Skip to content
Permalink
Browse files

Merge pull request #13445 from permcody/check_error

Working on SQA for check_error tests
  • Loading branch information...
permcody committed May 21, 2019
2 parents 208101e + 1a844a8 commit eaa2f43cdaa41eb3343665dc3e2b0dc64132ce1b
@@ -48,6 +48,8 @@ For development of MOOSE-based applications see [Application Development](applic

[Utils](utils/index.md) - Basic utilities used throughout the framework

[System Integrity Checking](sanity_checking.md) - Parsing and system integrity checks

## Internal Systems

[MooseVariables](moose_variables.md) - The set of objects that compute and hold variable/field values
@@ -0,0 +1,44 @@
MOOSE performs several sanity checks when parsing the input file and command line parameters and after all objects for the simulation have been constructed. There are several classes of errors that are covered.

# Parsing

The HIT (formerly GetPot) syntax is strict but fairly easy to use
and understand. The syntax consists of nesting blocks deliniated 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 requirement parameters are missing. MOOSE will also report warning when unknown (mispelled) 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)

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
[]
```
@@ -3,8 +3,6 @@
[]

[Variables]
active = 'u'

[./u]
order = FIRST
family = LAGRANGE
@@ -32,8 +30,3 @@

solve_type = 'PJFNK'
[]

[Outputs]
file_base = out
exodus = true
[]
@@ -3,8 +3,6 @@
[]

[Variables]
active = 'u'

[./u]
order = FIRST
family = LAGRANGE
@@ -33,9 +31,5 @@

solve_type = 'PJFNK'
dt = 1
num_steps = 5
[]

[Outputs]
exodus = true
num_steps = 2
[]

0 comments on commit eaa2f43

Please sign in to comment.
You can’t perform that action at this time.