Mesh System

Overview

There are two primary ways of creating a mesh for use in a MOOSE simulation: "offline generation" through a tool like CUBIT from Sandia National Laboratories, and "online generation" through programmatic interfaces. CUBIT is useful for creating complex geometries, and can be licensed from Coreform for a fee depending on the type of organization and work being performed. Other mesh generators can work as long as they output a file format that is supported by the FileMesh object.

Example Syntax and Mesh Objects

Mesh settings are applied with the [Mesh] section in input files, for example the basic input file syntax for generating a simple square mesh is shown below. For additional information on the other types of Mesh objects refer to the individual object pages listed below.

[Mesh]
  [./square]
    type = GeneratedMeshGenerator
    nx = 2
    ny = 2
    dim = 2
  [../]
[]
(moose/test/tests/auxkernels/solution_aux/build.i)

Available Objects

  • Moose App
  • AddMetaDataGeneratorThis mesh generator assigns extraneous mesh metadata to the input mesh
  • AdvancedExtruderGeneratorExtrudes a 1D mesh into 2D, or a 2D mesh into 3D, can have a variable height for each elevation, variable number of layers within each elevation, variable growth factors of axial element sizes within each elevation and remap subdomain_ids, boundary_ids and element extra integers within each elevation as well as interface boundaries between neighboring elevation layers.
  • AllSideSetsByNormalsGeneratorAdds sidesets to the entire mesh based on unique normals.
  • AnnularMeshGeneratorFor rmin>0: creates an annular mesh of QUAD4 elements. For rmin=0: creates a disc mesh of QUAD4 and TRI3 elements. Boundary sidesets are created at rmax and rmin, and given these names. If dmin!0 and dmax!360, a sector of an annulus or disc is created. In this case boundary sidesets are also created at dmin and dmax, and given these names
  • BlockDeletionGeneratorMesh generator which removes elements from the specified subdomains
  • BlockToMeshConverterGeneratorConverts one or more blocks (subdomains) from a mesh into a stand-alone mesh with a single block in it.
  • BoundaryDeletionGeneratorMesh generator which removes side sets
  • BoundingBoxNodeSetGeneratorAssigns all of the nodes either inside or outside of a bounding box to a new nodeset.
  • BreakBoundaryOnSubdomainGeneratorBreak boundaries based on the subdomains to which their sides are attached. Naming convention for the new boundaries will be the old boundary name plus "_to_" plus the subdomain name
  • BreakMeshByBlockGeneratorBreak the mesh at interfaces between blocks. New nodes will be generated so elements on each side of the break are no longer connected. At the moment, this only works on a REPLICATED mesh
  • BreakMeshByElementGeneratorBreak all element-element interfaces in the specified subdomains.
  • CartesianMeshGeneratorThis CartesianMeshGenerator creates a non-uniform Cartesian mesh.
  • CircularBoundaryCorrectionGeneratorThis CircularBoundaryCorrectionGenerator object is designed to correct full or partial circular boundaries in a 2D mesh to preserve areas.
  • CoarsenBlockGeneratorMesh generator which coarsens one or more blocks in an existing mesh. The coarsening algorithm works best for regular meshes.
  • CombinerGeneratorCombine multiple meshes (or copies of one mesh) together into one (disjoint) mesh. Can optionally translate those meshes before combining them.
  • ConcentricCircleMeshGeneratorThis ConcentricCircleMeshGenerator source code is to generate concentric circle meshes.
  • CutMeshByPlaneGeneratorThis CutMeshByPlaneGenerator object is designed to trim the input mesh by removing all the elements on one side of a given plane with special processing on the elements crossed by the cutting line to ensure a smooth cross-section. The output mesh only consists of TET4 elements.
  • DistributedRectilinearMeshGeneratorCreate a line, square, or cube mesh with uniformly spaced or biased elements.
  • ElementGeneratorGenerates individual elements given a list of nodal positions.
  • ElementOrderConversionGeneratorMesh generator which converts orders of elements
  • ElementSubdomainIDGeneratorAllows the user to assign each element the subdomain ID of their choice
  • ElementsToSimplicesConverterSplits all non-simplex elements in a mesh into simplices.
  • ElementsToTetrahedronsConverterThis ElementsToTetrahedronsConverter object is designed to convert all the elements in a 3D mesh consisting only linear elements into TET4 elements.
  • ExamplePatchMeshGeneratorCreates 2D or 3D patch meshes.
  • ExplodeMeshGeneratorBreak all element-element interfaces in the specified subdomains.
  • ExtraNodesetGeneratorCreates a new node set and a new boundary made with the nodes the user provides.
  • FancyExtruderGeneratorExtrudes a 1D mesh into 2D, or a 2D mesh into 3D, can have a variable height for each elevation, variable number of layers within each elevation, variable growth factors of axial element sizes within each elevation and remap subdomain_ids, boundary_ids and element extra integers within each elevation as well as interface boundaries between neighboring elevation layers.
  • FileMeshGeneratorRead a mesh from a file.
  • FillBetweenCurvesGeneratorThis FillBetweenCurvesGenerator object is designed to generate a transition layer to connect two boundaries of two input meshes.
  • FillBetweenPointVectorsGeneratorThis FillBetweenPointVectorsGenerator object is designed to generate a transition layer with two sides containing different numbers of nodes.
  • FillBetweenSidesetsGeneratorThis FillBetweenSidesetsGenerator object is designed to generate a transition layer to connect two boundaries of two input meshes.
  • FlipSidesetGeneratorA Mesh Generator which flips a given sideset
  • GeneratedMeshGeneratorCreate a line, square, or cube mesh with uniformly spaced or biased elements.
  • ImageMeshGeneratorGenerated mesh with the aspect ratio of a given image stack.
  • ImageSubdomainGeneratorSamples an image at the coordinates of each element centroid, using the resulting pixel color value as each element's subdomain ID
  • LowerDBlockFromSidesetGeneratorAdds lower dimensional elements on the specified sidesets.
  • MeshCollectionGeneratorCollects multiple meshes into a single (unconnected) mesh.
  • MeshDiagnosticsGeneratorRuns a series of diagnostics on the mesh to detect potential issues such as unsupported features
  • MeshExtruderGeneratorTakes a 1D or 2D mesh and extrudes the entire structure along the specified axis increasing the dimensionality of the mesh.
  • MeshRepairGeneratorMesh generator to perform various improvement / fixing operations on an input mesh
  • MoveNodeGeneratorModifies the position of one or more nodes
  • NodeSetsFromSideSetsGeneratorMesh generator which constructs node sets from side sets
  • OrientedSubdomainBoundingBoxGeneratorDefines a subdomain inside or outside of a bounding box with arbitrary orientation.
  • OverlayMeshGeneratorCreates a Cartesian mesh overlaying the input mesh region.
  • ParsedCurveGeneratorThis ParsedCurveGenerator object is designed to generate a mesh of a curve that consists of EDGE2 elements.
  • ParsedElementDeletionGeneratorRemoves elements such that the parsed expression is evaluated as strictly positive. The parameters of the parsed expression can be the X,Y,Z coordinates of the element vertex average (must be 'x','y','z' in the expression), the element volume (must be 'volume' in the expression) and the element id ('id' in the expression).
  • ParsedExtraElementIDGeneratorUses a parsed expression to set an extra element id for elements (via their centroids).
  • ParsedGenerateNodesetA MeshGenerator that adds nodes to a nodeset if the node satisfies the expression expression.
  • ParsedGenerateSidesetA MeshGenerator that adds element sides to a sideset if the centroid of the side satisfies the combinatorial_geometry expression.
  • ParsedNodeTransformGeneratorApplies a transform to a the x,y,z coordinates of a Mesh
  • ParsedSubdomainMeshGeneratorUses a parsed expression (combinatorial_geometry) to determine if an element (via its centroid) is inside the region defined by the expression and assigns a new block ID.
  • PatchMeshGeneratorCreates 2D or 3D patch meshes.
  • PatternedMeshGeneratorCreates a 2D mesh from a specified set of unique 'tiles' meshes and a two-dimensional pattern.
  • PlaneDeletionGeneratorRemoves elements lying 'above' the plane (in the direction of the normal).
  • PlaneIDMeshGeneratorAdds an extra element integer that identifies planes in a mesh.
  • PolyLineMeshGeneratorGenerates meshes from edges connecting a list of points.
  • RefineBlockGeneratorMesh generator which refines one or more blocks in an existing mesh
  • RefineSidesetGeneratorMesh generator which refines one or more sidesets
  • RenameBlockGeneratorChanges the block IDs and/or block names for a given set of blocks defined by either block ID or block name. The changes are independent of ordering. The merging of blocks is supported.
  • RenameBoundaryGeneratorChanges the boundary IDs and/or boundary names for a given set of boundaries defined by either boundary ID or boundary name. The changes are independent of ordering. The merging of boundaries is supported.
  • RinglebMeshGeneratorCreates a mesh for the Ringleb problem.
  • SideSetExtruderGeneratorTakes a 1D or 2D mesh and extrudes a selected sideset along the specified axis.
  • SideSetsAroundSubdomainGeneratorAdds element faces that are on the exterior of the given block to the sidesets specified
  • SideSetsBetweenSubdomainsGeneratorMeshGenerator that creates a sideset composed of the nodes located between two or more subdomains.
  • SideSetsFromBoundingBoxGeneratorDefines new sidesets using currently-defined sideset IDs inside or outside of a bounding box.
  • SideSetsFromNodeSetsGeneratorMesh generator which constructs side sets from node sets
  • SideSetsFromNormalsGeneratorAdds a new named sideset to the mesh for all faces matching the specified normal.
  • SideSetsFromPointsGeneratorAdds a new sideset starting at the specified point containing all connected element faces with the same normal.
  • SmoothMeshGeneratorUtilizes a simple Laplacian based smoother to attempt to improve mesh quality. Will not move boundary nodes or nodes along block/subdomain boundaries
  • SphereMeshGeneratorGenerate a 3-D sphere mesh centered on the origin
  • SpiralAnnularMeshGeneratorCreates an annular mesh based on TRI3 or TRI6 elements on several rings.
  • StackGeneratorUse the supplied meshes and stitch them on top of each other
  • StitchBoundaryMeshGeneratorAllows a pair of boundaries to be stitched together.
  • StitchedMeshGeneratorAllows multiple mesh files to be stitched together to form a single mesh.
  • SubdomainBoundingBoxGeneratorChanges the subdomain ID of elements either (XOR) inside or outside the specified box to the specified ID.
  • SubdomainIDGeneratorSets all the elements of the input mesh to a unique subdomain ID.
  • SubdomainPerElementGeneratorAllows the user to assign each element the subdomain ID of their choice
  • SymmetryTransformGeneratorApplies a symmetry transformation to the entire mesh.
  • TiledMeshGeneratorUse the supplied mesh and create a tiled grid by repeating this mesh in the x, y, and z directions.
  • TransfiniteMeshGeneratorCreates a QUAD4 mesh given a set of corner vertices and edge types. The edge type can be either LINE, CIRCARC, DISCRETE or PARSED, with LINE as the default option. For the non-default options the user needs to specify additional parameters via the edge_parameter option as follows: for CIRCARC the deviation of the midpoint from an arccircle, for DISCRETE a set of points, or a paramterization via the PARSED option. Opposite edges may have different distributions s long as the number of points is identical. Along opposite edges a different point distribution can be prescribed via the options bias_x or bias_y for opposing edges.
  • TransformGeneratorApplies a linear transform to the entire mesh.
  • UniqueExtraIDMeshGeneratorAdd a new extra element integer ID by finding unique combinations of the existing extra element integer ID values
  • XYDelaunayGeneratorTriangulates meshes within boundaries defined by input meshes.
  • XYMeshLineCutterThis XYMeshLineCutter object is designed to trim the input mesh by removing all the elements on one side of a given straight line with special processing on the elements crossed by the cutting line to ensure a smooth cross-section.
  • XYZDelaunayGeneratorCreates tetrahedral 3D meshes within boundaries defined by input meshes.
  • AnnularMeshFor rmin>0: creates an annular mesh of QUAD4 elements. For rmin=0: creates a disc mesh of QUAD4 and TRI3 elements. Boundary sidesets are created at rmax and rmin, and given these names. If dmin!0 and dmax!360, a sector of an annulus or disc is created. In this case boundary sidesets are also created a dmin and dmax, and given these names
  • ConcentricCircleMeshThis ConcentricCircleMesh source code is to generate concentric circle meshes.
  • FileMeshRead a mesh from a file.
  • GeneratedMeshCreate a line, square, or cube mesh with uniformly spaced or biased elements.
  • ImageMeshGenerated mesh with the aspect ratio of a given image stack.
  • MeshGeneratorMeshMesh generated using mesh generators
  • PatternedMeshCreates a 2D mesh from a specified set of unique 'tiles' meshes and a two-dimensional pattern.
  • RinglebMeshCreates a mesh for the Ringleb problem.
  • SpiralAnnularMeshCreates an annual mesh based on TRI3 elements (it can also be TRI6 elements) on several rings.
  • StitchedMeshReads in all of the given meshes and stitches them all together into one mesh.
  • TiledMeshUse the supplied mesh and create a tiled grid by repeating this mesh in the x,y, and z directions.
  • Phase Field App
  • EBSDMeshGeneratorMesh generated from a specified DREAM.3D EBSD data file.
  • SphereSurfaceMeshGeneratorGenerated sphere mesh - a two dimensional manifold embedded in three dimensional space
  • EBSDMeshMesh generated from a specified DREAM.3D EBSD data file.
  • Heat Transfer App
  • PatchSidesetGeneratorDivides the given sideset into smaller patches of roughly equal size.

