FMU Export with Modelica.Utilities.Streams functions

[robert.hallqvist@…]

The following error is communicated when exporting a model incorporating the functions Modelica.Utilities.Streams.readMatrixSize and matrixName, Modelica.Utilities.Streams.readMatrixSize:

[CodegenUtil.tpl: 197:14-197:14]: Template error: initial value of unknown type: Modelica.Utilities.Streams.readRealMatrix(..., Modelica.Utilities.Streams.readMatrixSize(...

It is possible to export FMUs incorporating these functions with competing FMI supporting tools

[casella]

@lochel, do you think this can be fixed in time for 1.16.0?

[sjoelund.se]

I would need some more input because this works for me. Or did someone already fix it?

[robert.hallqvist@…]

The code that I do not manage to export as an FMU is:

model ReadExtMatrix_ArbSize

parameter String fileName="*.mat";
parameter String matrixName = "data" "Name / identifier of the 2D Real array on the file";
parameter Real Mat[Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {1, 0}, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {0, 1}] = Modelica.Utilities.Streams.readRealMatrix(fileName, matrixName, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {1, 0}, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {0, 1});

end ReadExtMatrix_ArbSize;

The *.mat file contains a 2*n matrix named data

[sjoelund.se]

This works fine for me:

model ReadExtMatrix_ArbSize
parameter String fileName="/home/martin/.openmodelica/libraries/Modelica 4.0.0+maint.om/Resources/Data/Utilities/Test_RealMatrix_v4.mat";
parameter String matrixName = "Matrix_A" "Name / identifier of the 2D Real array on the file";
parameter Real Mat[Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {1, 0}, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {0, 1}] = Modelica.Utilities.Streams.readRealMatrix(fileName, matrixName, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {1, 0}, Modelica.Utilities.Streams.readMatrixSize(fileName, matrixName) * {0, 1});
end ReadExtMatrix_ArbSize;

But if loadResource is used, this will not evaluate at compile-time, and will fail since loadResource is deferred to runtime for FMUs.

[adrpo]

See also #5263.

[anonymous]

Did I understand you correctly sjoelund.se that you are able to export the code posted above as an FMU? The example that I posted simulates just fine but when I try to export the code as an FMU I get the described error.

[casella]

Replying to sjoelund.se:

But if loadResource is used, this will not evaluate at compile-time, and will fail since loadResource is deferred to runtime for FMUs.

What is the rationale behind deferring loadResource to runtime for FMUs? If the parameter is structural, why couldn't it be evaluated at compile-time, as it should?

[sjoelund.se]

Did I understand you correctly sjoelund.se that you are able to export the code posted above as an FMU? The example that I posted simulates just fine but when I try to export the code as an FMU I get the described error.

Yes, it worked fine as FMU.

Replying to casella:

Replying to sjoelund.se:

But if loadResource is used, this will not evaluate at compile-time, and will fail since loadResource is deferred to runtime for FMUs.

What is the rationale behind deferring loadResource to runtime for FMUs? If the parameter is structural, why couldn't it be evaluated at compile-time, as it should?

Because it would be evaluated to a constant string that won't exist on the machine that runs the FMU

[casella]

Replying to sjoelund.se:

Did I understand you correctly sjoelund.se that you are able to export the code posted above as an FMU? The example that I posted simulates just fine but when I try to export the code as an FMU I get the described error.

Yes, it worked fine as FMU.

@robert, which version of OMC are you using? Please try with version 1.16.0-dev.beta1

[casella]

Replying to sjoelund.se:

Because it would be evaluated to a constant string that won't exist on the machine that runs the FMU

The idea in this case should be that this constant string is immediately used by the front-end to load the data and constant-evaluated it, so this string won't actualy show up in the FMU code at all. I get that the front-end understands which parameters have structural influence, and it constant-evaluates them for good. Do I miss something?

Also, in case loadResource points to a modelica:// URL, we could make sure that the Resource directory is shipped with the FMU and reachable by the dll that implements it. Would that be doable?

[robert.hallqvist@…]

Replying to casella:

Replying to sjoelund.se:

Because it would be evaluated to a constant string that won't exist on the machine that runs the FMU

The idea in this case should be that this constant string is immediately used by the front-end to load the data and constant-evaluated it, so this string won't actualy show up in the FMU code at all. I get that the front-end understands which parameters have structural influence, and it constant-evaluates them for good. Do I miss something?

Also, in case loadResource points to a modelica:// URL, we could make sure that the Resource directory is shipped with the FMU and reachable by the dll that implements it. Would that be doable?

Does this mean that it will be possible to modify the csv in the resources and that the FMU will be able to read the modified values? This would be of great benefit for my application if that is the case

[casella]

Replying to robert.hallqvist@…:

Does this mean that it will be possible to modify the csv in the resources and that the FMU will be able to read the modified values? This would be of great benefit for my application if that is the case

In principle, why not. The FMI specification, regarding the contents of the FMU, mentions that

4) Further data can be included in the FMU ZIP file, especially a model icon (bitmap file), documentation files, maps and tables needed by the FMU

If the FMU was generated from a Modelica model, it should be able to access data in directories structured according to the Modelica standard

[casella]

Retargeted to 1.17.0 after 1.16.0 release

[casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[casella]

Ticket retargeted after milestone closed