Allowing updating state variables after initialization, for Hybrid Co-Simulation

[modelica-trac-importer]

Reported by peter.nilsson on 24 Sep 2012 13:07 UTC For FMI 2.0 Beta-4, after initialization only inputs and tunable parameters may be set via fmiSetXXX. For co-simulation there are reasons to allow also updates of states and discrete state variables after initialization.

One example of an use-case is to change both parameters and states as part of a tuning operation; another example is if the model is part of a predictive controller where the states are estimated from measurements.

---

Migrated-From: https://trac.fmi-standard.org/ticket/94

[modelica-trac-importer]

Comment by anonymous on 4 Oct 2012 07:31 UTC Peter, for Co-Simulation, setting of continuous states is not allowed at all. The FMU solver (which is part of the FMU in Co-Simulation case) is responsible for setting of continuous states. Additionally, setting of discrete state variables after initialization is not allowed at all. Discrete state variables (which can be local variables only) are handled handled internally by the FMU in Co-Simulation and Model Exchange case. Best regards Torsten

[modelica-trac-importer]

Comment by otter on 3 Dec 2012 01:45 UTC The setting of continuous and discrete states is needed for, e.g., nonlinear Kalman filters. However, here more functionality is needed in FMI 2.0, and there will not be enough time to provide this in FMI 2.0. Therefore, this ticket is moved to FMI 2.1.

[modelica-trac-importer]

Comment by tsnouidui on 6 Oct 2015 20:18 UTC Page 55 of the specification says that a co-simulation (2.0) FMU does not need to expose state derivatives in element <Derivatives>.

If that is the case, I wonder how an import tool could

a) determine which variables are state variables, and b) use this information to reinitialize state variables (using fmi2SetFMUState) for let's say Model Predictive Controls applications.

Does this information need to be mandatory similar to Model Exchange?

Also on page 58 of the specification, it is written that for Co-Simulation, element "Derivatives" is ignored if capability flag providesDirectionalDerivative has a value "false". Why is the definition of this element bounded to a capability flag?

Thanks!

Thierry

[modelica-trac-importer]

Comment by cbertsch on 1 Jun 2018 12:21 UTC Does the last comment already answer the question? --> Clarify in 2.0.1? (Related to Hybrid Co-Simulation Proposal?)

[modelica-trac-importer]

Comment by andreas.junghanns on 1 Jun 2018 12:26 UTC The fastest way to make progress is to add changes right into the 2.0.1 document as proposals. If we keep this discussion in the tickets, it requires an extra step to build this document.

[KarlWernersson]

Since this is an enhancement I don't see this as an 2.0.1 issue, Proposal, move to 3.0

[KarlWernersson]

I do not see what should be clarified for 2.0.1

[KarlWernersson]

fix in hybrid co-sim

[chrbertsch]

Is this a feature request for basic co-simulation (BCS) or hybrid co-simulation (HCS)?

