<commit_before># MooseVariableBase

!syntax description /Variables/MooseVariableBase

The current class hierarchy for Moose variables is shown below:

!media media/variables/moose_variable_hierarchy.svg
       caption=Moose variable hierarchy.
       style=width:50%;

`MooseVariableBase` is the primitive base class from which all variables
inherit. It includes methods for accessing the variable finite element type and
order, degress of freedom, scaling factor, name, and associated
`SystemBase`. Two classes inherit directly from `MooseVariableBase`:
`MooseVariableFEBase` and `MooseVariableScalar`. `MooseVariableScalar` represents a
Moose variable that is constant over the spatial domain. It has a number of
degrees of freedom equal to the order of the variable, e.g. the following
variable block would declare a `MooseVariableScalar` with two associated degrees
of freedom:

```
[AuxVariables]
  [aux_scalar]
    order = SECOND
    family = SCALAR
  []
[]
```

`MooseVariableFEBase` is an abstract class that encompasses all finite-element type
variables; all variables that vary spatially ultimately inherit from
`MooseVariableFEBase`. The class implements all the relevant variable methods other
than those that return the actual variable solution or variable shape functions,
since the return type in
the latter case depends on whether the finite-element variable is scalar-valued
(single-component) or vector-valued (multi-component) in nature. The existence
of the `MooseVariableFEBase` class allows construction of containers that hold both single- and
multi-component finite element variables. This is useful for instance in the
`Assembly` class where we can abstract the coupling matrix entries or in
Jacobian computing
objects like `Kernels` when we want to fetch the numerical ID of the variable
using `coupled`. Moreoever, this design structure mirrors that of the `FE`
design in LibMesh, where `FEAbstract` is an abstract base class that implements
all methods independent of `FE` type and the class
template `FEGenericBase<T>` implements the type dependent methods analogous to
`MooseVariableFE<T>`.

`MooseVariableFE<T>` implements methods that return the variable's solution
and its associated shape functions. Additionally, it contains the methods
responsible for computing the variable solution at quadrature points given the
degree of freedom values computed from the previous non-linear
solution. "Standard" or "traditional" finite element variables that are
single-component are instantiated with the template argument `Real`; these hold
variables of finite element families `LAGRANGE`, `MONOMIAL`, `HERMITE`,
etc. Multi-component vector finite element variables are instantiated with the
template argument `RealVectorValue` and currently encompass the finite element
familes `NEDELEC_ONE` and `LAGRANGE_VEC`. The former is useful for
electromagnetic applications or for general PDEs that involve a curl
operation. The latter is potentially useful for tensor mechanic or Navier-Stokes
simulations where historically displacement or velocity variables have been
broken up component-wise. To hide the templating of the Moose variable system
from other framework code, `MooseVariableFE<Real>` and
`MooseVariableFE<RealVectorValue>` have been aliased to `MooseVariable` and
`VectorMooseVariable` respectively.

Finally, `MooseVariableConstMonomial` is a class that takes advantage of its
finite element type (constant value on an element) to optimize its solution
computing routines. Consequently, it overrides the `computeElemValues` and
similar methods of `MooseVariableFE<Real>`.

## Accessors

There are a myriad of ways to access Moose variables from user interfaces. We'll
outline a few below.

## Restart

Variables can be restarted/initialized from variable values in a file on disk by
setting the parameter `initial_from_file_var = source_var_name` in the variable
sub-block, where `source_var_name` is the name of the source variable in the
file. Note that the user will also have to set parameters in the `[Mesh]` block
in order for this to work, as described for example in the documentation of the
[FileMeshGenerator.md].

### SystemBase

It's common for interface objects (`Kernel` objects for example) to have a `_sys`
member. The `_sys` member has the following variable accessor methods which take
a `THREAD_ID` and either a `std::string` variable name or `unsigned` variable ID
as arguments:

- `getVariable`: returns a reference to a `MooseVariableFEBase`. Useful when access
  to the variable finite element solution or shape functions is not needed
- `getFieldVariable`: this is a templated method that takes as its template
  argument either `Real` or `RealVectorValue` and returns a reference to a
  `MooseVariable` or a `VectorMooseVariable` respectively. Useful when the user
  knows and needs the complete type
- `getScalarVariable`: returns a reference to a `MooseVariableScalar`

These getter methods ultimately query different map containers in the `VariableWarehouse`.

### SubProblem

Another common interface object member is `_subproblem`. `_subproblem` has the
following acessors methods which take `THREAD_ID` and a `std::string` variable
name as arguments (note that acessors through variable IDs do not exist through
`SubProblem`):

- `getVariable`: returns a reference to a `MooseVariableFEBase`. Useful when access
  to the variable finite element solution or shape functions is not
  needed. Calls `SystemBase::getVariable`
- `getStandardVariable`: returns a reference to a
  `MooseVariable`. Useful when the user
  knows and needs the complete type. Calls `SystemBase::getFieldVariable<Real>`
- `getVectorVariable`: returns a reference to a
  `VectorMooseVariable`. Useful when the user
  knows and needs the complete type. Calls `SystemBase::getFieldVariable<RealVectorValue>`
- `getScalarVariable`: returns a reference to a `MooseVariableScalar`

Note that the template abstraction available in `SystemBase` is not available in
`SubProblem`. This is because the accessor methods in `SubProblem` are pure
virtual, i.e. their implementations are made in derived classes which eliminates<commit_msg>Fix some typos for moose variable base, refs #18333<commit_after># MooseVariableBase

!syntax description /Variables/MooseVariableBase

The current class hierarchy for Moose variables is shown below:

