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
I have opened this discussion as I'm now organising the implementation plan for the 3.0 restructure, based on that we seem to be more keen to explore this approach.
Overview
We can break down this restructure into two aspects:
Multiphysics simulations
Sort out the code structure issues on 2.0
The benefit is that these tasks can be broken down into subsections and are decoupled from each other, which inherently means they're progressively implementable.
The ethos of this approach is:
Have all "nice user interface features" decoupled from the actual "solvers".
We don't have to replace the existing simulations, but we are providing a space to move all the "highly coupled" user functionality into a dedicated "multiphysics user-specific" class.
We want to have clear interfaces which improve maintainability of coupling relationships, we want to enable extensibility of the physical coupling we want to represent in a microservice-esque development scheme.
High Level View
Lower Level View
Implementation Considerations
Assumptions
These assumptions are based on the feedback sessions with the solver team, product directions, conversations I have had, Tyler’s core concept:
We want to manage the multi-solver coupling in the frontend.
Each solver in the backend can be treated as a self-contained solver.
If strong coupling is designed between solvers in the backend, this is treated as another self-contained solver as defined by a CouplingSpec .
Hence, the scalability of maintenance of each solver is linear and self-contained. Coupling definitions and supported relationships are frontend-defined.
We want to maintain as most compatibility with 2.0 as possible.
We want to maintain class methods linked and easy to access by the user.
We do not want to move solver methods outside of classes, and make classes more typing based, and methods to operate on this types essentially, and hence method compatibility scalability inherently depends on inheritance/repeatability rather than functional typing extensions.
IMPORTANT: Coupled simulations require coupled property monitors for the entire simulation region.
Architectural Theory
We want to do the opposite of inheritance, we want to “compose” our simulations out of smaller building blocks. The goal is that this allows us to manage coupling in a more defined way.
General Important Changes
A “multi-physics simulation” composes a the physics we want to represent from “single solver simulations”.
Possibly, to some level, some aspect of parallel batch multi-physics simulations can be enabled depending on the type of coupling from previous solver results.
A “multi-solver simulation scheduler” manages the creation of simulation tasks. This is constructed out of a CouplingSpec
A “grid/multi-solver interpolation utility” handles all the translation methods between the solvers. The idea is to move the structure of the PerturbationMediums into a dedicated supported section.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have opened this discussion as I'm now organising the implementation plan for the 3.0 restructure, based on that we seem to be more keen to explore this approach.
Overview
We can break down this restructure into two aspects:
The benefit is that these tasks can be broken down into subsections and are decoupled from each other, which inherently means they're progressively implementable.
The ethos of this approach is:
High Level View
Lower Level View
Implementation Considerations
Assumptions
These assumptions are based on the feedback sessions with the solver team, product directions, conversations I have had, Tyler’s core concept:
We want to manage the multi-solver coupling in the frontend.
Each solver in the backend can be treated as a self-contained solver.
CouplingSpec
.Architectural Theory
General Important Changes
CouplingSpec
PerturbationMediums
into a dedicated supported section.Beta Was this translation helpful? Give feedback.
All reactions