@APillekeit , @jbernalr and other HCS team members: If I understand the current spec (https://fmi-standard.org/docs/3.0-dev/#_state_event_mode) correctly, the setting (continuous) state variables is still not possible in HCS. Would it be possible to allow this in event mode of HCS? Or do you have other comments on this issues and how it could be realized with FMI 3.0

[masoud-najafi]

In FMI-3.0, nothing has been changed concerning the update of internal states of an FMU for XCS.

[andreas-junghanns]

In FMI-3.0, nothing has been changed concerning the update of internal states of an FMU for XCS.

But do you think we should allow such a change right after init for CS and if yes, for which types?

[chrbertsch]

In FMI 3.0 in HCS, setting of discrete states in event mode is possible https://fmi-standard.org/docs/3.0-dev/#fmi3NewDiscreteStates.

As mentioned above, in xCS FMU, continuous states are not exposed and cannot be set. So I propose to close this of move it from "FMI 3.0" "future".

However, in https://fmi-standard.org/docs/3.0-dev/#fmi3GetFMUState we mention for the funtion fmi3GetFMUState and fmi3SetFMUState the use case of nonlinear Kalman filters, just in the motivation above. However, to my understanding, with fmi3SetFMUState, the internal structure of the FMUState is a secret of the FMU, right? How could this then be used to set the continuous states of the FMU?

@KarlWernersson , @masoud-najafi , @MartinOtter and others: could you please comment?

[masoud-najafi]

I agree that it is very interesting to access (set and get) continuous and/or discrete states in xCS. Consider, for example, getting the linear representation of the CS model. But currently there is no way to distinguish states from other local variables in xCS, unless we allow using <Derivatives> in the XML similar to ME. If we want to support this, we should allow setting continuous and discrete states, during initialization. This should be discuss broadly in a meeting. Concerning fmi3SetFMUState and fmi3GetFMUState, they are irrelevant to internal continuous and discrete states.

[KarlWernersson]

Well, if model structure/derivatives is used the states are exposed. So that functionality is already there Then one could use setFloat64 directly if one wants to avoid the function setContinousStates function for co-sim/hy-cosim

If some tool vendors think it would be hard to support this, introduce a flag, "canSetContinousTimeStates" and you are done.

So this would only require minimal changes to the standard.

[chrbertsch]

@MartinOtter , @AndreasPfeiffer @KarlWernersson and others: Wouldn't this feature be needed to support nonlinear state observers with BCS FMUs?

Currently we state in https://fmi-standard.org/docs/3.0-dev/#get-set-fmu-state for fmi3SetFMUState

Examples for using this feature: .. For nonlinear Kalman filters (get the FMU state just before initialization; in every sample period, set new continuous states from the Kalman filter algorithm based on measured values; integrate to the next sample instant and inquire the predicted continuous states that are used in the Kalman filter algorithm as basis to set new continuous states).

But I do not see how to do this, as the internal structure of what you get with fmi3GetFMUState is a secret of the FMU.

[KarlWernersson]

@chrbertsch This article was published quite a while ago https://www.ep.liu.se/ecp/096/005/ecp14096005.pdf

In this we utilized the modelStructure of the FMU, and allowed setReal explicitly on states. In fact you can still do this with dymoal cs FMU's today as i havent seen a good reason to explicitly forbid it.

[AndreasPfeiffer]

In Section 3.1 of the above mentioned article (https://www.ep.liu.se/ecp/096/005/ecp14096005.pdf) we describe what is additionally to the FMI standard 2.0 needed for applying a FMU for Co-Simulation to nonlinear Kalman filters:

• The continuous-time states have to be reported in the modelDescription.xmlfile under element ModelStructure (sufficient to do it indirectly by marking the derivatives as ). Remark: In the current FMI spec. of FMI 3.0, in Section https://fmi-standard.org/docs/3.0-dev/#ModelStructure there we have: "A Model Exchange FMU must expose all derivatives of its continuous-time states in elements <ModelStructure><Derivative> and must expose all event indicators in elements <EventIndicator>. A Co-Simulation FMU does not need to expose these state derivatives and event indicators." It means, it is possible to get the necessary information for a FMU for Co-Simulation, if the exporting tools is supporting it - and only then.
• It has to possible to explicitly set the continuous-time states with fmiSetReal before fmiDoStep is called. Remark: I do not see, that this is allowed in FMI 3.0 (also not allowed in FMI 2.0), see the table of allowed fmi-function in the different modes.
• It has to be possible to inquire the actual values of all variables with fmiGetReal after fmiSetReal was called, without an fmiDoStep in between (e.g. compute outputs depending on continuous states without doing an integration step). This also includes evaluating the derivatives, alternatively the function fmiGetDerivatives has to be supported. Remark: I also do not see, that this is allowed in FMI 3.0 (also not allowed in FMI 2.0), see the table of allowed fmi-function in the different modes.

If FMUs exported by Dymola support most of the features, then this is different to explictly support it in the FMI standard and I do not see, that is is sufficient to just introduce one flag into the current version of the FMI standard. In summary, I think there are some requirements for nonlinear Kalman filtering, that are not fulfilled by the current FMI specification - at least I do not see it as @chrbertsch.

[chrbertsch]

I am wondering, whether the event mode of HCS would not be the right place to support the functionality of getting outputs and derivatives directly after setting them. If we would allow getting outputs and derivatives in StepMode of A BCS FMU directly after setting the inputs we would break with the basic concept of BCS, that the computations take place in the doStep method. (see https://fmi-standard.org/docs/3.0-dev/#state-step-mode-co-simulation:

It is not allowed to call fmi3Get{VariableType} functions after fmi3Set{VariableType} functions without an fmi3DoStep call in between.

[The reason is to avoid different interpretations of the caching, since contrary to FMI for Model Exchange, fmi3DoStep will perform the actual calculation instead of fmi3Get{VariableType}, and therefore, dummy algebraic loops at communication points cannot be handled by an appropriate sequence of fmi3Get{VariableType} and, fmi3Set{VariableType} calls as for Model Exchange.]

Is it allowed to call the fmi3SetFloat64 and fmi3GetFloat64 functions in event mode of HCS? I see in https://fmi-standard.org/docs/3.0-dev/#_handling_a_successful_early_return_by_the_co_simulation_master_in_hybrid_co_simulation

In Event Mode it is allowed to call fmi3Get{VariableType} after fmi3NewDiscreteStates has been called and it is allowed to call fmi3Set{VariableType} before calling fmi3NewDiscreteStates. The FMU leaves Event Mode when the master calls fmi3EnterStepMode.

fmi3NewDiscreteStatesTYPE even has an argument valuesOfContinuousStatesChanged. So what is missing support the "nonlinear state estimator" use case with HCS making use of the event mode? This seems to me to be better fittting than BCS.

perhaps the name fmi3NewDiscreteStatesTYPE is misleading and should be fmi3NewStatesTYPE or fmi3AdvanceSuperDenseTimeTYPE

@AndreasPfeiffer , @KarlWernersson, @TorstenBlochwitz, @MartinOtter @masoud-najafi @CSchulzeTLK and others: could you please comment?

[chrbertsch]

FMI Design Meeting Recommendation to put this in a layered standard that uses some non-standard extensions of FMI, indicated in an annotation. An importer can ignore the layered standard completely

@KarlWernersson, @otronarp ?, @chrbertsch will work on a proposal. @pmai will support regarding the aspect of a layered standard

[aisak7]

Hello,

After read the post im a bit confused yet, and im not clear about the next question:

• is it possible to modify local values on ModelExchange after initialization

• in the other hand, is there any way to access to the states of the integrator defined in the model via any function?

thank u very much.

[chrbertsch]

• is it possible to modify local values on ModelExchange after initialization

This ticket is about Co-Simulation FMUs

• in the other hand, is there any way to access to the states of the integrator defined in the model via any function?

what do you mean with access? You can "get" any exposed varaible with fmi3getXXX. But this ticket is aboubt setting state variables.

[aisak7]

Hello @chrbertsch,

I know this is not the right place to ask for, and apologizes for it. but I can’t find any help out here.

I’m exporting FMU model with Amesim with high values exposed, what means I can see every variable inside the model, including the states from integrators, the thing is all those variables are declared as local, so I can’t modify any of them, I have tried to use fmi2setreal but this give me an error about “valueReference doesn’t exist”, but that’s not true, because I can see that variable in the xml, and that’s why I’m asking if local values can be changed some way working under model exchange.

here is the stack overflow post: https://stackoverflow.com/questions/66633258/fmi-amesim-can-be-modified-local-variables-under-modelexchange

Thanks for ur help.

[chrbertsch]

I know this is not the right place to ask for, and apologizes for it. but I can’t find any help out here.

@aisak7: Please contact you AMESim support and/or use a platform like stackoverflow to ask such usage or tool related questions https://stackoverflow.com/questions/tagged/fmi

[DavideDega]

Hello @AndreasPfeiffer and @chrbertsch, I've read your article relative to the implementation of EKF in the FMU. Right now I am trying to implement it for the estimation of the attitude of a satellite. Unfortunatively I am running in the following problem: Basically the attitude is defined using quaternions as states and when I write the fmiSetReal command (in Dymola) to update the corresponding state of the FMU I get: [fmi2Warning]: FMU_name: fmiSetReal: may not change #rState# at this stage, setting of variable ignored. Consequently no update of the state is performed. I find it strange becaouse this procedure works with other states like position but doen't work with orientation. Do you have any clue on why this is happening? There is a way to ignore such warning and overwrite it ? Thank you in advance for any feedback.

[MartinOtter]

Hello @AndreasPfeiffer and @chrbertsch, I've read your article relative to the implementation of EKF in the FMU. Right now I am trying to implement it for the estimation of the attitude of a satellite. Unfortunatively I am running in the following problem: Basically the attitude is defined using quaternions as states and when I write the fmiSetReal command (in Dymola) to update the corresponding state of the FMU I get: [fmi2Warning]: FMU_name: fmiSetReal: may not change #rState# at this stage, setting of variable ignored. Consequently no update of the state is performed. I find it strange becaouse this procedure works with other states like position but doen't work with orientation. Do you have any clue on why this is happening? There is a way to ignore such warning and overwrite it ? Thank you in advance for any feedback.

Potential reason: If the quaternions are defined with Modelica, then this is an overdetermined set of states and Dymola uses dynamic state selection to reduce from 4 to 3 states during simulation (I guess this is done inside the FMU). It is not possible to update such states from a user side.

[DavideDega]

Thx @MartinOtter. I see that in the output of the simulation (under the section state select) and I've only three elements. I am able to modify such states. Thank you a lot for the comment.

[brazilbruno]

@KarlWernersson @AndreasPfeiffer I'm not sure if this is the right place to ask. I am trying to implement a UKF using a co-simulation FMU exported from Dymola, and imported in Python using the FMPy package. I have thoroughly read the paper you mentioned and have tried implementing it accordingly, but I have run into some problems.

After initialization, it is possible to set continuous states using setReal. And after setting the states, it is also possible to use getReal and get the variable outputs, so far so good. The problem arises when you have a variable input (varies with time) inside the FMU. The FMU needs to have its internal time moved forward, so after the last sigma-point is calculated, the state of the FMU must not be reversed. But when it is not reversed (by using setFMUstate()), it is no longer possible to use setReal and update the continuous states. The workaround I have used is to reset the FMU after each measurement step and then use the setupExperiment function with the current simulation time as input, but this leads to a considerable change in runtime. Is there a workaround, or am I missing something?

I would really appreciate the help!

[KarlWernersson]

Hi @brazilbruno Sorry for the delayed response. In general, Dymola fmu's are not so strict with the standard regarding resetting values and computing them without doStep so this often works. If you have issues there i would recommend to contact Dymola support for further assistance.