MOOSE Newsletter (February 2024)

N-to-M siblings transfer in MultiAppGeneralFieldTransfer

The MultiAppGeneralFieldTransfer-derived classes can now perform arbitrary N-to-M siblings transfer. Siblings transfer are transfer between two multiapps without copying any information on the parent application. This flexibility enables more efficient multiphysics coupling, and generally facilitates the setup of multiphysics simulation in which each physics solve is segregated in a separate MultiApp.

New Application syntax block

The Application syntax was introduced into MOOSE. The Application block is utilized to explicitly specify the application type used for the input file. The application type should be provided using the "type" parameter under the block. The Application block is parsed before the MOOSE application is actually built. If any mismatch between the registered application type and the user-selected type is detected, the system will immediately throw an error and stop the setup of the simulation. The Application block supports MultiApps and can be used to replace the command-line option --app <AppName>. When a combined application is given, the user can choose only to run one of the dependent applications by providing the specific dependent application type in Application block.

Solid mechanics module

The Tensor Mechanics module has been renamed to the Solid Mechanics module. The tensor mechanics module started out as an alternative implementation of the solid mechanics equation from the old solid mechanics module. The old solid mechanics module was removed in 2020. Four years later, we expect that re-using the solid mechanics module name will not cause much, if any, disruption.

Concurrently, the following syntax changes were made for the major Actions in the module. For example, the main action was changed from:

[Modules]
  [TensorMechanics]
    [Master]
     ...

to the new syntax:

[Physics]
  [SolidMechanics]
    [QuasiStatic]
     ...

Summary of syntax changes:

Lower dimensional aux vars in boundary restricted aux kernels

Users may now populate auxiliary variables living on lower dimensional blocks through auxiliary kernels applied on boundaries coincident with the lower-d blocks. This allows, for instance, use of face material property evaluations in computation of the lower-d aux var. This work also led to

• robustification of some framework level objects against the possiblity of "late" remote element deletion, including PiecewiseConstantFromCSV and ElementalVariableValue.

• explicity initializing relationship managers (RMs) with the MooseMesh the RM is logically associated with. This ensures that, if an RM uses data from the MooseMesh for ghosting determination, the behavior is sane.