Available Subsystems

Available Actions

MeshGenerator System

The MeshGenerator System is useful for programmatically constructing a mesh. This includes generating the mesh from a serious of points and connectivity, adding features on the fly, linearly transforming the mesh, stitching together pieces of meshes, etc. There are several built-in generators but this system is also extendable. MeshGenerators may or may not consumer the output from other generators and produce a single mesh. They can be chained together through dependencies so that complex meshes may be built up from a series of simple processes.

Mesh Generator development

Mesh generator developers should call mesh->set_isnt_prepared() at the end of the generate routine unless they are confident that their mesh is indeed prepared. Examples of actions that render the mesh unprepared are

  • Translating, rotating, or scaling the mesh. This will conceptually change the mesh bounding box, invalidate the point locator, and potentially change the spatial dimension of the mesh (e.g. rotating a line from the x-axis into the xy plane, etc.)

  • Adding elements. These elements will need their neighbor links set in order for things like finite volume to work

  • Changing element subdomains. This will invalidate the mesh subdomain cached data on the libMesh::MeshBase object

  • Changing boundary IDs. This invalidates global data (e.g. data aggregated across all processes) in the libMesh::BoundaryInfo object

When in doubt, the mesh is likely not prepared. Calling set_isnt_prepared is a defensive action that at worst will incur an unnecessary prepare_for_use, which may slow down the simulation setup, and at best may save follow-on mesh generators or simulation execution from undesirable behavior.

