Skip to content


Modelon Impact relies on a cloud-native workspace concept, which allows you to collaborate and share content with other users (in your organisation or with your external clients). You can manage and configure your Workspace in the Workspace Management app.


A Workspace is a virtual environment, where Modelon Impact stores your data. Information associated with a Workspace is stored in a number of locations and should not be confused with a single working directory on a disk.
The following figure shows how you can imagine a Workspace. Within the Workspace there are also dependencies (shown as arrows), but more about this below.

The settings and configuration of your Workspace are stored in your user environment.

A Workspace contains:

  • Projects that contain editable Workspace content intended for tracking under a version control system (Git or Subversion; mandatory, at least one).
  • Libraries containing read-only dependencies of the Workspace.
  • Generated Resources are FMUs (compiled models), simulation results and other artifacts (all generated by Impact operations).
  • (Favorites for classes you see in the left side-bar, are user-specific UI settings and are therefore not part of a Project or Workspace)

Workspaces are designed by users and are always located in the user area and are therefore independent of other Workspaces. Editable content can be shared via Projects, and can be downloaded and uploaded to Projects.

Workspaces configurations can be shared via a hyperlink, under the condition that all contained Projects are under version control (cf. Projects).

Workspaces can be downloaded and uploaded as ZIP files.


As a user, you work in Projects, which means Projects are editable and all your data is stored there. You can have multiple Projects in your Workspace. Each Project can contain Modelica libraries/packages (normal case).

** Project-related settings and metadata are stored in the project.json file.**

Projects contain🔗

(default folder names in bold letters):

  • Modelica libraries incl. additional resources like data files (in a subfolder Resources inside the corresponding Modelica library).
  • Resources (folder), which contains subfolders for ...

    • Views: Views (stickies, result charts) belong to a specific Modelica class (model). All Views are saved in a folder with the class name, and the subfolder structure follows the Modelica namespace (one JSON file per View).

    • Favorites from the Details Panel: You can set Favorites (star icon) for parameters and variables for filtering. They belong always to the particular Modelica class. All those kinds of Favorites are saved in a sub-folder with the surrounding Modelica package name, and the sub-folder structure follows the Modelica namespace (one JSON file for Favorites per class).

    • ExperimentDefinitions: Experiment Definitions belong to simulation models (the further sub-folder structure follows the Modelica namespace, one JSON file per experiment)

    • CustomFunctions: Source code and associated resources of Custom Functions (python scripts).

- ***ReferenceResults***: In this folder, you can store reference regression test result files for your Modelica libraries.

Projects contain editable Modelica packages/libraries including all related sources. Those folders (one folder per top-level package) only contain artifacts for the package. You can extract these folders to import them into other Modelica vendor tools.
By default, Impact uses sparse checkout and only checks out folders mentioned in the project.json file.

Modelon Impact-specific artifacts like Experiment Definitions or Custom Function are stored outside Modelica and Modelon Impact fetches these artifacts from these specific folders.

Only one project with a Modelica library of a specific name can be enabled at a time🔗

In a workspace, you can only have one active project containing a Modelica library with a specific name enabled at any given time.

For Example, If you have two projects "MyLibraryA" and "MyLibraryB" that both contain a Modelica library with the same name

then both MyLibraryA and MyLibraryB cannot be enabled in the workspace at the same time, as shown below.


Impact creates folders only if required. Therefore you may not see all folders listed here.


It is not recommended to edit the folder structure manually. Modelon Impact creates them and relies on this. Custom folders are ignored by Modelon Impact as long as they are not used by Custom Functions.

Projects can be managed with a version control system (Git or Subversion). This is optional and can be added/configured via the Workspace Management app.

Projects can be exported/downloaded as ZIP files, and Projects can be released as Libraries. Then they are encrypted and read-only for users.


This folder, which is evaluable via VS Code, is generated by Impact for every Project. This folder contains a project.json file, and this is how Impact recognizes that it is a Project. In this JSON file the name, the version, dependencies and content paths are stored.


Please be careful when editing the project.json file. It is not recommended to change IDs. Please note that other Projects can depend on the current Project and that Workspaces may link to this Project.

Don't modify the name here, do it always via the Impact UI. The name is used for references in multiple places.

Default Project🔗

