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

Implement an improved version of the RKWrapper class to enable nonlinear workflows #36

Open
SMijin opened this issue Aug 16, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@SMijin
Copy link
Contributor

SMijin commented Aug 16, 2024

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.

@SMijin SMijin added the enhancement New feature or request label Aug 16, 2024
@SMijin SMijin self-assigned this Aug 16, 2024
@sleigh2022
Copy link
Collaborator

Some notes from earlier discussion on this topic:

  • 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.

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

No branches or pull requests

2 participants