DAG and final mesh selection

When chaining together several MeshGenerators, you are implicitly creating a DAG (directed acyclic graph). MOOSE evaluates and generates the individual objects to build up your final mesh. If your input file has multiple end points, (e.g. B->A and C->A) then MOOSE will issue an error and terminate. Generally, it doesn't make sense to have multiple end points since the output of one would simply be discarded anyway. It is possible to force the selection of a particular end point by using the "final_generator" parameter in the Mesh block. This parameter can be used on any generator whether there is ambiguity or not in the generator dependencies.

Outputting The Mesh

Since MOOSE contains a lot of ability to read/generate/modify meshes - it's often useful to be able to run all of the Mesh related portions of the input file and then output the mesh. This mesh can then be viewed (such as with Peacock) or used in other MOOSE input files for further combination/modification.

This can be achieved by using the command line option --mesh-only. By default --mesh-only will write a mesh file with _in.e (the opposite of the _out.e that is appended from the output system) appended to the input file name. You can also optionally provide a mesh filename to write out using --mesh-only output_file.e. When using the --mesh-only option, by default any extra element integers defined on the mesh will also be outputted to the output Exodus file. To prevent extra element ids from being output, the parameter output_extra_element_ids should be set to false in the [Outputs] block of the input file as shown below:


[Outputs]
  [out]
    type = Exodus
    output_extra_element_ids = false
  []
