Parsing

The HIT (formerly GetPot) syntax is strict but fairly easy to use and understand. The syntax consists of nesting blocks delineated by square brackets. Name/value pairs are then used to set parameters throughout the system. The token rules are fairly loose. Most tokens are allowed (letters, numbers, underscores). Notably, spaces may not occur inside any section names, nor parameter names. When the parser runs, several different kinds of errors are detected:

• Syntax errors: (missing brackets, lack of closing section, mismatched quotes - single or double, etc.)

• Semantic errors: incorrect types (numbers instead of strings, incorrect MOOSE types, etc)

Missing and incorrect parameters

MOOSE will report errors when required parameters are missing. MOOSE will also report warning when unknown (misspelled) parameters are supplied but are not used. As a developer you should use paramError() or paramWarning(), when creating error messages related to input file parameters. These "param" type errors will be used by the parser to generate line number information for the offending problematic parameters.

Simulation Sanity Checks

MOOSE performs several sanity checks just before the simulation runs. This includes several different kinds of checks

• Each block must have an active Kernel (Part of a PDE)

• Each "consumed" material property must be supplied (checked on each subdomain and boundary)

• Each specified block or boundary must exist in the mesh.

• Each "active" or "inactive" section in the input must exist

• Invalid object types are flagged as invalid

• All coupling parameters must refer to valid variables

• All Functions must refer to valid functions or must be parsed as a valid function expression.

• All Postprocessors must refer to valid Postprocessors in the input file.

• All other system "coupling" parameters are checked for validity

• All pluggable systems must refer to the right type of variable (scalar, vector, array, "nonlinear", "auxiliary", etc)

• Material properties must be defined on every block or boundary where they are consumed.

• Multiple material properties with the same name be defined on overlapping blocks/boundaries.

• Variable definition on boundary restricted objects. Nodal object integrity checking is controlled with "boundary_restricted_node_integrity_check". Elemental object integrity checking is controlled with "boundary_restricted_elem_integrity_check". Checked objects include - Nodal user objects - Nodal auxiliary kernels - Nodal boundary conditions - Side user objects - Elemental auxiliary kernels - Integrated boundary conditions

Some of these checks can be disabled. This often comes in handy for testing purposes. One of the most common pair of parameters used in testing can be used to disable the kernel coverage check when a solve is not necessary.

# Disables the kernel coverage check and skips solving the system
[Problem]
  kernel_coverage_check = false
  solve = false
[]

By default, MOOSE assumes the computational domain to be the entire mesh. However, some simulations set up using subdomain modifiers or lower-dimensional blocks (such as mortar contact) describe the computational domain of the underlying problem on a subset of the mesh.

In such cases, the common approach is to either:

• Disable kernel coverage checks entirely by setting:

[Problem]
  kernel_coverage_check = false
[]

• Restrict the kernel coverage check to specific blocks by setting:

[Problem]
  kernel_coverage_check = ONLY_LIST
  kernel_coverage_block_list = 'block1 block2 block4'
[]

In addition, when certain material properties are block restricted to the computational domain, users must also manually set:

[Problem]
  material_coverage_check = ONLY_LIST
  material_coverage_block_list = 'block1 block2 block4'
[]
```
to skip the material coverage check outside the computational domain.

This manual setup is not only repetitive but also error-prone, especially when the same block list needs to be specified in multiple places.

To simplify this process, the `block` parameter can be specified under `[GlobalParams]` so that it applies to all block-restrictable objects. This allows users to specify the default computational domain and inform MOOSE to skip coverage checks outside the computational domain.

Setting `GlobalParams/block` will automatically:

- Enable kernel coverage check with `ONLY_LIST` mode and assign the specified blocks to `kernel_coverage_block_list`
- Enable material coverage check with `ONLY_LIST` mode and assign the specified blocks to `material_coverage_block_list`

This provides a more user-friendly and centralized way to handle simulations with a preferred, non-default computational domain.

Example Usage for  `GlobalParams/block`:

```
# Perform kernel and material coverage checks only for block 0, 1, and 3,
# while excluding block 2 as an inactive region.

[GlobalParams]
  block = '0 1 3'
[]

[Variables]
  [u]
    # Now this variable will be block-restricted to blocks 0, 1, and 3.
  []
[]

[Kernels]
  [diffusion]
    # And kernels are also block-restricted to blocks 0, 1, and 3.
    type = Diffusion
    variable = u
  []
[]

Kernel coverage check will respect the GlobalParams/block parameter, i.e. the following setup would trigger the error about missing kernel on block 3:

[GlobalParams]
  block = '0 1 3'
[]

[Variables]
  [u]
    block = '0 1'
  []
[]

[Kernels]
  [diffusion]
    type = Diffusion
    variable = u
    block = '0 1'
  []
[]