Models

Basic concepts

Entity

Everything in Simantics database is called an entity.

There are three dimensions for classifying an entity that is under a model:

• Intrinsic type of the entity: it can be for example a diagram, a time series, etc. (see below)
• Origin of the entity: it might come from some measuring device, it might be imported from a file or a database, it can be handwritten or a result of some activity. In the last case, the data is organized under the activity that generated it.
• The role of the entity in different activities. The data can be used for example as an initial state for a simulation, as an input time series or as a target for optimizing model parameters.

One principle in designing model concepts is to use type only to describe what kind of data the entity contains and how it can be adapted. The types should not be used to describe the role of the entity, because the same entity can serve in many different roles.

Library

Library is a container of entities. It has no other meaning than just to group them, but types inheriting it may add additional semantics. Entities can be linked to a library either by composition (ConsistsOf) or aggragation (IsLinkedTo).

Model

A model is an abstracted description of a real or imaginary physical object or phenomenon.

In Simantics, a model is a container for interrelated entities that are used to describe, visualize or compute some properties of a physical object or phenomenon.

Entities are organized under the model in a hierarchical fashion in libraries. Every entity has to be a part of (directly or with libraries between) exactly one model, project or ontology. Usually the entities linked to the model are part of the project or some ontology.

Entities can be graph or workspace persistent or transient.

Models are typed. A model type typically contains a template for creating an empty model, restricts which kind of entities can be created and asserts that certain entities are included to the model (for example some standard library of component types).

Configuration

Configuration is an entity that is used to describe a structure of a model. It is an abstract concept and doesn't restrict in any way how the structure is represented. Its only contract is to provide an address space. An address space is a set of variable names and their data types.

There is currently no mechanism for getting the address space of a configuration. The base realization of the configuration can however be used for that purpose.

Realization

A realization is not a type but a role of a configuration. Every realization realizes some configuration. A realization is a tree-structure that binds a value to variables of the configuration it realizes. There are many different realization relations: the relation specifies how the type of the value in realization is related to the type of the variable specified in the realized configuration. In this way, for example states and histories can be uniformly represented.

Activity

Activities are defined as something that can be run. Multiple activities can be run at the same time, and in different machines and processes. Currently active activities can be controlled.

An activity usually creates a Run-entity under the Activity-entity that configures it. That entity contains all results the activity produced. There can also be activities that modify the model in some other way.

Activities can be defined as continuous: they are run automatically when the model changes.

Activities are configured to run using certain computational resources. In the model, these resources are referred with logical names, the logical names are assigned to actual physical resources in the project. The default assignment is graph persistent but each user can override the resource assignments with workspace persistent configuration.

View

Views visualize one or multiple entities. Typically the visualizations access the entity using their realizations and different variables in the configurations are referred relatively so that the same view can be used to visualize different realizations of the configuration.

There are both independent and associated views. Only independent views are included to the model. They may depend on many data items but are not bound to any one of them. Associated views are associated with one particular data item: typically a structual component has an associated diagram. Associated views are only linked to their data items and when the data item is removed, also the view is removed.

Dependencies

A model uses data from three differently behaving locations, model configuration, shared libraries and ontologies. A model specifies the used shared libraries and ontologies explicitly by using semantic links L0.IsLinkedTo (specify more explicitly).

Thus for a model m the set of dependencies can be found from m by traversing the transitive closure of L0.ConsistsOf and L0.IsLinkedTo. These dependencies can be queried by name and type by using the indexed function L0.Dependencies.

The query text is in Lucene query format. The index contains the named fields 'Name' and 'Types', where Name is the L0.HasName property of the resource and Types is a space-separated list of the resources' type hierarchy.

An example to query all instances of L0.Function from model dependencies.

<source lang="java"> Function index = graph.adapt(L0.Dependencies, Function.class); Collection<Map<String, Object>> results = (Collection<Map<String, Object>>)

   index.apply(graph, model, "Types:Function");

</source>

Examples

• Structural components
• Component types
• Time series
• Valuations
• Simulation snapshots
• CSG-geometries
• FEM-node or element datasets
• Other models (data items under the linked models are not part of the parent model)

• Simulation experiments
• Optimizations
• Validators
• Report generators
• Composite activities

• Charts
• Operation diagrams
• CFD-visualizations
• Spreadsheets (these can be also data items in some cases?)
• Queries