FMICodeGenerator should handle and maintain states properly.
With "states", we need to distinguish between a) just regular states and b) integrated continuous variables.
a) This is handled already automatically. Whenever you store a value in any of the data maps
m_boolVar
m_realVar
m_integerVar
m_stringVar
these are stored and maintained in the FMU instance class object from one doStep() call to the next. Also, these states are stored in calls to serializeFMUstate() and restored in deserializeFMUstate(). Even if the master copies the FMU state and stores it into a file and later re-creates the FMU instance and restores data back from external memory - these states are restored as well.
b) support for continues variables is pending - for now a workaround would be to "reuse" the m_realVar map, but for larger fields this would be bad for performance. The plan is to add some integration library (CVODE?) into the code generator and then provide some integration functionality inside the FMU as well.
FMICodeGenerator should handle and maintain states properly.
With "states", we need to distinguish between a) just regular states and b) integrated continuous variables.
a) This is handled already automatically. Whenever you store a value in any of the data maps
these are stored and maintained in the FMU instance class object from one doStep() call to the next. Also, these states are stored in calls to
serializeFMUstate()and restored indeserializeFMUstate(). Even if the master copies the FMU state and stores it into a file and later re-creates the FMU instance and restores data back from external memory - these states are restored as well.b) support for continues variables is pending - for now a workaround would be to "reuse" the m_realVar map, but for larger fields this would be bad for performance. The plan is to add some integration library (CVODE?) into the code generator and then provide some integration functionality inside the FMU as well.