dynamic model description

[andreas-junghanns]

Currently, FMUs ship a fixed modelDescription.xml.
Such fixed model properties requires re-exporting FMUs every time a small change to the IO or parameters are required.

If we introduce a function fmi3GetModelDescription() to retrieve the modelDescription as string during runtime, parameters could be used to influence the IO.

Example use case 1:
A generic CSV reader FMU is passed a path to a file plus a regular expression to filter the variables from the file.
The FMU will than produce a modelDescription string with the variables as found and filtered in the CSV file.

Example use case 2:
A generic tool-coupling FMU is passed a model name to be started in a remote simulation tool.
Depending on the IO defined in the model, the modelDescription string is produced by the tool-coupling FMU.

Solution idea:
The FMU only shows structural parameters in the modelDescription.xml.
Those structural parameters can be set during the Configuration Mode and during Instantiated, the importer can retrieve the dynamic modelDescription string calling fmi3GetModelDescription().

Downside:
Static analysis of the IO is not possible anymore.

[chrbertsch]

FMI Design Meeting Berlin:

Andreas: idea: modelDescription.xml only contains structural parameters.
Use Case: generic FMU, that reads a file and configures itself. Only then an importer inquires with fmi3GetModelDescription a string with the modeldescription. There is no need to re-export this FMU everytime.
Klaus: We had several similar discussion with calculate structural parameters.
Pierre: ... cannot be done on different platforms
Andreas: static ... is gone. Code generation is gone.
Andreas: there is no default
Pierre: splits the FMI standard into static and dynamical FMUs
Torsten: if the modelDescription is reproducalble, it could work for a Modelica tool
Pierre: only on the same platform
Andreas: problems if the file changes
Klaus: graphical represenation etc. is lost
Pierre: if we want to go into this direction, I would not generate a modelDescription.xml but have it in memory
Torsten B.: not usable for all tools
Pierre: (invariance problem)

Andreas: is this a good idea?
Klaus: This is a "hyper FMU" with only fixed structural parameters.
Andreas: I hear that some tool vendors can not to support this.
Pierre: The proposal has to be worked out in more detail. There might be other technical solutions.
Klaus: I am not against it.
Torsten: why is it not possible to re-generate the FMU?
Andreas: customers do not want to do it (effort, licenses)
Pierre: you could also include an FMU generator
Timo: injection an xml file only does not fit to build chains.
Markus F: for our tool, this would be no problem for the export. Our FMUs always contain the same binary.
Klaus: Modelica exporters will never do this.
Timo: we had similar discussion with customers on generic FMUs
Pierre: Another view: configuring before import... "factory FMus"
Adrian: how should an importing tool handle this.
Pierre: .... this would work
Andreas: We do not want to fill disks with many generated files
Klaus: what is the importer? Could be just the GUI. "Could be done with Simulation"
Timo: Could be a layered standard
Pierre: we need invariants
Markus F.: why not go the tool coupling way?
Andreas: the number of inputs and outpus changes with this proposal.
Markus: not regenerate the binary ...
Klaus: this is not the problem ...
Klaus: why is FMI so static? e.g. why need static value references?
Torsten B: provide information w/o instantiation.

Pierre: we should investigate this idea

Interested people: Andreas, Klaus, Pierre, Timo, Jan, (Torsten B.)
Andreas: I will invite to a meeting