NekRSMesh

Construct a mirror of the NekRS mesh in boundary and/or volume format

Description

This class constructs a "mirror" mesh of the NekRS domain as a MooseMesh so that other MOOSE applications can send/receive data to/from this mesh using MOOSE Transfers. When data is read from NekRS, NekRSProblem directly accesses solution arrays in NekRS and interpolates them onto the NekRSMesh mirror. When data is written into NekRS, it is read from a MooseVariable on the NekRSMesh and interpolated directly into boundary condition and source arrays in NekRS.

A mesh mirror can be constructed for

  • Just the NekRS boundaries. This can be used when only boundary coupling/data is desired, such as for Conjugate Heat Transfer (CHT).

  • The entire NekRS volume. This can be used when only volume coupling/data is desired, such as for temperature and density coupling to MOOSE.

  • The entire NekRS volume and boundaries. This is the most general mirror, and can be used for concurrent boundary and/or volume coupled, such as for combined CHT and volume coupling to BISON and OpenMC, respectively.

For each choice of mesh domain, there are three options for the "resolution" of the mesh mirror:

  • first order, or HEX8 elements (for volume mirrors) or QUAD4 elements (for boundary mirrors)

  • second order, or HEX27 elements (for volume mirrors) or QUAD elements (for boundary mirrors)

  • "exact" order, which will represent the NekRS high-order mesh exactly using HEX8 elements (for volume mirrors) or QUAD4 elements (for boundary mirrors).

Boundary Mesh Mirror

In boundary mode, NekRSMesh will read the nodes associated with all NekRS elements on a set of specified boundaries and then build an equivalent MooseMesh of either first or second order. For example, suppose your NekRS mesh is the one shown in Figure 1; a boundary with ID 2 is indicated. The mesh lines in Figure 1 are shown connecting the GLL quadrature points in NekRS (not the eight nodes that would be needed to define the corners of a hexahedral element).

Figure 1: Example NekRS mesh; mesh lines are shown connecting GLL points

The three different types of mesh mirrors are shown in Figure 2. White dots are shown to indicate the nodes for the first two mesh mirrors (too many nodes would clutter the image if we showed the nodes for the exact mesh mirror as well).

Figure 2: Three different mesh mirrors for boundary 2 in the NekRS mesh from Figure 1

  • First-order mesh mirrors are selected with order = FIRST, giving the first mesh mirror in Figure 2. NekRS's boundary elements are converted to QUAD4. That is, if NekRS uses a polynomial order of 7, data transfers between the mesh mirror and NekRS's mesh would involve interpolations on each element between NekRS quadrature points and 4 MOOSE nodes.

  • Second-order mesh mirrors are selected with order = SECOND, giving the second mesh mirror in Figure 2. NekRS's boundary elements are converted to QUAD9. That is, if NekRS uses a polynomial order of 7, data transfers between the mesh mirror and NekRS's mesh would involve interpolations on each element between NekRS quadrature points and 9 MOOSE nodes.

  • An "exact" mesh mirror is selected with exact = true, giving the third mesh mirror in Figure 2. For each NekRS boundary element, we build QUAD4 elements.

The boundary IDs in boundary correspond to the boundary IDs in the NekRS mesh, i.e. in the .re2 file. You can set multiple boundaries to construct by passing a vector of sideset IDs; this will add multiple boundaries into the same mirror mesh.

[Mesh]
  type = NekRSMesh
  boundary = '1 2 3 4 5 6'
[]
(test/tests/postprocessors/nek_weighted_side_integral/nek.i)
warningwarning

When a boundary mesh mirror is constructed using NekRSMesh, the actual sidesets associated with the original mesh are lost. For instance, setting boundary = '1 2' will construct a mesh mirror consisting of the elements on boundaries 1 and 2 in the NekRS mesh, but those boundary IDs are not preserved in the mirror. This is a limitation of libMesh, because sideset names cannot be associated with 2-D elements - only with faces of 3-D elements. However, this has not yet been a limitation in Cardinal, because we can still perform operations based on NekRS sideset IDs through the various Nek postprocessors in Cardinal. If these postprocessors do not meet your needs, you can retain NekRs sideset IDs when constructing a volume mesh; please see Volume Mesh Mirror and Volume and Boundary Mesh Mirrors for details.

Volume Mesh Mirror

In volume mode, NekRSMesh will read the nodes associated with the entire NekRS mesh and then build an equivalent MooseMesh. Again using the Figure 1 as an example NekRS mesh, the three different types of mesh mirrors are shown in Figure 3. White dots are shown to indicate the nodes for the first two mesh mirrors (too many nodes would clutter the image if we showed the nodes for the exact mesh mirror as well).

