Improved initialization about fmi-standard HOT 12 CLOSED

Comment by Torsten Blochwitz on 4 Dec 2009 09:03 UTC
We suggest to have two functions. One is called only once and can be used for one time initializations. The other one might be called iteratively.
We agree that this could be too much work now and should be shifted.

from fmi-standard.

Comment by Martin Otter on 4 Dec 2009 17:51 UTC
Here are some comments from an email from Johan Akesson:

If you would like to enable initialization algorithms outside of an FMI dll to be interfaced with the model, then I think that the actual equation systems for the initialization system needs to be exposed in the same way as the ODE. In a sense, there is an asymmetry here: the simulation algorithm is assumed to be *outside* of an FMI dll whereas the initialization algorithm is assumed to be *inside* an FMI dll. As I mentioned before, it is often not sufficient for optimization purposes to obtain only the solution to the initialization system; the initial equations may contain optimization parameters. You will find the definition used in JModelica.org at http://www.jmodelica.org/api-docs/jmi/group__Jmi.html under the heading "The DAE initialization interface". Of course, this would be more complicated when taking discrete variables and hybrid behavior into account. Exposing the initialization equations would of course still permit a default initialization scheme to be provided inside the dll.

from fmi-standard.

Comment by Martin Otter on 6 Dec 2009 17:08 UTC
Due to time limitations, we will not manage an improved initialization scheme, especially because a test implementation is important here. Therefore, moved this to the next FMI version.

from fmi-standard.

Modified by dietmarw on 19 Mar 2012 09:26 UTC

from fmi-standard.

Modified by dietmarw on 19 Mar 2012 09:28 UTC

from fmi-standard.

Modified by dietmarw on 7 Sep 2012 10:18 UTC

from fmi-standard.

Comment by torstenblochwitz on 3 Dec 2012 23:59 UTC
Proposal from the Waterloo FMI meeting: Introduce a new function fmiCompletedInitialization functions which informs the FMU about finished initialization. After fmiInitialize and before this function call fmiGetXXX, fmiSetXXX function calls are allowed. Inside the FMU the initial equations are active in this stage. We have to introduce a new state to the state machine of calling sequence "initial Evaluation", which is entered by fmiInitializeModel/Slave and left by fmiCompletedInitialization.

May be we need a capabilty flag for this feature, at least for Co-Simulation.

Remark: Normally in initialization phase conditions are allowed to switch. This should not happen, when fmiSetXX and fmiGetXX are called for computation of a numeric Jacobian or residuals during solution of a system of equations during initialization. For that reason we propose to allow such discrete changes only during a special function call. We propose to use fmiEventUpdate for that.

from fmi-standard.

Changelog removed by torstenblochwitz on 3 Dec 2012 23:59 UTC

from fmi-standard.

Comment by torstenblochwitz on 1 Feb 2013 15:52 UTC
In order to illustrate the Waterloo proposal I have added the attachement StateMachine_Initialization.pdf. It contains an extension of the statemachine for calling sequence for Model Exchange. The new state "instantiated" is a substate of "modelInitialized" because it can be left by fmiTerminate.

When I was drawing the statemachine I have noticed the fallowing inaccuracies:

• in state "instantiated" setting of all Parameters is allowed. For that reason I replaced fmiGetP by fmiSetP in my extension.
• additionally in state "instantiated" setting of inputs should be allowed too. I have added these calls too.
• in state "eventPending" setting of continuous inputs should be possible too. This should be added to the statemachine.
  I have added the drawing to a new page in StateMachines.odg on svn.

Additionally I propose to include the capability flag "completedIninitializationNotNeeded" with the following explanation:

If true, function fmiCompletedInitialization needs not to be called. This leads to a simpler initialization routine. If it is called, it has no effect. If false (the default), the function must be called after initialization process is completed, see section XXX.

This is similar to the flag "completedIntegratorStepNotNeeded".

from fmi-standard.

Comment by torstenblochwitz on 7 Feb 2013 14:31 UTC
Discusion: Seems to be the right solution.

Lev: What about setting of time?
Torsten: Has to be set before.

Decision: Torsten will write complete proposal for spec.

from fmi-standard.

Comment by muehlbauer on 26 Feb 2013 14:30 UTC
I updated the drawing for cosimulation in StateMachines.odg (also the .png but not in the spec itself) on svn in accordance to the changes described above for model exchange:

• in state "intantiated" fmiGetP also has to be replaced by fmiSetP
• new state "slaveInitialized"
• new function "fmiCompletedIteration", which can be called iteratively.
  In my mind, the changes only make sense together w/ the capability flag "completedInitializationNotNeeded" suggested above.
  However, I think the names are quite vague. I would prefer "fmiInitializeIteratively" and "supportIterativeInitialization", for instance.
  Please note that for cosimulation it is the master's job to decide when to stop the iterative initialization based on the values received by fmiGetX. Hence, this is not part of the fmi spec.

from fmi-standard.

Comment by otter on 11 Oct 2013 09:39 UTC
This has been fixed in FMI 2.0 RC1 for ModelExchange and CoSimulation by introducing fmiEnterInitializationModel and fmiExitInitializationMode and optionally allow iteration via fmiSet/fmiGet between these function calls.

from fmi-standard.