Enable exporting and importing subsimulator state #769
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a follow-up to #765 and the second and final step to close #756. Here, I've implemented functionality to export the internal state of individual subsimulators in a generic, structured form, and to import them again later. This exported form is intended as an intermediate step before serialisation and disk storage. The idea was to create a type that can be inspected and serialised to almost any file format we'd like. The type is defined by `cosim::serialization::node` in `cosim/serialization.hpp`. It is a hierarchical, dynamic data type with support for a variety of primitive scalar types and a few aggregate types: strings, arrays of nodes, dictionaries of nodes, and binary blobs. (Think JSON, only with more types.)
Closed
2 tasks
|
Hm. Seems like my little trick of storing an incomplete |
|
Ok, I made it work now. It seems that to make a recursive map-like data type in standard C++, one has to hide the internal type, for example by messing about with |
kyllingstad
commented
Jul 9, 2024
| @@ -290,8 +291,6 @@ class slave | |||
| * `state_index`. The index is only valid for this particular slave. | |||
| * | |||
| * The function may be called at any point after `setup()` has been called. | |||
| * | |||
| * \pre `this->model_description().can_save_state` | |||
There was a problem hiding this comment.
This and the removal on lines 304–305 was just something I missed in #765.
davidhjp01
requested changes
Oct 8, 2024
davidhjp01
approved these changes
Oct 9, 2024
Closed
2 tasks
kyllingstad
added a commit
that referenced
this pull request
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.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a follow-up to #765 and the second and final step to close #756. It is part of a PR series which will culminate in the implementation of #757, and until that point, I am targeting the
dev/state-persistencebranch rather thanmaster.Here, I've implemented functionality to export the internal state of individual subsimulators in a generic, structured form, and to import it again later.
This exported form is intended as an intermediate step before serialisation to disk. The idea was to create a type that can be inspected and serialised to almost any file format we'd like.
The type is defined by
cosim::serialization::nodeincosim/serialization.hpp. It is a hierarchical, dynamic data type with support for a variety of primitive scalar types and a few aggregate types: strings, arrays of nodes, dictionaries of nodes, and binary blobs. (Think JSON-like structure, only in-memory and with more types.)Edit:
nodewas originally a homebrew type. Now, it is based on Boost.PropertyTree. Otherwise, the description above still fits pretty well.