Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable saving the entire simulation state in memory and restoring it again #768

Closed
kyllingstad opened this issue Jul 4, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@kyllingstad
Copy link
Member

I had originally intended this as a subtask of #757, which is about persisting the entire simulation state to disk, but after working on #756, I've found that it makes more sense to have it as a separate issue.

In essence, this issue is about implementing similar functionality as in #756, only on the full-system level. Here, we also need to export the state of the algorithm.

@kyllingstad kyllingstad added the enhancement New feature or request label Jul 4, 2024
@kyllingstad kyllingstad self-assigned this Jul 4, 2024
kyllingstad added a commit that referenced this issue Nov 25, 2024
This closes #768. Some changes may warrant a bit of extra explanation:

**`execution` and `algorithm`:** I have taken one step towards prohibiting adding/removing sub-simulators after the co-simulation has begun, as decided in #771.  In particular, I've added the `execution::initialize()` function, which marks the point where such changes are no longer allowed.  (This is a backwards-compatible change, because it gets automatically called by `execution::step()` if it hasn't been called manually.)

**`slave_simulator`**: The changes in `slave_simulator.cpp` really ought to have been included in #769. Unfortunately, I didn't realise they were necessary before it was all put into the context of saving algorithm and execution state.  Basically, I thought I could get away with just saving each FMU's internal state, but it turns out that we also need to save the `slave_simulator` "get" and "set" caches.

(For those interested in the nitty-gritties, this is due to some subtleties regarding exactly when the cache values are set in the course of a co-simulation, relative to when the values are passed to the FMU. At the end of an "algorithm step", the "set cache" is out of sync with the FMUs input variables, and won't be synced before the next step. Simply performing an additional sync prior to saving the state is not sufficient, because that could have an effect on the FMUs output variables, thus invalidating the "get cache". That could in principle be updated too, but then the `slave_simulator` is in a whole different state from where it was when we started to save the state.)
@kyllingstad
Copy link
Member Author

Closed by #777.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant