MCP-0017: FMU_Import

[modelica-trac-importer]

Modified by dietmarw on 9 Jun 2015 12:41 UTC
This is the ticket for MCP 0017:

The primary goal is to important an FMU 2.0 ModelExchange or CoSimulation in a fully portable way into Modelica. Basically, the FMU is a Modelica ExternalObject (Modelica 3.3 section 12.9.7) and the FMU functions are Modelica functions operating on this ExternalObject. An ExternalObject has two required functions: “constructor” + “destructor”, that are called by the simulation environment when appropriate. It is proposed to add three additional optional functions that an ExternalObject can have. These functions are also useful for non-FMU external objects.

Note, currently, import of FMUs is tool specific, e.g. due to function fmi2CompletedIntegratorStep. Initially, this was dicussed in ticket #1626.

Document location

• https://svn.modelica.org/projects/MCP/MAinternal/MCP-0017_FMU_Import/

---

Reported by otter on 9 Jun 2015 12:24 UTC
This is the ticket for MCP 0017:

The primary goal is to important an FMU 2.0 ModelExchange or CoSimulation in a fully portable way into Modelica. Basically, the FMU is a Modelica ExternalObject (Modelica 3.3 section 12.9.7) and the FMU functions are Modelica functions operating on this ExternalObject. An ExternalObject has two required functions: “constructor” + “destructor”, that are called by the simulation environment when appropriate. It is proposed to add three additional optional functions that an ExternalObject can have. These functions are also useful for non-FMU external objects.

Note, currently, import of FMUs is tool specific, e.g. due to function fmi2CompletedIntegratorStep. Initially, this was dicussed in ticket #1626.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1727

[modelica-trac-importer]

Comment by dietmarw on 9 Jun 2015 12:41 UTC
Added document location to description.

[modelica-trac-importer]

Comment by hansolsson on 14 Sep 2016 10:35 UTC
Hans: Would prefer to merge enterEventMode(obj) and enterContinuousTimeMode(obj) to enterMode(obj, ...); - could then possibly add more transitions in the state-diagram to this function.
Henrik: There are several states in the state machine for FMU, and multiple transitions - in some cases the transition-functions are not called.
Hans: Should ensure that enterMode(obj, ...) is called consistently. Should it have both previous and current mode as input?
Henrik: FMU should take of previous mode.

Will have to ensure that this works for all transitions in state-diagram.
Convenient to have redundant enterMode(obj, ...) defined as no-op.

Is there always a clear place for calling this function in a simulation environment?
--
Resource location:
Two issues:

• Moving packages should move resources!

Hans: Already part of Dymola/3D Experience platform move/copy operations, similarly as references, or isn't it? Could be confusion by LibraryDirectory - that is handled this way.

Henrik: Should allow relative paths as well in loadResource.
Note: Normal structure is:

M 
 - package.mo
 - A 
   - B.mo
   - package.mo
 - Resources - even for M.A.B

Seems like tool-issue about moving/copying classes.

• Resources inside an FMU.
  The idea is that loadResource ensures that a table-file can be referenced, a FMU built referencing this table-file, sent to someone else and the resource is found when running the FMU.
  Internally this is handled by having the table-file in the FMU, and using a reference returns this - based on fmiLocation sent to instantiate model.

fmi2SetupExperiment:
Hans: We need this an external function of the FMU, but having consistent argument with the simulation seems less urgent, we could expose them as parameters of the imported FMU and require users to set them for the imported (and that could be that different from simulation setup).
Two possibilities: access the information in Modelica and automatically call this function in wrapper, or automatically call this function for external objects - if provided.
Gerd: There are some cases where start-time is used currently in Modelica.
Hans: Risk of misuse in models; will we need fake stop-time in simulation for debugging?

Nominal attribute seems less urgent - since work-around exist and nominal is not *that* necessary.
Value reference problem seems urgent: started discussion

[modelica-trac-importer]

Comment by hansolsson on 14 Sep 2016 12:07 UTC
The solution for the unsigned int as value reference in Dymola and SimulationX is to treat it as integer - and let it overflow (more or less controlled).
The change of the external interface is not that needed.

In SystemModeler additional integer types are available in the external environment (as we interpreted Henrik).
--
Additional changes are needed for portable efficient import of FMUs (especially setting and getting variables allowing for algebraic loops over the FMU).
It is not clear if the non-linear predictive control use case will benefit from this - or if the automatic modeChanges will be a problem, and the wrapper needs to be adapted.

Both for FMU and other numerical use case it is important that completedIntegratorStep specify that the directly preceding calls are for the state at the end-point of the step (that would not necessarily be the case for all integrators).

For maximum of a signal it requires the derivative of the input, whereas one goal was to avoid that requirement.

Using the ModelicaError workaround for FMUs seem dangerous: this will involve longjmp between different DLLs - and it is not clear that the FMU-interface allows functions to not return (the error logger in FMU is only supposed to log the error).
And for external objects (in DLL) you can assume the first call constructs the external object, and the last one deletes the external objects.

Using the relative tolerance in other places is not a good idea - since the error might cause chattering, since the crossing functions will have an error of the order 1e-4. Thus this is actually an argument against providing that information to models.
--
How to proceed:

• Allow these optional functions in external objects (modeChange and completedIntegratorStep - where the object should be in the state corresponding to the completed step).
• Document the behavior of loadResource.
• Test-implement - and see what is missing

Hans: What to do if there is a state event during a step, should completedIntegratorStep first be called at the end-point of the original step?
Gerd: At the point found by the event-locator - i.e. the point where the event will be handled, and the same time-point as the starting point of the next step.

[modelica-trac-importer]

Comment by hansolsson on 14 Sep 2016 12:10 UTC
Unclear who will volunteer to do it.
Stefan V doesn't work on FMUs, neither Gerd nor Hans think they have time.

[modelica-trac-importer]

Modified by stefanv on 25 Oct 2017 13:32 UTC

[GallLeo]

We see more and more Modelica users store their FMU wrappers in Modelica packages.
Those Modelica packages are then not Modelica-compliant anymore.

I'm courious why this MCP had high priority in the beginning and then came to a full stop.
The last comment indicates, that nobody had time to work on it?
Or is it because it's impossible to solve satisfactory for all tools?

[chrbertsch]

I would appriciate this also w.r.t. to the overall goal that the MA standards should be compatible with each other and together allow seamless workflows.

[GallLeo]

Is this MCP scheduled for Modelica 3.5?

[HansOlsson]

Is this MCP scheduled for Modelica 3.5?

Realistically (and unfortunately) not, since there hasn't been enough work on it.