Figure 3: Three different mesh mirrors for the entire volume of the NekRS mesh from Figure 1

  • First-order mesh mirrors are selected with order = FIRST, giving the first mesh mirror in Figure 3. NekRS's elements are converted to HEX8. That is, if NekRS uses a polynomial order of 7, data transfers between the mesh mirror and NekRS's mesh would involve interpolations on each element between NekRS quadrature points and 8 MOOSE nodes.

  • Second-order mesh mirrors are selected with order = SECOND, giving the second mesh mirror in Figure 3. NekRS's elements are converted to HEX27. That is, if NekRS uses a polynomial order of 7, data transfers between the mesh mirror and NekRS's mesh would involve interpolations on each element between NekRS quadrature points and 27 MOOSE nodes.

  • An "exact" mesh mirror is selected with exact = true, giving the third mesh mirror in Figure 3. For each NekRS element, we build HEX8 elements.

If creating a mesh mirror in volume mode, the sideset IDs from the NekRS mesh will be constructed in the mesh mirror.

Volume and Boundary Mesh Mirrors

Combined volume and boundary mesh mirrors are used for:

  • Combined CHT and volume coupling of NekRS to MOOSE

Combining the volume and boundary modes is achieved by setting both volume = true and specifying the CHT boundaries with the boundary parameter. The resulting volume mesh mirror will contain all the sidesets of the NekRS mesh (because as described in Volume Mesh Mirror , all sidesets are automatically created in volume mesh mirrors), and also set up necessary mapping data structures to facilitate CHT to the NekRS boundaries specified with the boundary parameter.

For instance, the following code snippet will generate a second-order volume mesh and sideset 2 will be coupled via CHT to MOOSE.

[Mesh]
  type = NekRSMesh
  order = SECOND
  volume = true
  boundary = '2'
[]

Other Features

When NekRS is run in non-dimensional form, the .re2 mesh will also be in non-dimensional units. In this case, to ensure that the mesh mirror that handles data transfers to/from dimensional coupled MOOSE applications (such as BISON) can correctly map the data in space, a scaling factor must be applied to the mesh mirror.

For example, consider a hypothetical case where NekRS solves for flow in a domain of size 5 m 5 m. Suppose that the characteristic length is taken as m; in this case, the mesh in the .re2 file should be of size to properly set up the nondimensional formulation. When the mesh mirror is constructed, if no adjustments are made, the mesh mirror will extend over a range of - but will be coupled to a MOOSE application that probably selects a length scale as meters - not a nondimensional scale. So, to convert the mesh mirror back to dimensional units, the scaling parameter is used. For this example, if the coupled MOOSE application solves in units of meters, then scaling should be set to 5 to dimensionalize the non-dimensional NekRS mesh. Generally, scaling should be set to the same value used to "scale" the mesh when using the exo2nek program.

