Question: Restoring FMU state across sessions for perpetual/batch simulation fails with access violation

[prafull-cognite]

Summary:
I am running a perpetual simulation using FMPy and a Co-Simulation FMU (FMI 2.0, Python 3.12, Windows). My workflow is to process real data in batches: I run the simulation on the currently available data, then pause and save the FMU state. When new data arrives (which could be hours or days later), I want to resume the simulation from exactly where I left off by restoring the saved state.

What I am trying:

• Save the FMU state after running the simulation for some time (not just after initialization).
• Store the FMU state bytes to disk (using pickle or direct file write).
• Later, after a kernel restart or process termination, re-instantiate the FMU from the same .fmu file, and try to restore the saved state using deSerializeFMUstate and setFMUstate.

Problem:

• When I try to restore the FMU state in a new Python session (after re-instantiating the FMU), I get:

  OSError: exception: access violation writing 0xXXXXXXXXXXXXXXX
  

Questions:

• Is it possible to serialize an FMU state after simulation has advanced, and later restore it into a new FMU instance (across sessions or kernel restarts)?
• Does FMPy or the FMI 2.0 standard support this use case for Co-Simulation FMUs?
• If not, is there a recommended approach for running perpetual simulations with batch data, where each run may be separated by hours or days?
• If this is a limitation of the FMU implementation, can FMPy detect and provide a clearer error or warning?

Environment:

• FMPy version: latest
• FMU type: Co-Simulation (FMI 2.0)
• Python version: 3.12
• OS: Windows

Thank you for your help!

[t-sommer]

Is it possible to serialize an FMU state after simulation has advanced, and later restore it into a new FMU instance (across sessions or kernel restarts)?

Yes. See https://github.com/CATIA-Systems/FMPy/blob/main/tests/test_fmu_state.py for an example.

Does FMPy or the FMI 2.0 standard support this use case for Co-Simulation FMUs?

Yes.

If this is a limitation of the FMU implementation, can FMPy detect and provide a clearer error or warning?

Can you share an example to reproduce the problem?

[prafull-cognite]

Thanks for the looking into this @t-sommer , I could be doing something wrong then. But good to know that there is support for state preservation across sessions!

see the notebook for example here, Cannot share the actual FMU as it is a proprietary design. But sharing the FMU details below:

Model Info

FMI Version 2.0
FMI Type Co-Simulation
Model Name AiotelFMU_v3
Description None
Platforms linux64, win32, win64
Continuous States 270
Event Indicators 194
Variables 16297
Generation Tool Dymola Version 2023 (64-bit), 2022-04-13 (using Dassl with tolerance 0.0001)
Generation Date 2025-07-23T12:59:05Z

Default Experiment

Stop Time 200000.0
Tolerance 0.0001