Operating mechanism (advanced)

This page introduces the operating mechanism behind Mogick desktop and helps you understand the reasons behind some interface behaviors. Most of these mechanisms are completed automatically in the background, and manual intervention is usually not required for daily use.

Installation and runtime positioning

Mogick desktop, modeling kernel, interfaceless simulation backend, help documentation and other programs are installed in different subdirectories under the same installation root directory. When the application starts, it will calculate the installation root based on its own location, and position these supporting programs and resources based on their relative positions.

The advantage of this design is that no matter which drive letter/directory it is installed in, or it is portable and distributed with the installation package, the application can correctly link the modeling kernel and the simulation backend, without starting failure or missing functions due to a hard-coded path.

Modeling and Simulation Services (MOLS)

The desktop side will automatically launch and maintain a modeling and simulation service (MOLS) in the background, and communicate with the AI engine. When you describe your modeling/simulation requirements in natural language, AI will call this service to complete modeling and simulation, and generate models, pictures or result files in the current project directory. You can click to view them in the [Product Workspace] (/desktop-app/artifact-workspace). The .mo model can also enter the [Text and Graphics View] (/desktop-app/modelica-mo-view).

• The service life cycle is automatically managed by the application and is transparent to you: no need to manually start external tools.
• The application will try to recover automatically when the service is abnormal.
• .mo graphical view and other capabilities rely on the service being ready; when the service is not ready, the interface will give a readable prompt instead of a white screen.

When running independently per session

In order to allow multiple sessions to truly work in parallel without queuing each other, the desktop allocates an independent backend runtime (such as Julia, mols) for each session:

• Activate only when used: The session starts a certain backend capability when it is used for the first time, instead of always persisting.
• Close the session and recycle: Closing the session will recycle its backend and release resources.
• Limited by machine capability: The number of active backends is limited by machine capabilities; when idle for too long or exceeds the upper limit, the idle session backend that has not been used for the longest time will be recycled (the one in use will not be touched).

The interface changes you can perceive are very light, reusing the existing chat prompt style:

• The "Starting" prompt is displayed when the backend is launched for the first time.
• When the recycled session is used again, the prompt "Running state has been reset" will be displayed.

Note: Click .mo to view model text/graphics (moView) currently still uses the globally shared modeling backend and is not isolated with the session.

Tool hosting and multi-session isolation

The desktop provides callable tools for AI through the MCP (Model Context Protocol) host. The host will choose the isolation method based on the nature of the MCP:

• Connecting to stateful/blocking backend MCP (such as Syslab → Julia, Sysplorer → mols) is based on session isolation. Each session gets an independent context, can be concurrent, and is cleaned up when the session ends.
• For stateless/concurrent MCP, just share one copy.

This not only prevents heavy backends from interoperating with each other in multiple sessions, but also does not waste resources for lightweight tools. For the addition and management of MCP, see MCP Server.

SysCAD product 3D viewing

When the session generates a .syscad model file, you can click on the file in the [Product Workspace] (/desktop-app/artifact-workspace), open a tab in the preview area and render its 3D model. Read-only browsing such as rotation, scaling, and translation is supported without switching to external SysCAD.

Rendering relies on native SysCAD viewing capabilities; it degrades and gives a readable prompt when opening or rendering exceptions occur.