Closed lindsayad closed 1 month ago
Components could hold metadata, much like mesh generators do right now. In fact components could be able to use MGs to create their own meshes
Extracting the components system into its own module only makes sense to me if we intend to use the components system for non-TH applications as well.
I will try to pitch this to Reactor & Griffin team next time we meet. I think it's a great idea.
@joshuahansel sometimes you have to build it and then they will come
@rui-hu @snschune
To start off some discussion, what's the advantage of some app like Griffin using components?
For shielding, it would be good to have a bunch of discontinuous meshes because that's all that s needed in most cases. They could be tied to components. That way you do not need to remesh the whole thing when you change one part.
If the contact between the meshes is important for thermo-mechanics for example, then we could say:
mesh = mesh_1:<list of blocks>
for each component and use that same continuous mesh in TM
For transfers as well, keeping the data local to a component makes sure we don't send data that s unrelated, and it speeds it up because there's less source data to consider.
In general, a plant is a collection of components, not a giant mesh. It would very much simplify our workflow for modeling plant systems if we recognized that in how we create the physics
Agreed, I think that any time where you have multiple physical pieces in your domain, components make a lot of sense.
Closing because I think the Physics/ActionComponents systems fill this role.
Reason
thermal_hydraulics
module and SAM components can use the component basics in the new moduleDesign
We will know the design is successful if there is no more need for
SAMComponent
,AddSAMComponentAction
, andSAMSimulation
Impact
A component system that we know is very generic