Closed aprilnovak closed 1 year ago
Wouldn't it be both more simple and more efficient to add a density attribute to cells, similar to how temperature can be set either through the cell definition or through the material?
For example, if you ran on a mesh with thousands of elements representing water in a PWR assembly, and wanted to have variations in density throughout, you'd have to have different materials in each, right? That seems extremely inefficent. It would make far more sense to assign density multipliers in each cell.
That's on my long-term to-do list, but I unfortunately don't have the cycles right now for that. This is needed to support some current projects.
I like the idea of a density multiplier, though - that would be a lot less intrusive than wholesale replicating "density" on a Cell (like we do for temperature). I believe Serpent does a density multiplier approach.
In that case, adding the clone functionality seems pretty reasonable!
It's possible someone might use this for reasons other than multiphysics, too - it's a pretty generic capability, we are just using it as a stop-gap to a better density-lives-on-cell idea.
Thanks for the feedback!
Yes for sure, this would probably be the right solution if subdividing materials for depletion through C++.
In Cardinal, we need to be able to clone materials on-the-fly according to contours in density (we are creating new materials as-needed to represent density distributions coming from MOOSE). However, the
Material
constructor which reads from XML will error out if you call it > 1 time, with an error like:So, we need to be able to clone a material, but allow it to have an ID specified separately from what's in the XML file.
Option 1:
Material::clone()
Create a clone method on
Material
, by setting all the member variables ofMaterial
. This requires us to be careful if any members get added to Material, but is more general because it could be called at any point during the simulation and rebuild the Material in-place (as opposed to strictly the info specified in the XML files).Option 2: Refactor
Material::Material
As a second option, we could just refactor the
Material
constructor like:Then, from Cardinal we would set the ID ourself, and then call
read_mat_from_xml(node)
.