RelationshipManagers give developers full control of the parallel ghosting of both the geometric (elements and nodes) and algebraic (solution) information with your simulation. This allows developers to reach beyond their normal partitions to run algorithms that may need to access off-partition information without manual parallel communication. You may notice information about which RelationshipManagers are active in your simulation in the information printout. For more information on this important capability, click here.
MOOSE is moving away from traditional include guards and using #pragma once instead. This is slightly less error prone
since you don't need to use a different CPP variable in every file and also reduces the amount of clutter in your header
files. Please start using this new scheme if you contribute to MOOSE.
#pragma once
class SomeObject
{
};
The method of manufactured solutions is a robust means to verify that simulation tools are correct. Therefore, tools and documentation for performing this type of analysis has been added to the code base.
[python/mms.md]
The documentation for the [AuxKernels/index.md] has been improved to include a few examples of how the system should be utilized.
The `VectorAuxKernel base class was created to allow for vector auxiliary variables. For example, it is now possible to create an auxiliary variable that is populated by a parsed function. The following partial input file shows an example of populating a vector auxiliary variable using a parsed function.
!listing vector_function_aux.i block=AuxVariables Functions AuxKernels
The need to include the <RESIDUAL> template argument for AD objects is no longer needed within
the MOOSEDocs syntax calls. For example, the following command can be used to list the available
parameters for the ADDiffusion object.
!listing ADDiffusion.md line=syntax parameters
If you are using MOOSEDocs for tracking requirements within a test specification, the following pages provide detailed information about what is expected.
Documenting MOOSE: Requirement, Design, and Issues
[what_is_a_requirement.md]
There are now three ADKernel base objects, as listed below, that may be used for time derivative portions of partial differential equations. More information about Kernel object in general is provided in the [syntax/Kernels/index.md] documentation.
| Object | Purpose |
|---|---|
| +ADTimeKernelValue+ | This object should be used for time derivative terms that require +only+ the =test function=. |
| +ADTimeKernelGrad+ | This object should be used for time derivative terms that require +only+ the =gradient of the test function=. |
| +ADTimeKernel+ | This object should be used for time derivative terms that require +both+ the =test function= and the =gradient of the test function=. |
The FeatureFloodCount object can now detect "percolation" among any feature in your domain. This is done by supplying a list of primary and secondary boundaries between which a percolation track would be of interest. Additionally, the FeatureFloodCount object can now calculate percent of boundary coverage, where boundary may be an external boundary or an internal boundary defined by a sideset.
Executioner/start_timenow works correctly when performing a Restart simulation.- Reformatting of
timeanddtprintouts. "Dt" is no longer printed on the initial condition, which was misleading. - Fix bug where second level Multiapps where not properly restored when doing a Picard iteration.