Input Parameters

  • add_subdomain_idsThe listed subdomains will be assumed valid for the mesh. This permits setting up subdomain restrictions for subdomains initially containing no elements, which can occur, for example, in additive manufacturing simulations which dynamically add and remove elements.

    C++ Type:std::vector<unsigned short>

    Controllable:No

    Description:The listed subdomains will be assumed valid for the mesh. This permits setting up subdomain restrictions for subdomains initially containing no elements, which can occur, for example, in additive manufacturing simulations which dynamically add and remove elements.

  • add_subdomain_namesOptional list of subdomain names to be applied to the ids given in add_subdomain_ids. This list must contain the same number of items as add_subdomain_ids.

    C++ Type:std::vector<SubdomainName>

    Controllable:No

    Description:Optional list of subdomain names to be applied to the ids given in add_subdomain_ids. This list must contain the same number of items as add_subdomain_ids.

  • allow_renumberingTrueIf allow_renumbering=false, node and element numbers are kept fixed until deletion

    Default:True

    C++ Type:bool

    Controllable:No

    Description:If allow_renumbering=false, node and element numbers are kept fixed until deletion

  • boundaryBoundary ID(s) through which nekRS will be coupled to MOOSE

    C++ Type:std::vector<int>

    Controllable:No

    Description:Boundary ID(s) through which nekRS will be coupled to MOOSE

  • build_all_side_lowerd_meshFalseTrue to build the lower-dimensional mesh for all sides.

    Default:False

    C++ Type:bool

    Controllable:No

    Description:True to build the lower-dimensional mesh for all sides.

  • coord_blockBlock IDs for the coordinate systems. If this parameter is specified, then it must encompass all the subdomains on the mesh.

    C++ Type:std::vector<SubdomainName>

    Controllable:No

    Description:Block IDs for the coordinate systems. If this parameter is specified, then it must encompass all the subdomains on the mesh.

  • exactFalseWhether the mesh mirror is an exact replica of the NekRS mesh

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Whether the mesh mirror is an exact replica of the NekRS mesh

  • fluid_block_id0Subdomain ID to use for the fluid mesh mirror

    Default:0

    C++ Type:unsigned int

    Controllable:No

    Description:Subdomain ID to use for the fluid mesh mirror

  • ghosting_patch_sizeThe number of nearest neighbors considered for ghosting purposes when 'iteration' patch update strategy is used. Default is 5 * patch_size.

    C++ Type:unsigned int

    Controllable:No

    Description:The number of nearest neighbors considered for ghosting purposes when 'iteration' patch update strategy is used. Default is 5 * patch_size.

  • max_leaf_size10The maximum number of points in each leaf of the KDTree used in the nearest neighbor search. As the leaf size becomes larger,KDTree construction becomes faster but the nearest neighbor searchbecomes slower.

    Default:10

    C++ Type:unsigned int

    Controllable:No

    Description:The maximum number of points in each leaf of the KDTree used in the nearest neighbor search. As the leaf size becomes larger,KDTree construction becomes faster but the nearest neighbor searchbecomes slower.

  • orderfirstOrder of the mesh interpolation between nekRS and MOOSE

    Default:first

    C++ Type:MooseEnum

    Options:first, second

    Controllable:No

    Description:Order of the mesh interpolation between nekRS and MOOSE

  • parallel_typeDEFAULTDEFAULT: Use libMesh::ReplicatedMesh unless --distributed-mesh is specified on the command line REPLICATED: Always use libMesh::ReplicatedMesh DISTRIBUTED: Always use libMesh::DistributedMesh

    Default:DEFAULT

    C++ Type:MooseEnum

    Options:DEFAULT, REPLICATED, DISTRIBUTED

    Controllable:No

    Description:DEFAULT: Use libMesh::ReplicatedMesh unless --distributed-mesh is specified on the command line REPLICATED: Always use libMesh::ReplicatedMesh DISTRIBUTED: Always use libMesh::DistributedMesh

  • scaling1Scaling factor to apply to the mesh

    Default:1

    C++ Type:double

    Controllable:No

    Description:Scaling factor to apply to the mesh

  • skip_refine_when_use_splitTrueTrue to skip uniform refinements when using a pre-split mesh.

    Default:True

    C++ Type:bool

    Controllable:No

    Description:True to skip uniform refinements when using a pre-split mesh.

  • solid_block_id1Subdomain ID to use for the solid mesh mirror

    Default:1

    C++ Type:unsigned int

    Controllable:No

    Description:Subdomain ID to use for the solid mesh mirror

  • volumeFalseWhether the nekRS volume will be coupled to MOOSE

    Default:False

    C++ Type:bool

    Controllable:No

    Description:Whether the nekRS volume will be coupled to MOOSE

Optional Parameters

  • alpha_rotationThe number of degrees that the domain should be alpha-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

    C++ Type:double

    Controllable:No

    Description:The number of degrees that the domain should be alpha-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

  • beta_rotationThe number of degrees that the domain should be beta-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

    C++ Type:double

    Controllable:No

    Description:The number of degrees that the domain should be beta-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

  • gamma_rotationThe number of degrees that the domain should be gamma-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

    C++ Type:double

    Controllable:No

    Description:The number of degrees that the domain should be gamma-rotated using the Euler angle ZXZ convention from https://en.wikipedia.org/wiki/Euler_angles#Rotation_matrix in order to align with a canonical physical space of your choosing.

  • length_unitHow much distance one mesh length unit represents, e.g. 1 cm, 1 nm, 1 ft, 5inches

    C++ Type:std::string

    Controllable:No

    Description:How much distance one mesh length unit represents, e.g. 1 cm, 1 nm, 1 ft, 5inches

  • up_directionSpecify what axis corresponds to the up direction in physical space (the opposite of the gravity vector if you will). If this parameter is provided, we will perform a single 90 degree rotation of the domain--if the provided axis is 'x' or 'z', we will not rotate if the axis is 'y'--such that a point which was on the provided axis will now lie on the y-axis, e.g. the y-axis is our canonical up direction. If you want finer grained control than this, please use the 'alpha_rotation', 'beta_rotation', and 'gamma_rotation' parameters.

    C++ Type:MooseEnum

    Options:X, Y, Z

    Controllable:No

    Description:Specify what axis corresponds to the up direction in physical space (the opposite of the gravity vector if you will). If this parameter is provided, we will perform a single 90 degree rotation of the domain--if the provided axis is 'x' or 'z', we will not rotate if the axis is 'y'--such that a point which was on the provided axis will now lie on the y-axis, e.g. the y-axis is our canonical up direction. If you want finer grained control than this, please use the 'alpha_rotation', 'beta_rotation', and 'gamma_rotation' parameters.

