Development of a generic and portable FMU import block

[beutlich]

Currently it is hardly possible (or impossible) to share a custom Modelica library between different tools or platforms if imported FMUs are involved. This is a striking shortcoming of the MSL (or any other generic Modelica library), though both FMI and Modelica are created for openness and tool-exchangeability.

Based on the everlasting problem of the online-computation of the minimum of a (continuous) variable, I summarized my recent experiments in a presentation for the Saxon Modelica User's Group. The corresponding experimental Modelica library is also publicly available at beutlich/LastLib.

My idea is the development of a generic and portable FMU import block / template with a specified interface for the FMU itself and the parameters, inputs and outputs of the FMU.

block FMUImport "FMU Import"
  import M = ModelicaServices;
  parameter String fmuPath = "" "File where FMU is stored"
    annotation(Dialog(
      loadSelector(filter="Functional Mock-up Units (*.fmu)",
      caption="Open file")));
  parameter String fmuInstanceName = "test_fmu";
  parameter M.FMISettings fmuSettings(logging=true);
  parameter Real pR[M.getNumberOfRealParams(fmu)] "Real parameters";
  parameter Integer pI[M.getNumberOfIntegerParams(fmu)] "Integer parameters";
  input Real uR[M.getNumberOfRealInputs(fmu)] "Real inputs";
  input Integer uI[M.getNumberOfIntegerInputs(fmu)] "Integer inputs";
  output Real yR[M.getNumberOfRealOutputs(fmu)] "Real outputs";
  output Integer yI[M.getNumberOfIntegerOutputs(fmu)] "Integer outputs";
  // similar for the Boolean and String types
  protected
    parameter M.FMUExternalObject fmu(fmuPath, fmuInstanceName, fmuSettings);
  equation
    // ...
end FMUImport;

Technically, everything what is tool-dependent has to go to ModelicaServices, but the aim should be to specify the block as tool-generic as possible. Also, we should reuse as much as possible from modelica-tools/FMUComplianceChecker for the implementation of the external object FMUExternalObject, e.g., FMU unzipping, XML parsing, library loading/unloading etc.

For dedicated I/O signal names the expandable connectors feature of Modelica still can be used on top of the FMU import block. However this would be beyond the scope of a generic block.

@andreas-junghanns @HansOlsson @hubertus65 @johanrhodin @otronarp @sjoelund @svorkoetter Please let me know what you think. Is it possible at all? Thank you.

@FrenkelJ @vwaurich FYI.

[sjoelund]

I am of the opinion that Modelica tools should not import FMUs, but rather let FMI tools handle connections between FMUs.

[andreas-junghanns]

The idea is good: why should every tool have a different way to ask the user to bridge between two standards - both from the same organization (Modelica Association).

I cannot comment on how good your proposal from a Modelica perspective is.

Regards,

• Andreas

Am 10.11.2017 um 12:08 schrieb Thomas Beutlich:

Currently it is hardly possible (or impossible) to share a custom Modelica library between different tools or platforms if imported FMUs are involved. This is a strinking shortcoming of the MSL (or any other generic Modelica library), though both FMI http://fmi-standard.org/ and Modelica are created for openness and tool-exchangeability.

Based on the everlasting problem of the online-computation of the minimum of a (continuous) variable, I summarized my recent experiments in a presentation http://www.modelisax.de/wp-content/uploads/2013/06/Modelica_FMI_Last.pdf for the Saxon Modelica User's Group http://www.modelisax.de. The corresponding experimental Modelica library is also publicly available at beutlich/LastLib https://github.com/beutlich/LastLib.

My idea is the development of a generic and portable FMU import block / template with a specified interface for the FMU itself and the parameters, inputs and outputs of the FMU.

block FMUImport "FMU Import" import M = ModelicaServices; parameter String fmuPath = "" "File where FMU is stored" annotation(Dialog( loadSelector(filter="Functional Mock-up Units (*.fmu)", caption="Open file"))); parameter String fmuInstanceName = "test_fmu"; parameter M.FMISettings fmuSettings(logging=true); parameter Real pR[M.getNumberOfRealParams(fmu)] "Real parameters"; parameter Integer pI[M.getNumberOfIntegerParams(fmu)] "Integer parameters"; input Real uR[M.getNumberOfRealInputs(fmu)] "Real inputs"; input Integer uI[M.getNumberOfIntegerInputs(fmu)] "Integer inputs"; output Real yR[ M.getNumberOfRealOutputs(fmu)] "Real outputs"; output Integer yI[M.getNumberOfIntegerOutputs(fmu)] "Integer outputs"; // similar for the Boolean and String types protected parameter M.FMUExternalObject fmu(fmuPath, fmuInstanceName, fmuSettings); equation // ... end FMUImport;

