Handling Constraints in ModelExchange

[modelica-trac-importer]

Reported by akorobkine on 11 Jul 2013 19:59 UTC After investigating FMUChecker-2.0a1/FMUChecker-2.0a2 (ModelExchange branch) we have found that fmiGetContinuousStates is not called after the call to fmiCompletedIntegratorStep, unless there are events present in the system. This is a possible problem if the system has constraints and the states could change their values during the call to fmiCompletedIntegratorStep, but the master will possibly not have the correct (updated) values for the states.

Here are the possible solutions to the above issue:

(1) Adding the following call (unconditionaly): fmistatus = fmi2_import_get_continuous_states(fmu, states, n_states);

right after the call to fmi2_import_completed_integrator_step(fmu, &callEventUpdate) and prior to event handling in the FMUChecker seems to fix the above issue.

(2) Another possible fix (on the FMU generation side) is to add in a dummy event for any model that has constraints, to force the client to call fmiGetContinuousStates at the end of every step (when the events run).

(3) It may be that constraint handling should be made explicit in the FMI spec, by addition of a new function, e.g. fmiApplyProjection, and a capability flag indicating that the FMU requires projection?

Looking at the above issue and the possible solutions to it, what is the preferred way to handle systems with constraints in the FMU environment?

Thanks,

Alex/Maplesoft

---

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

[modelica-trac-importer]

Comment by iakovn on 14 Oct 2013 09:33 UTC In my opinion ME FMU as per current spec is not supposed to modify its states during continuous integration and so (2) is currently the only way to implement this. The problem is that event handling will restart the integrator, which is not desirable if the only operation is state projection (i.e., small modification of continuous states).

I believe (3) is needed to support this properly. It may be enough with a capability flag and a requirement that fmiGetContinuousStates should be called after fmiCompletedIntegratorStep if this flag is set.

[modelica-trac-importer]

Comment by otter on 14 Oct 2013 11:21 UTC The FMI 1.0 and 2.0 interface is for ODEs with embedded algebraic equations. It is not for DAEs and not for overdetermined ODEs or DAEs. There is a plan to support residues in FMI 2.1 (so mix of ODEs and DAEs) additionally. At the same time also overdetermined DAEs/ODEs could be supported as well (so projecting on a constraint). However, all this seems to be outside of FMI 2.0.

Still overdetermined ODEs can be handled in a clean way in FMI 2.0 (but maybe not as efficient as it could be; but not supporting DAEs seems to be much more critical for multi-body systems):

1. Call fmiCompletedIntegratorStep after each step.
2. If a projection is needed (so not in every step, but only if the constraint is violated too much), set the return argument enterEventMode = true and mark in the FMU that a projection is needed.
3. The environment triggers an event and during the event handling the FMU performs the project, changes the states, and informs the environment that the states have changed.
4. The environment inquires the new state vector and re-initializes its solver with its new states.

I changed the milestone to FMI 2.1 because the issue can be handled in FMI 2.0 and one might analyze the problem again for the FMI 2.1 development whether a more efficient solution is needed.

[modelica-trac-importer]

Comment by mfriedrich on 12 Feb 2015 18:54 UTC The last comment of otter seem for me to be the only correct solution of state projection and this way it is already possible in FMI 1.0. Of course, resetting the integrator after state projection (minimal state change) is not desirable due to performance reasons, but i do not see a way out here since, at least, for multistep integration methods just setting a new state is not enough due to the other previous states being store in the integrator internally.

[modelica-trac-importer]

Comment by cbertsch on 1 Jun 2018 12:45 UTC Check if this is covered by the DAE FCP.

[chrbertsch]

Now that FMI 3.0 is released, there is a new window of opportunity to bring DAE Support in FMI 3.x.

Prerequisite would be an active working group that would agree on a solution approach (e.g., provision of residuals, or projection methods), solve the remaining issues (e.g., initialization), and provide a concrete proposal that fits to FMI 3.

@friedrichatgc , @MartinOtter , @masoud-najafi , @TorstenBlochwitz and other "friends of FMI with DAE support": what do you think, and are you willing to bring this forward?

[MartinOtter]

This is a very good idea. I will not have much time, but will try to give comments/suggestions.

[friedrichatgc]

Comment by otter on 14 Oct 2013 11:21 UTC The FMI 1.0 and 2.0 interface is for ODEs with embedded algebraic equations. It is not for DAEs and not for overdetermined ODEs or DAEs. There is a plan to support residues in FMI 2.1 (so mix of ODEs and DAEs) additionally. At the same time also overdetermined DAEs/ODEs could be supported as well (so projecting on a constraint). However, all this seems to be outside of FMI 2.0.

Still overdetermined ODEs can be handled in a clean way in FMI 2.0 (but maybe not as efficient as it could be; but not supporting DAEs seems to be much more critical for multi-body systems):

1. Call fmiCompletedIntegratorStep after each step.

2. If a projection is needed (so not in every step, but only if the constraint is violated too much), set the return argument enterEventMode = true and mark in the FMU that a projection is needed.

3. The environment triggers an event and during the event handling the FMU performs the project, changes the states, and informs the environment that the states have changed.

4. The environment inquires the new state vector and re-initializes its solver with its new states.

I changed the milestone to FMI 2.1 because the issue can be handled in FMI 2.0 and one might analyze the problem again for the FMI 2.1 development whether a more efficient solution is needed.

I fully agree with this comment. fmiCompletedIntegratorStep is exactly for this purpose. This approach already works with FMI 1.0 and I have already implemented this successfully. Making projections after every step is not an requirement for me (due to performance reasons). Other stabilization techniques like Baumgarte stabilization can also be implemented with current FMI 1.0. So, I don't see a need for extending the ODE interface for FMI 1.0 and 2.0