0

In FMI 2.0, array parameters are serialized to scalar variables. Importing tools can display them as arrays, but their size is fixed and their handling is inefficient. Better array support is currently in development by a working group of the FMI project, but I would like to know about workarounds how to handle array parameters in the meantime.

Ideas are to

  • hard code them (disadvantage: the are no paramters any more ...)
  • put them in a CSV file in the resources folder and read them at the start of the simulation (disadvantage: no parameter mask support, complicated)
  • put them in a string parameter and parse it at simulation start (disadvantage: limited length of strings, complicated)

Are there other ideas / workarounds? Thanks in advance.

Christian Bertsch
  • 383
  • 1
  • 7

1 Answers1

1

Combinations of the ideas outlined in your question are also possible.

Hard code with selector parameter

Here the idea is to hard code several variants of your array and allow the user to select one with a parameter.

I did this in a recent project where a user needed to choose between different spatially resolved initial conditions (e.g. temperature profiles). We used a model to generate more than 100 different sets of spatially resolved initial conditions (each representing a different "history" of the modeled object), hard coded them as FORTRAN arrays (the inner core of the FMU was in FORTRAN), and used a single integer parameter to select which profile he wanted to use.

It worked very well and the user has no way of breaking it.

Shorten the array and interpolate

If the data in your array is smooth, you might be able to dramatically reduce the number of values you actually need to pass to your simulation - which would make serialization into scalar parameters less painful. Within the FMU, interpolate to get the resolution you need.

String parameter to select csv file

You can use a string parameter to provide the path to a user-provided csv-file. I would not recommend this, because the user will most likely break it.

mklingn
  • 151
  • 3