Technically, everything what is tool-dependent has to go to ModelicaServices, but the aim should be to specify the block as tool-generic as possible. Also, we should reuse as much as possible from modelica-tools/FMUComplianceChecker https://github.com/modelica-tools/FMUComplianceChecker for the implementation of the external object FMUExternalObject, e.g., FMU unzipping, XML parsing, library loading/unloading etc.

For dedicated I/O signal names the expandable connectors feature of Modelica still can be used on top of the FMU import block. However this would be beyond the scope of a generic block.

@andreas-junghanns https://github.com/andreas-junghanns @HansOlsson https://github.com/hansolsson @hubertus65 https://github.com/hubertus65 @johanrhodin https://github.com/johanrhodin @otronarp https://github.com/otronarp @sjoelund https://github.com/sjoelund @svorkoetter https://github.com/svorkoetter Please let me know what you think. Is it possible at all? Thank you.

@FrenkelJ https://github.com/frenkelj @vwaurich https://github.com/vwaurich FYI.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/modelica/Modelica/issues/2389, or mute the thread https://github.com/notifications/unsubscribe-auth/AWZilKk1ZJusSzXjmuoeEXwuw69mVaCpks5s1C62gaJpZM4QZZ_P.

[otronarp]

I think that the idea of a portable FMU import is good and that there are use cases for it , but I think that I would rather see it implemented through additions to the language (compared to adding magic functions to ModelicaServices):

• https://github.com/modelica/ModelicaSpecification/issues/1727
• https://github.com/modelica/ModelicaSpecification/issues/1626

[hubertus65]

I think it is a great idea to get this done and consider it quite necessary for a number of relevant simulation-based workflows. So, I disagree with @sjoelund above and actually disagree strongly.

It is not clear to me whether it can be dealt with cleanly in the language: Modelica is all about hiding the details of the numerical solvers for the user's safety, and FMI is all about exposing it to make efficient simulation possible. Ticket 1626 referenced by @otronarp suggests to use an extension of ExternalObject, and that is not that far away from using ModelicaServices. I am strongly opposed to simply make the integrator step accessible in the language, that is against our design ideas.

I think there are 2 basic ways to do it: either through something like an FMI-specific extension of ExternalObject, or through ModelicaServices. There are maybe other options, but the two above build on existing definitions in the language.

[chrbertsch]

Most functionality requested in this issue has been made available by @t-sommer in FMPy https://github.com/CATIA-Systems/FMPy in release 0.3.11, available in the FMPy GUI and as a command, see e.g. test case https://github.com/CATIA-Systems/FMPy/blob/main/tests/test_import_to_modelica.py

[chrbertsch]

The work of @t-sommer has been moved from fmpy to https://github.com/modelica/Modelica-FMI

[beutlich]

to https://github.com/modelica/Modelica-FMI

and being a private repository. Anyway, it's time to close this one after almost 7 years.

[casella]

@beutlich I'm sorry but I don't understand why you marked this ticket as wontifix and closed it.

The problem is still absolutely relevant, I understand it has not been entirely solved yet by @t-sommer's solution: @hubertus65 wrote in an email to modelica-design on 09/09/2024 14:37:

It is in the works, but as you can see form the issues list, there is more todo. I think this effort would benefit from more extensive testing by all tools, including OpenModelica of course. and the cited https://github.com/modelica/Modelica-FMI is not accessible to MAP-Lib members.

Do I miss something?

[casella]

@t-sommer, @chrbertsch can you please make https://github.com/modelica/Modelica-FMI accessible to the MAP-Lib group (or to everybody, just in case)?

[t-sommer]

I've added @modelica/map-lib.

[beutlich]

I've added @modelica/map-lib.

I confirm that I gained read access to https://github.com/modelica/Modelica-FMI again.

@beutlich I'm sorry but I don't understand why you marked this ticket as wontifix and closed it.

The problem is still absolutely relevant, I understand it has not been entirely solved yet by @t-sommer's solution: @hubertus65 wrote in an email to modelica-design on 09/09/2024 14:37:

My idea from 7 years ago was to have an exchangeable Modelica-FMU block with tool-specifics implemented in ModelicaServices. There was no more than this early idea.

https://github.com/modelica/Modelica-FMI on the other hand generates Modelica blocks with all parameters, input and output variables expanded (names, units, quantities, descriptions etc.) from templates. For me that approach seems more promising.

[casella]

My idea from 7 years ago was to have an exchangeable Modelica-FMU block with tool-specifics implemented in ModelicaServices. There was no more than this early idea.

https://github.com/modelica/Modelica-FMI on the other hand generates Modelica blocks with all parameters, input and output variables expanded (names, units, quantities, descriptions etc.) from templates. For me that approach seems more promising.

I completely agree, but at the end of the day this new approach provides a solution to the problem this ticket was opened for. In some sense, https://github.com/modelica/Modelica-FMI actually provides such blocks. But I get your point, it's not part of the MSL, so it doesn't belong here.

My point is, being able to import FMUs in a Modelica model is a relevant issue, which is currently unresolved and should be tracked by an issue. The question is, on which issue tracker?