!media media/variables/moose_variable_hierarchy.svg
       caption=Moose variable hierarchy.
       style=width:50%;

`MooseVariableBase` is the primitive base class from which all variables
inherit. It includes methods for accessing the variable finite element type and
order, degress of freedom, scaling factor, name, and associated
`SystemBase`. Two classes inherit directly from `MooseVariableBase`:
`MooseVariableFEBase` and `MooseVariableScalar`. `MooseVariableScalar` represents a
Moose variable that is constant over the spatial domain. It has a number of
degrees of freedom equal to the order of the variable, e.g. the following
variable block would declare a `MooseVariableScalar` with two associated degrees
of freedom:

```
[AuxVariables]
  [aux_scalar]
    order = SECOND
    family = SCALAR
  []
[]
```

`MooseVariableFEBase` is an abstract class that encompasses all finite-element type
variables; all variables that vary spatially ultimately inherit from
`MooseVariableFEBase`. The class implements all the relevant variable methods other
than those that return the actual variable solution or variable shape functions,
since the return type in
the latter case depends on whether the finite-element variable is scalar-valued
(single-component) or vector-valued (multi-component) in nature. The existence
of the `MooseVariableFEBase` class allows construction of containers that hold both single- and
multi-component finite element variables. This is useful for instance in the
`Assembly` class where we can abstract the coupling matrix entries or in
Jacobian computing
objects like `Kernels` when we want to fetch the numerical ID of the variable
using `coupled`. Moreover, this design structure mirrors that of the `FE`
design in LibMesh, where `FEAbstract` is an abstract base class that implements
all methods independent of `FE` type and the class
template `FEGenericBase<T>` implements the type dependent methods analogous to
`MooseVariableFE<T>`.

`MooseVariableFE<T>` implements methods that return the variable's solution
and its associated shape functions. Additionally, it contains the methods
responsible for computing the variable solution at quadrature points given the
degree of freedom values computed from the previous non-linear
solution. "Standard" or "traditional" finite element variables that are
single-component are instantiated with the template argument `Real`; these hold
variables of finite element families `LAGRANGE`, `MONOMIAL`, `HERMITE`,
etc. Multi-component vector finite element variables are instantiated with the
template argument `RealVectorValue` and currently encompass the finite element
families `NEDELEC_ONE` and `LAGRANGE_VEC`. The former is useful for
electromagnetic applications or for general PDEs that involve a curl
operation. The latter is potentially useful for tensor mechanic or Navier-Stokes
simulations where historically displacement or velocity variables have been
broken up component-wise. To hide the templating of the Moose variable system
from other framework code, `MooseVariableFE<Real>` and
`MooseVariableFE<RealVectorValue>` have been aliased to `MooseVariable` and
`VectorMooseVariable` respectively.

Finally, `MooseVariableConstMonomial` is a class that takes advantage of its
finite element type (constant value on an element) to optimize its solution
computing routines. Consequently, it overrides the `computeElemValues` and
similar methods of `MooseVariableFE<Real>`.

## Accessors

There are a myriad of ways to access Moose variables from user interfaces. We'll
outline a few below.

## Restart

Variables can be restarted/initialized from variable values in a file on disk by
setting the parameter `initial_from_file_var = source_var_name` in the variable
sub-block, where `source_var_name` is the name of the source variable in the
file. Note that the user will also have to set parameters in the `[Mesh]` block
in order for this to work, as described for example in the documentation of the
[FileMeshGenerator.md].

### SystemBase

It's common for interface objects (`Kernel` objects for example) to have a `_sys`
member. The `_sys` member has the following variable accessor methods which take
a `THREAD_ID` and either a `std::string` variable name or `unsigned` variable ID
as arguments:

- `getVariable`: returns a reference to a `MooseVariableFEBase`. Useful when access
  to the variable finite element solution or shape functions is not needed
- `getFieldVariable`: this is a templated method that takes as its template
  argument either `Real` or `RealVectorValue` and returns a reference to a
  `MooseVariable` or a `VectorMooseVariable` respectively. Useful when the user
  knows and needs the complete type
- `getScalarVariable`: returns a reference to a `MooseVariableScalar`

These getter methods ultimately query different map containers in the `VariableWarehouse`.

### SubProblem

Another common interface object member is `_subproblem`. `_subproblem` has the
following accessors methods which take `THREAD_ID` and a `std::string` variable
name as arguments (note that accessors through variable IDs do not exist through
`SubProblem`):

- `getVariable`: returns a reference to a `MooseVariableFEBase`. Useful when access
  to the variable finite element solution or shape functions is not
  needed. Calls `SystemBase::getVariable`
- `getStandardVariable`: returns a reference to a
  `MooseVariable`. Useful when the user
  knows and needs the complete type. Calls `SystemBase::getFieldVariable<Real>`
- `getVectorVariable`: returns a reference to a
  `VectorMooseVariable`. Useful when the user
  knows and needs the complete type. Calls `SystemBase::getFieldVariable<RealVectorValue>`
- `getScalarVariable`: returns a reference to a `MooseVariableScalar`

Note that the template abstraction available in `SystemBase` is not available in
`SubProblem`. This is because the accessor methods in `SubProblem` are pure
virtual, i.e. their implementations are made in derived classes which eliminates
{'fraction_non_alphanumeric': 0.052886948083454635, 'fraction_numerical': 0.000727802037845706, 'mean_word_length': 5.533016376122557, 'pattern_counts': {'":': 0, '<': 19, '<?xml version=': 0, '>': 19, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2494126', 'n_tokens_mistral': 3104, 'n_tokens_neox': 2978, 'n_words': 1591}