search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.78k stars 1.05k forks source link

QoI unit transformations #21550

Open lindsayad opened 2 years ago

lindsayad commented 2 years ago

Reason

12293 covers mesh transformations, e.g. being able to identify coordinates that establish spatial relationships between different applications in MultiApp settings. For instance #12293 outlines what nodes data should be transferred between a 3D Griffin neutronics calculation and a 2D RZ BISON fuel performance calculation whose up-direction is different.

However, identifying what points to transfer between is only half the battle. Now we have to perform the data transfers ... and if the canonical units for QoIs are different between applications, then #12293 on its own does not address this. @vincentlaboure brought up transferring power density which has units of Power/Volume. Power or more commonly Volume can have different units between applications. We want to be able to handle that.

Design

Maybe denote QoI units in the input files? E.g. units parameters in Variables and Postprocessors sub-blocks?

Impact

Make it so folks crafting multiphysics simulation inputs don't have to think about different unit systems in different applications.

vincentlaboure commented 2 years ago

I like the idea of having an optional parameter for Variables/AuxVariables that the user could potentially change (in the case of the power density however, Griffin already constructs it through an action so it would be done automatically there). Postprocessors should be able to determine the unit automatically (based on the mesh unit and whether an integration is performed on a volume, sideset, etc.) so users shouldn't have to mess with that directly. I guess SpatialUO would also have to be smart about it (e.g. LayeredAverage keeps the unit of the original variable but LayeredIntegral/LayeredSideIntegral don't).