4. Workflow to Establish a MultiApps Simulation

Identification of Physical Phenomena and Their Domains

The first step when designing a MultiApps based simulation is to identify the physical phenomena that need to be modeled, and their spatial and time domains.

For a reactor system, neutronics is expected to be the essential (and usually dominant) physics. Heat conduction and thermal hydraulics are important in solid and fluid reactor components, respectively. The performance of specific reactor components, such as fuel, heat pipes, and coolant channels, may involve unique physical behaviors that need to be simulated separately. Meanwhile, diffusion controlled chemical reactions can exist in different regions of reactors.

Once all the physical phenomena of interest as well as the corresponding variables (i.e., physical quantities) and PDEs are identified, the corresponding space and time domains of these physical phenomena also need to be identified. The domain information is important to the determination of MultiApps hierarchy.

Figure 1: Identify all the physical phenomena to be simulated and their domains.

We take the VTB Sodium Fast Reactor (SFR) case as an example. It is focused on reactor assembly analysis of SFR considering thermal expansion. The physical phenomena that need to be modeled are illustrated in Figure 1 along with their space domains. Neutronics needs to be simulated for the entire assembly. Detailed thermal physics is required in the fuel region, including computation of fuel temperatures and axial fuel expansion governed by tensor mechanics (reactivity is sensitive to these quantities). Thermal hydraulics of the assembly coolant is needed to support the fuel temperature simulation. Lastly, the radial expansion of the assembly structure also needs to be computed, which is mainly controlled by the thermal expansion of the supporting grid plate of the assembly.

Selection of MOOSE Apps

Once the important physics has been identified, appropriate MOOSE-based (or MOOSE-wrapped) applications need to be selected to solve them. Chapter 3 discusses different MOOSE applications and their respective focuses in detail. The MOOSE Framework is equipped with a number of commonly used physics-dedicated applications termed Physics Modules. Many common physical phenomena, such as heat conduction and tensor mechanics, can be handled by these openly available MOOSE modules. However, to solve those physical phenomena that involve more complex physics phenomena or require advanced properties/models, a dedicated MOOSE application may need to be adopted. Some common MOOSE applications can be found here.

To make these physical modules and applications work together in a MultiApps system, users can either dynamically load the libraries of the child applications in the parent application, or directly use a pre-compiled super application such as BlueCRAB and Direwolf. Licensing for coupled applications (BlueCRAB and Direwolf) can be obtained through INL's NCRC.

Figure 2: Identify all the MOOSE applications/modules that are needed.

Continuing with the VTB SFR case as an example, as shown in Figure 2, the neutronics can be handled by Griffin; the thermal and tensor mechanics of the fuel region can be simulated using BISON; the thermal expansion of the supporting plate can be simulated using the MOOSE Tensor Mechanics module; and the coolant channel's thermal hydraulics can be simulated using the heat structure models in SAM.

Interconnection between Physical Phenomena

With the physics and corresponding MOOSE applications identified, the next step is to figure out the data that need to be exchanged between the different physics (i.e., corresponding to each MOOSE application). This is the key step to connecting multiple single physics problems into a single multiphysics problem. With these data exchanges, which happen through the MOOSE transfer system, the physical phenomena are eventually "coupled".

Figure 3: Identify the data exchanges needed to achieve coupling.

We consider the dependencies among the physics in the VTB SFR case, as shown in Figure 3. Generally, neutronics will need temperature (particularly in fuel and coolant regions) and displacement information from other apps to account for reactivity feedback. The thermal physics of the fuel needs power density (heat source) from neutronics and it calculates the temperature distribution. This is important not only to account for the thermal reactivity feedback on the neutronic solution, but also to be used by a tensor mechanics app for thermal expansion and thermal stress calculations. Finally, the fuel region needs to exchange thermal information with coolant region to simulate the heat sink effects.

Selection of Transfer Methods

A great variety of Transfers methods are available to users in MOOSE; even more options are available through other MOOSE apps. Different Transfers methods are designed to match different data transfer needs. There are generally three categories of data involved in MOOSE simulations: scalar data, array (vector) of scalars data, and field data. Transfers are covered in additional detail in Chapter 6 of this tutorial.