In Workspace Management, you can set a Project as "default" for a Workspace.
The Default Project is a setting and is indicated by a specific icon in both, the Project Browser and the Workspace Management app. This Project is associated with the Workspace dependencies.

If you are working with read-only classes (typically from the released libraries, cf. Libraries), Modelon Impact stores Experiment Definitions, Views, and Favorites from the Details Panel in this Project.


Don't mix Default Project with active Project. The active Project is the Project in the Project Browser from which the currently opened class originates, as long as it is an editable class. Read-only classes therefore never originate from an active Project. For editable classes, Modelon Impact stores
Experiment Definitions, Views, and Favorites from the Details Panel in this active Project.


There are also Libraries. They are not editable and will be displayed just as Modelica libraries in the lower part of the Workspace panel. Libraries are encrypted, which means the Modelica libraries are stored in .mol or .moc files.

In the Workspace Management app you can define which Library (= Released Project) your Workspace includes and therefore your Projects depend on. This means, that you use or reference something in your Projects, that is located in a Library (e.g., a Modelica class in the Modelon Base Library), your Project will always require the presence of this Library.

Generated Resources🔗

Generated Resources are immutable artifacts, generated by Modelon Impact (e.g., OCT) and some of them are binary. Typical Generated Resources are compiled models (FMUs), experiment results, and executed experiment definitions. Also, artifacts, generated by Custom Functions first land here.

By default, Generated Resources are linked to an Experiment and can be accessed (post-processing) and exported/downloaded via the Simulations tab.

Generated Resources are never under version control. Sharing is only possible if they are referenced in Projects (and therefore a Workspace).

Modelica Packages🔗

The Workspace defines which Projects can be used and which Libraries can be used. All Projects can contain one or more Modelica packages (also called "Modelica libraries).

If you create or upload a new top-level Modelica package in Modelon Impact, it will be stored in the folder Modelica. This folder then contains all Modelica/ libraries of your Project and we recommend using this folder if you upload a library outside of Modelon Impact e.g., via JupyterLab, VS Code (/Modelica/MyPackage1/...).

The version of Modelica packages can be selected (if available) via Workspace Management (cf. Project version). Modelon Impact starts Modelica conversion scripts automatically if required.

However, Modelica packages can be stored anywhere (not recommended), e.g. if they are already present. Modelon Impact fetches these packages and loads them into one single global Modelica namespace!


Modelon Impact loads all libraries into the same namespace. It does not matter if they exist in different Projects (editable or read-only).
If your Workspace loads multiple Projects and these Projects contain Modelica packages with the same name, Modelon Impact loads only the first occurrence of the name. Other occurrences of the name are ignored when loading. The Workspace Management therefore lets you disable Projects.


In Modelica it is implicitly allowed to define circle dependencies between packages, also on top-level. This is not nice, but the Modelon Impact compiler OCT can handle it.

It is strongly recommended to avoid circular dependencies between Modelica packages. Modelon Impact will handle this situation but it may lead to persistent warnings on inconsistent Project dependencies, issues with Project versioning and unexpected results running conversion scripts.
For example (cf. figure above): A model in Modelica_B uses elements from package Modelica_A, then Modelica_X` should not use elements from Modelica_B.

The WAMS folder🔗

Modelica libraries created in previous versions of Modelon Impact may contain the WAMS subfolder in the Resources folder of your Modelica package. This folder may contain Modelon Impact-specific artifacts from previous versions. You can remove the folder because Impact no longer considers this folder.

If you have performed a workspace conversion, all artifacts contained there should have been converted to new artifacts, which are then stored outside the libraries (see section Projects).

Experiment Definitions🔗

Experiment Definitions contain all the information needed to run or to reproduce a simulation, i.e. the model, type of experiment, parameter modifications, solver and compiler settings and more. In the Modelon Impact user interface, there are two places (Application settings -> EXECUTION and the Experiments panel), where you can enter this information.


There are three groups of settings: - Application ("user") Settings are stored in the browser and include: - UI customizations (canvas, model browsing) (including Favorites for classes you see in the left side-bar), - Export settings, and - Workspace settings are stored in the user space and browser cookies.

  • Project settings, which define the user experience of a Project, like dependencies to Libraries or Unit settings are stored in the project.json file. This file is part of the project folder and therefore, if wanted, also under version control.
  • Execution settings: All settings and parameters, which are required to run or to reproduce a simulation result are stored in Experiment Definitions as JSON file.