Transformations Relative To Parent Application Frame Of Reference Parameters

  • coord_typeXYZType of the coordinate system per block param

    Default:XYZ

    C++ Type:MultiMooseEnum

    Options:XYZ, RZ, RSPHERICAL

    Controllable:No

    Description:Type of the coordinate system per block param

  • rz_coord_axisYThe rotation axis (X | Y) for axisymmetric coordinates

    Default:Y

    C++ Type:MooseEnum

    Options:X, Y

    Controllable:No

    Description:The rotation axis (X | Y) for axisymmetric coordinates

  • rz_coord_blocksBlocks using general axisymmetric coordinate systems

    C++ Type:std::vector<SubdomainName>

    Controllable:No

    Description:Blocks using general axisymmetric coordinate systems

  • rz_coord_directionsAxis directions for each block in 'rz_coord_blocks'

    C++ Type:std::vector<libMesh::VectorValue<double>>

    Controllable:No

    Description:Axis directions for each block in 'rz_coord_blocks'

  • rz_coord_originsAxis origin points for each block in 'rz_coord_blocks'

    C++ Type:std::vector<libMesh::Point>

    Controllable:No

    Description:Axis origin points for each block in 'rz_coord_blocks'

Coordinate System Parameters

  • centroid_partitioner_directionSpecifies the sort direction if using the centroid partitioner. Available options: x, y, z, radial

    C++ Type:MooseEnum

    Options:x, y, z, radial

    Controllable:No

    Description:Specifies the sort direction if using the centroid partitioner. Available options: x, y, z, radial

  • partitionerdefaultSpecifies a mesh partitioner to use when splitting the mesh for a parallel computation.

    Default:default

    C++ Type:MooseEnum

    Options:default, metis, parmetis, linear, centroid, hilbert_sfc, morton_sfc

    Controllable:No

    Description:Specifies a mesh partitioner to use when splitting the mesh for a parallel computation.

Partitioning Parameters

  • construct_node_list_from_side_listTrueWhether or not to generate nodesets from the sidesets (usually a good idea).

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Whether or not to generate nodesets from the sidesets (usually a good idea).

  • control_tagsAdds user-defined labels for accessing object parameters via control logic.

    C++ Type:std::vector<std::string>

    Controllable:No

    Description:Adds user-defined labels for accessing object parameters via control logic.

  • dim1This is only required for certain mesh formats where the dimension of the mesh cannot be autodetected. In particular you must supply this for GMSH meshes. Note: This is completely ignored for ExodusII meshes!

    Default:1

    C++ Type:MooseEnum

    Options:1, 2, 3

    Controllable:No

    Description:This is only required for certain mesh formats where the dimension of the mesh cannot be autodetected. In particular you must supply this for GMSH meshes. Note: This is completely ignored for ExodusII meshes!

  • enableTrueSet the enabled status of the MooseObject.

    Default:True

    C++ Type:bool

    Controllable:No

    Description:Set the enabled status of the MooseObject.

  • nemesisFalseIf nemesis=true and file=foo.e, actually reads foo.e.N.0, foo.e.N.1, ... foo.e.N.N-1, where N = # CPUs, with NemesisIO.

    Default:False

    C++ Type:bool

    Controllable:No

    Description:If nemesis=true and file=foo.e, actually reads foo.e.N.0, foo.e.N.1, ... foo.e.N.N-1, where N = # CPUs, with NemesisIO.

  • patch_size40The number of nodes to consider in the NearestNode neighborhood.

    Default:40

    C++ Type:unsigned int

    Controllable:No

    Description:The number of nodes to consider in the NearestNode neighborhood.

  • patch_update_strategyneverHow often to update the geometric search 'patch'. The default is to never update it (which is the most efficient but could be a problem with lots of relative motion). 'always' will update the patch for all secondary nodes at the beginning of every timestep which might be time consuming. 'auto' will attempt to determine at the start of which timesteps the patch for all secondary nodes needs to be updated automatically.'iteration' updates the patch at every nonlinear iteration for a subset of secondary nodes for which penetration is not detected. If there can be substantial relative motion between the primary and secondary surfaces during the nonlinear iterations within a timestep, it is advisable to use 'iteration' option to ensure accurate contact detection.

    Default:never

    C++ Type:MooseEnum

    Options:never, always, auto, iteration

    Controllable:No

    Description:How often to update the geometric search 'patch'. The default is to never update it (which is the most efficient but could be a problem with lots of relative motion). 'always' will update the patch for all secondary nodes at the beginning of every timestep which might be time consuming. 'auto' will attempt to determine at the start of which timesteps the patch for all secondary nodes needs to be updated automatically.'iteration' updates the patch at every nonlinear iteration for a subset of secondary nodes for which penetration is not detected. If there can be substantial relative motion between the primary and secondary surfaces during the nonlinear iterations within a timestep, it is advisable to use 'iteration' option to ensure accurate contact detection.

Advanced Parameters

Input Files