Scalar data in MOOSE mainly include Scalar variables and Postprocessors. The scalar-to-scalar transfer is usually straightforward. Depending on the scalar data types on both sides of the transfer, MultiAppScalarToAuxScalarTransfer, MultiAppPostprocessorTransfer, MultiAppPostprocessorToAuxScalarTransfer, etc.

Array (vector) of scalars data are mainly VectorPostprocessors in MOOSE. MultiAppVectorPostprocessorTransfer transfers values from parent app VectorPostprocessors to child application Postprocessors or vice versa.

MOOSE's Reporter system allows more general types of single values (VectorPostprocessors and Postprocessors are just two special types of Reporter). Reporter values can be transferred between parent and child apps using MultiAppReporterTransfer. Note that VectorPostprocessor-to-VectorPostprocessor transfer can be achieved using MultiAppReporterTransfer, instead of MultiAppVectorPostprocessorTransfer.

More challenging and complex are the transfer of field data. Field data in MOOSE are usually Variables or AuxVariables (sometimes also UserObjects). The most straightforward case would be that the parent and child apps use the same mesh. In that case, both nodal and elemental field data can be directly transferred using MultiAppCopyTransfer. More generally, the meshes used by parent and child apps are different. In some cases, using the field data value of the nearest node is enough, which can be achieved by MultiAppNearestNodeTransfer. Alternatively, interpolation based on multiple nearest nodes is used during the transfer using MultiAppGeometricInterpolationTransfer. Moreover, in some cases, the conservation of the integrated field data value is required, where MultiAppProjectionTransfer should be adopted leveraging projection and an on-the-fly calculated adjusting factor.

If child applications are established at multiple positions, field data of the parent app may need to be sampled and transferred to each child application (usually as scalar data), or vice versa. Based on the different type of field data and different algorithm, MultiAppShapeEvaluationTransfer(both directions), MultiAppPostprocessorInterpolationTransfer(from child application only), MultiAppUserObjectTransfer(to child application only), MultiAppVariableValueSamplePostprocessorTransfer(to child application only), and MultiAppVariableValueSampleTransfer(to child application only).

For the SFR single assembly example, Figure 6 visualizes how the five apps involved are tested.

The field variable power_density calculated by Griffin is transferred to Bison thermal physics simulation using MultiAppProjectionTransfer as this transfer conserves the integrated power, leveraging projection to minimize difference between the integrated power and an adjusting factor based on the given postprocessor (i.e., from_postprocessors_to_be_preserved and to_postprocessors_to_be_preserved) to .

For the temperature variable from heat conduction and thermal hydraulics applications, as well as the displacement variables from tensor mechanics application, MultiAppGeometricInterpolationTransfer is used to ensure proper values can be obtained when meshes are different. Because the thermal physics application and the tensor mechanics applications use an identical mesh, field variables such as temperature and displacements are transferred by MultiAppCopyTransfer.

The data transfer between the thermal physics application (BISON) and the thermal hydraulics (SAM) application is special. Although both applications use 2D-RZ axisymmetric meshes, the applications are oriented in different coordinate systems. In BISON, the convention is that the R mesh exists in the XZ plane, while in SAM, the convention is that R mesh exists in the XY plane. MultiAppCoordSwitchNearestNodeTransfer (a SAM object) performs transfers with coordinate system conversion along with the nearest node transfer. Native support is also present in MOOSE for most coordinate-transformations during transfers.

Since Transfers can be time and resource consuming, optimization in Transfers methods can make the simulation more efficient. For example, the transferred data can be limited to some essential blocks instead of the entire mesh to reduce data volume, or the position-sensitive transfer such as nearest point transfers can use a recorded map instead of doing search every time if the source and destination meshes do not move or deform significantly.

Figure 6: MultiApps testing with dummy apps.

If things are all set correctly, the output with dummy parent/child apps should be the same as the standalone testing. Once the single applications are verified to work properly with dummy parent and child apps, these single apps are ready to be assembled together.