[]

Alternatively, if only a subset of extra element ids should be outputted to the Exodus file, the parameter extra_element_ids_to_output should be set in the [Outputs] block of the input file like so:


[Outputs]
  [out]
    type = Exodus
    output_extra_element_ids = true
    extra_element_ids_to_output = 'id_to_output1 id_to_output2 ...'
  []
[]

Here are a couple of examples showing the usage of --mesh-only:


# Will run all mesh related sections in input_file.i and write out input_file_in.e
./myapp-opt -i input_file.i --mesh-only

# Will do the same but write out mesh_file.e
./myapp-opt -i input_file.i --mesh-only mesh_file.e

# Run in parallel and write out parallel checkpoint format (which can be read as a split)
mpiexec -n 3 ./myapp-opt -i input_file.i Mesh/parallel_type=distributed --mesh-only mesh_file.cpr

Named Entity Support

Human-readable names can be assigned to blocks, sidesets, and nodesets. These names will be automatically read in and can be used throughout the input file. Mesh generators such as CUBIT will generally provide the capability internally. Any parameter that takes entity IDs in the input file will accept either numbers or "names". Names can also be assigned to IDs on-the-fly in existing meshes to ease input file maintenance (see example). On-the-fly names will also be written to Exodus/XDA/XDR files. An illustration for mesh in exodus file format.

[Mesh]
  file = three_block.e

  # These names will be applied on the fly to the
  # mesh so that they can be used in the input file
  # In addition they will show up in the output file
  block_id = '1 2 3'
  block_name = 'wood steel copper'

  boundary_id = '1 2'
  boundary_name = 'left right'
[]
(moose/test/tests/mesh/named_entities/name_on_the_fly.i)

Replicated and Distributed Mesh

The core of the mesh capabilities are derived from libMesh, which has two underlying parallel mesh formats: "replicated" and "distributed".

The replicated mesh format is the default format for MOOSE and is the most appropriate format to utilize for nearly all simulations. In parallel, the replicated format copies the complete mesh to all processors allowing for efficient access to the geometry elements.

The distributed mesh format is useful when the mesh data structure dominates memory usage. Only the pieces of the mesh "owned" by a processor are actually stored on the processor. If the mesh is too large to read in on a single processor, it can be split prior to the simulation.

commentnote

Both the "replicated" and "distributed" mesh formats are parallel with respect to the execution of the finite element assembly and solve. In both types the solution data is distributed, which is the portion of the simulation that usually dominates memory demands.

Distributed Mesh Output Format (Nemesis)

When running a simulation with DistributedMesh it is generally desirable to avoid serializing the mesh to the first rank for output. In the largest case this may cause your simulation to run out of memory, in smaller cases, it may just cause unnecessary communication to serialize your parallel data structure. The solution is to use "nemesis" output.

Nemesis creates separate Exodus files that are automatically read by Paraview and displayed as if a normal Exodus mesh had been output. The output files have the following naming convention:


<filename>.e.<num_processors>.<rank>

# For example, on a 4 processor run, you can expect filenames like this:
out.e.4.0
out.e.4.1
out.e.4.2
out.e.4.3

Mesh splitting

For large meshes, MOOSE provides the ability to pre-split a mesh for use in the "distributed" format/mode. To split and use a mesh for distributed runs:


