In general, MOOSE is not designed for generating finite element meshes. Generally, CUBIT from Sandia National Laboratories is recommended for creating meshes, especially complex geometries, for use in MOOSE. CUBIT can be licensed from CSimSoft for a fee depending that varies based 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] of the input files, for example the basic input file syntax for reading a file from a mesh is shown below. For additional information on the other types of Mesh objects refer to the individual object pages listed below.
[Mesh] type = FileMesh file = square.e 
- Moose App
- 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 tmin!0 and tmax!2Pi, a sector of an annulus or disc is created. In this case boundary sidesets are also created a tmin and tmax, and given these names
- ConcentricCircleMeshThis ConcentricCircleMesh source code is to generate concentric circle meshes.
- DistributedGeneratedMeshCreate a line, square, or cube mesh with uniformly spaced or biased elements.
- 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.
- 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.
- External Petsc Solver App
- PETScDMDAMeshCreate a line, square, or cube mesh with uniformly spaced memsh using PETSc DMDA.
- Phase Field App
- EBSDMeshMesh generated from a specified DREAM.3D EBSD data file.
- Moose App
Outputing 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 commandline 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 writeout using
Here are a couple of examples showing the usage of
# 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
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' 
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.
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 unecessary communication to serialize your parallel datastructure. 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
For large meshes, MOOSE provides the ability to pre-split a mesh for use in the 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 procs $ mpiexec -n 1000 moose-app-opt -i your_input-file.i --use-split
For more details see "Mesh Splitting".
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' 
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 [../] 
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. 
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 guarentees that an element id is never recycled (because it might be a key to an important map), you should use unique_id.