search

modelica / fmi-standard

Specification of the Functional Mock-up Interface (FMI)
https://fmi-standard.org/
Other
274 stars 85 forks source link

ME statechart not complete for change of structural parameters that add or remove states? #1059

Closed chrbertsch closed 4 years ago

chrbertsch commented 4 years ago

(moved @hubertus65 ' s comment out of https://github.com/modelica/fmi-standard/issues/1016#issuecomment-644178154 as a new ticket as it addresses a new topic)

The FMI-ME statechart does not seem to be complete for me for the -admittedly quite complex case - of structural parameters that add or remove states, at least if "initialization" is interpreted in the sense of initializing an ODE/DAE. If a structural parameter is changed in event mode and changes the number of states, there has to be a new initialization state to initialize "new" states, or what the values of the reduced number of states should be. A second remark: It will not be possible to create such FMUs from Modelica tools since Modelica as of today does not support a changing number of states in a model based on an event. My assumption is that this is for controller design, where the number of states in the controller changes dynamically? I also wonder whether it might not be wise to forbid a changing number of states in ME FMUs: it opens a can of worms in terms of hard open questions. How are the start values of "new" states defined and made visible? If the number of states is reduced, do the values of the remaining states remain the same as before the event? How are they mapped? I can imagine that control design tools might want to support this, but I don't see physical modeling tools support this any time soon. I have not seen customer demand for this feature either.

chrbertsch commented 4 years ago

Copied @andreas-junghanns 's reply from ifrom https://github.com/modelica/fmi-standard/issues/1016#issuecomment-644354656

@hubertus65 This was discussed and we decided this is not an issue FMI has to solve. If the FMU can handle changing number of states, it offers states depending on structural parameters, else it does not. If the importer cannot handle such an offer for changing structural parameters changing the number of states, well, it should not change that structural parameter away from its initial value.

We wanted to make sure we do not restrict artificially which can be restricted by the tools very easily to allow future, smarter implementations to potentially use these possibilities.

clagms commented 4 years ago

@hubertus65 these are nice points that you raise. Do you have ready examples that illustrate these challenges that you can share with us? I agree with you that this is a can of worms, but I'm wondering whether one can characterize more rigorously when it (or when it is not) a problem. At least, we could use some small examples to show people that "systems like these" are probably not simulatable with ME (and most likely the cosim interfaces).

andreas-junghanns commented 4 years ago

@klausschuch : please help here - you have a better memory of the endless discussions we had around exactly these points.

@clagms : I am all for examples that show "how to do things". To find examples for "what does not work" is extremely presumptuous: just because we do not know an algorithm to solve this is not proof that it cannot be done. Especially in special applications with some favorable restrictions, exciting new things might be possible. Why restrict the standard or the imagination of (naive) people that might dare to go where no one went before? And please remember: Both the FMU exporter AND the FMU importer have to agree to use a given feature - there is no real danger (except for bad implementations, but those will exist no matter what we define) of abuse of this freedom.

hubertus65 commented 4 years ago

Here are 2 somewhat academic examples: An adaptive controller where you allow design of controllers of different orders during an update event. If there is a state representing the integrated error, a user would want to transfer that value to the state with the same function in the updated controller. It is probably not a disaster if it would be initialized to zero, but the resulting controls are likely not smooth. Example 2 (a bit contrived, it can be done with constant # of states) is a rocket with 2 stages. When the stages separate, 12 additional states appear for the 2nd stage mechanics. They need all to be initialized. This can definitely be hand-written if one wants an example, and it could be reduced to 1-dimensional movement and 2 states. I am not volunteering to write this, though :-).