// For input files with a file-based mesh:
$ moose-app-opt -i your_input-file.i --split-mesh 500,1000,2000 // comma-separated list of split configurations
Splitting 500 ways...
    - writing 500 files per process...
Splitting 1000 ways...
    - writing 1000 files per process...
...

// MOOSE automatically selects the pre-split mesh configuration based on MPI processes
$ mpiexec -n 1000 moose-app-opt -i your_input-file.i --use-split

For more details see "Mesh Splitting".

Displaced Mesh

Calculations can take place in either the initial mesh configuration or, when requested, the "displaced" configuration. To enable displacements, provide a vector of displacement variable names for each spatial dimension in the 'displacements' parameters within the Mesh block.

[Mesh]
  type = FileMesh
  file = truss_2d.e
  displacements = 'disp_x disp_y'
[]
(moose/modules/solid_mechanics/test/tests/truss/truss_2d.i)

Once enabled, the any object that should operate on the displaced configuration should set the "use_displaced_mesh" to true. For example, the following snippet enables the computation of a Postprocessor with and without the displaced configuration.

[Postprocessors]
  [./without]
    type = ElementIntegralVariablePostprocessor
    variable = c
    execute_on = initial
  [../]
  [./with]
    type = ElementIntegralVariablePostprocessor
    variable = c
    use_displaced_mesh = true
    execute_on = initial
  [../]
[]
(moose/test/tests/postprocessors/displaced_mesh/elemental.i)

Mixed Dimension Meshes

MOOSE will function properly when running simulations on meshes containing mixed dimension elements (e.g. 1D and 2D, 1D and 3D, etc.). Residual calculation, material evaluation, etc should all work properly.

[Mesh]
  file = 1d_3d.e
  # 1d_3d.e contains HEX8 and BEAM2 elements - no additional input file
  # changes are necessary to handle mixed-dim meshes.
[]
(moose/test/tests/mesh/mixed_dim/1d_3d.i)

Unique IDs

There are two "first-class" id types for each mesh entity (elements or nodes): "id and unique_id". Both the id and unique_id field are unique numbers for the current active set of mesh entities. Active entities are those that are currently representing the domain but doesn't include "coarse parents" of some elements that may become active during a coarsening step. The difference however is that unique_ids are never reused, but ids might be. Generally the id is "good-enough" for almost all use, but if you need guarantees that an element id is never recycled (because it might be a key to an important map), you should use unique_id.

Periodic Node Map

The MooseMesh object has a method for building a map (technically a multimap) of paired periodic nodes in the simulation. This map provides a quick lookup of all paired nodes on a periodic boundary. in the 2D and 3D cases each corner node will map to 2 or 3 other nodes (respectively).

Extra integer IDs

Extra integer IDs for all the elements of a mesh can be useful for handling complicated material assignment, performing specific calculations on groups of elements, etc. Often times, we do not want to use subdomain IDs for these tasks because otherwise too many subdomains could be needed, and in turn large penalty on run-time performance could be introduced.

MooseMeshMooseMesh has a parameter extra_integers to allow users to introduce more integer IDs for elements each identified with a name in the parameter. When this parameter is specified, extra integers will be made available for all elements through Assembly in MOOSE objects such as kernels, aux kernels, materials, initial conditions, element user objects, etc. To retrieve the integer on an element, one needs to simply call


getElementID(integer_name_parameter, comp),

within the initialization list of your constructor. integer_name_parameter is the name of the parameter in type of std::vector<ExtraElementIDName> of this object listing all integer names. comp is the index into the integer names if multiple are specified for integer_name_parameter. It is noticed that the returned value of this function call must be in type of const dof_id_type &, which is used to refer the value set by MOOSE in Assembly. The returned reference should be held in a class member variable for later use. Based on this ID, one can proceed with any particular operations, for example, choosing a different set of data for evaluating material properties.

IDs can be assigned to the mesh elements with MeshGenerators in a similar way to assigning subdomain IDs. We note that the element IDs are part of the mesh and will be initialized properly for restart/recover.

Mesh meta data

