You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the RKWrapper assumes a linear workflow through the majority of the simulation construction process. For example, it does not store individual model objects, and instead adds their dictionary representation to its internal configuration state. This means that it is difficult or impossible to retrieve added models for potential removal, modification, or detailed reference.
Ideally, an improved design would store all of the objects necessary to build the configuration file in such a way that the individual components can be changed or removed without rebuilding the entire wrapper. This would likely require redesigning the majority of ReMKiT1D objects to enable their modification.
Given the breaking nature of this redesign, it is almost certain that a new wrapper class should be added instead of modifying the existing wrapper to enable the backwards compatibility with current linear workflows.
The text was updated successfully, but these errors were encountered:
The current v1.2.0 ReMKiT1D workflow requires an RKWrapper, or at least its VariableContainer and Grid, both at the start and the end of the workflow. RKWrapper lives entirely within RMK_support, while the config.json file generated from it ultimately contains all the ingredients of a simulation.
In future it should be made possible to recover an RKWrapper, or at least VariableContainer and Grid, from an existing config.json. This may be necessary if that config.json file cannot be regenerated, such as if the original generator script is lost, or if that generator uses randomisation or other external/prior dependencies like in ML workflows.
What breaks backwards compatibility of config.json files with RMK_support is the some of the changes that RMK core makes to config.json at runtime, such as converting both Variables and Variable-like Modelbound Data into matching constructs (as the underlying list structure is the same for both in RMK core). The property "isSingleHarmonic" is used only for Varlike MB data and not for Variables within RMK_Support, for example.
For now, if the user wants to attempt regenerating VariableContainer from a config.json file, they need to keep a clean copy of config.json for RMK_Support to handle only, while allowing core ReMKiT1D to work with another copy.
At the moment, the RKWrapper assumes a linear workflow through the majority of the simulation construction process. For example, it does not store individual model objects, and instead adds their dictionary representation to its internal configuration state. This means that it is difficult or impossible to retrieve added models for potential removal, modification, or detailed reference.
Ideally, an improved design would store all of the objects necessary to build the configuration file in such a way that the individual components can be changed or removed without rebuilding the entire wrapper. This would likely require redesigning the majority of ReMKiT1D objects to enable their modification.
Given the breaking nature of this redesign, it is almost certain that a new wrapper class should be added instead of modifying the existing wrapper to enable the backwards compatibility with current linear workflows.
The text was updated successfully, but these errors were encountered: