Demonstrate Cardinal controlling OpenMC geometry

[gonuke]

Reason

In order to perform a criticality search with multiphysics feedback in Cardinal, it will necessary for Cardinal to change parameters of some surfaces. This issue seeks to demonstrate the ability to do this as a single change (i.e. not yet as part of a root-finding search).

Design

The following need to be considered in the design:

• What kind of change will be supported, namely translation vs rotation
• A mechanism for the user to specify which surface must change and which parameter of that surface must change
• Direct calls to the openmc library to cause those changes at an appropriate in the cycle of mapping/remapping mesh to cells

A test would include

• creating a minimum working geometry for an OpenMC + MOOSE HTM simulation, A
• manually creating a variation on that minimum working geometry, B
• perform Cardinal calculations with A & B
• perform Cardinal calculations with A with 0 change applied - confirm that it matches A
• perform Cardinal calculation with A modified to match B - confirm that it matches B

Consideration should be given to whether this is implemented as an absolute change in a geometric parameter vs a relative change. In the latter, it may be necessary to read the parameters from the OpenMC geometry before applying the change.

Impact

This will add optional user input to control changes to geometry without changes to topology.

Additional Context

A general solution to this is likely too complicated; it may be best to develop a single specific case such as:

• translate a single surface in a single dimension
• rotate a single surface around a given axis of rotation

From these examples, more complicated examples can be pursued in separate issues:

• translate multiple surfaces
• rotate multiple surfaces

[aprilnovak]

A specific idea for an MWE: We can change the OpenMC geometry on each Picard iteration if we specify the displacements and use a DAGMC-based model. We could prove equivalence of the following:

• Create a DAGMC model of a cube over 0 < x < 1, 0 < y < 1, 0 < z < 1, and apply displacements from Cardinal of displacement_x = x*t. This will move the surface originally at x=1 as a function of time. As the cube changes shape, we compute different tallies.
• Create a CSG model of the same initial cube, but change the position of the original x=1 surface using the new proposed system.
• If the tallies are identical between these two, I would consider this proof that the new implementation is correct (because we have separately verified the DAGMC-moving-geometry functionality against standalone OpenMC calculations).

This doesn't have to be the MWE, but is probably how I'd approach proving it if it were me.

[gonuke]

It seemed simpler to me to just compare against standalone OpenMC calculations

[aprilnovak]

Yes, definitely simpler - the only downside is that the seed in Cardinal keeps running, so you wouldn't be able to compare identically (only within statistics). The method I proposed would match identically. But either case is fine by me

[gonuke]

Yes, definitely simpler - the only downside is that the seed in Cardinal keeps running, so you wouldn't be able to compare identically (only within statistics). The method I proposed would match identically. But either case is fine by me

Hmmm... I'll have to learn more about that.

[gonuke]

Many/most/all surface operations are a specific functions of the given surface type. This makes it challenging to implement a generic surface translation capability in Cardinal.

Option a: add "displace" method to every OpenMC surface to allow for it to be displaced (not unrelated to the recent openmc-dev/openmc#3491)

Option b: be more limiting on the types of surfaces that can be translated on the Cardinal side, either with a different UserObject or with logic within a single UserObject

[gonuke]

Should have pinged @pshriwise in the above comment...

[gonuke]

May make the most sense to pivot to moving whole universes within cells rather than moving individual surfaces.