Mesh generators can declare mesh meta data, which can be obtained later in Actions or in UserObjects. Mesh meta data can only be declared in the constructors of mesh generators so that they can be restarted without re-running mesh generators. Mesh meta data can be useful for setting up specific postprocessors, kernels, etc. that require certain geometry information. Mesh meta data are not possible or extremely hard to be derived directly from libMesh mesh object. A simple example of mesh meta data is the num_elements_x provided by GeneratedMeshGenerator, which can be used as an indicator for a mesh regular in x direction.

Debugging in-MOOSE mesh generation

commentnote

The MOOSE mesh generation tutorial is the most comprehensive resource on learning how to mesh within MOOSE. We summarize here only a few techniques.

Mesh generation in MOOSE is a sequential tree-based process. Mesh generators are executed sorted by dependencies, and the output of each generator may be fed to multiple other generators. To succeed in this process, you must decompose the creation of the mesh into many individual steps. To debug this process, one can:

  • use the show_info(=true) input parameter on each mesh generator. This will output numerous pieces of metadata about the mesh at each stage of the generation process. You can check there if all the subdomains that you expected at this stage are present in the mesh and if they are of the expected size, both in terms of number of elements but also bounding box.

  • use the output input parameter on the mesh generator right before the problematic stage. This will output the mesh, by default using the Exodus format with the name <mesh_generator_name>_in.e, so you may visualize it before it gets acted upon by the next mesh generator(s).

For a narrow selection of mesh issues, listed in its documentation, the MeshDiagnosticsGenerator may be used to detect unsupported features in meshes.

Examining meshes

The results of finite element/volume simulations are highly dependent on the quality of the mesh(es) used. It happens regularly that results are excellent and meeting all predictions using a regular Cartesian grid mesh, but significantly deteriorate or do not converge on the real system mesh, often created outside MOOSE.

We point out in this section a few things to look for. - Sidesets in MOOSE are oriented. If you place a Neumann/flux boundary condition on a sideset, the direction of the flux will depend on the orientation of the sideset. - MOOSE generally does not support non-conformal meshes for regular kernels, except when they arise from online mesh refinement. When inspecting your mesh, you should not see any hanging nodes or surfaces not exactly touching. If you are using such a mesh, you MUST use interface kernels, mortar or other advanced numerical treatments. - Many physics will give better results with high element quality and smooth distributions of element volumes. You may examine the spatial distribution of these quantities using the ElementQualityAux and VolumeAux respectively.

Coordinate Systems

The following are the coordinate systems currently available in MOOSE:

  • XYZ: 3D Cartesian.

  • RZ: 2D axisymmetric coordinates.

  • RSPHERICAL: 1D spherical coordinates with the origin at .

Coordinate systems may be specified in the input file or within code.

Specifying coordinate systems in the input file

In an input file, coordinate systems may be specified in the Mesh block. First, "coord_type" is used to specify the coordinate system type. If you would like to use multiple coordinate systems in your application, you can supply multiple entries in this parameter. Then you must specify "coord_block" to specify the corresponding blocks to which each coordinate system applies.

If the RZ coordinate system is used, there are two options for how to specify the coordinate axis(es) in an input file:

  • Specify "rz_coord_axis" to choose a single RZ coordinate system, using the or direction and starting at . If the former is used, then the axial coordinate is , and the radial coordinate is ; if the latter is used, these are switched.

  • Specify the following three parameters:

The second option has greater flexibility, as it allows the following, which the first option does not:

  • Multiple axisymmetric coordinate systems can be defined.

  • Any point can be used for the origin of the coordinate system, not just .

  • Any direction can be used for the axisymmetric axis, not just the or direction.

Note that the Transfers ability for the second option is more limited

Specifying coordinate systems within code

To specify coordinate systems within code, MooseMesh::setCoordSystem(blocks, coord_sys) is used, where blocks and coord_sys have the same behavior as the "coord_block" and "coord_type" parameters, respectively.

If the RZ coordinate system is used, there are two options for how to specify the coordinate axis(es) within the code, just like in the input file: