MOOSE Newsletter (August 2021)

AD Scalar Kernels

Scalar kernels can now use automatic differentiation (AD). While AD is not necessary for systems of ordinary differential equations (ODEs) involving only scalar variables (due to the exact Jacobians offered by ParsedODEKernel, for example), ODEs involving contributions from field variables greatly benefit from AD. For example, an elemental user object may compute an ADReal value from field variable(s) on a domain, which then may be used in a scalar equation.

To create an AD scalar kernel, derive from ADScalarKernel and implement the method computeQpResidual(). As a caution, if using user objects to compute ADReal values, be sure to execute those user objects on NONLINEAR to ensure the derivatives in the ADReal value are populated.

Multiple Content Configurations in MooseDocs

MooseDocs is now capable of translating multiple sets of markdown (MooseDown) and other file contents that each use unique and independent configurations, i.e., each with their own instances of readers, renderers, executioners, and extensions. This means that pages of a website may appear and function very unalike from each other, yet build together still by a single './moosedocs.py build --serve' job and be served under the same home address. Think of this feature as the ability to combine many websites into one. For example, the main MOOSE website and the MOOSE Workshop can now be built together even though they are translated from MooseDown to HTML in a much different way and require separate styling and JavaScript methods. Another example is two pages could use two different main menu bars or different executables and instructions for retrieving application syntax.

Most notably, this new feature provides the ability to cross-link between the content sets using the AutoLink Extension. The build routines assume that there's no difference between pages of different configurations, including while making edits during a live reload, and the user can assume that interactions between pages work exactly the same as they always have. The MooseDocs Configuration page was revised to reflect these changes, namely, please see the Content Across Multiple Configurations section to learn how to take advantage of this new system.

Improvements to Navier Stokes Flow capabilities

  • Thermal boundary conditions, including radiative and convective heat transfer boundary conditions, were reworked to support primitive, mixed, and conservative variable sets for fluid flow.

  • Initial conditions for conservative variable sets were added. This allows for a simple initialization of density, energy and momentum from temperature, velocity and pressure.

Bug Fixes and Minor Enhancements

  • In ExplicitSSPRungeKutta, a bug was fixed where a segmentation fault was occurring in some corner cases when using automatic differentiation, due to calling computeADTimeDerivatives before initializing some stage data, even though in these cases, the resulting value is not used. Now, a quiet NaN is returned instead of trying to use an invalid pointer.

  • When using time integrators deriving from ExplicitTimeIntegrator, if solve_type was set to anything other than LINEAR, a segmentation fault would occur. Now, an error message is given instead.

  • Missing class documentation was added for actions and auxiliary kernels.

  • When a block or boundary is misspelled, the code will now output the name of the block or boundary in addition to a newly generated id, which will simplify the search for the issue.

  • Dependency resolution between user objects and auxiliary kernels will now be cognizant of their respective execution flags.

  • If the dependency resolution between user objects and auxiliary kernels is known to fail in a given case, incorrectly executing the user object before the auxiliary kernel, a force_postaux boolean parameter to the user object may be used to re-establish the correct order.

Optional-parameter additions for mesh uniform refinement

  • skip_deletion_repartition_after_refine instructs moose to skip remote-element deletion and mesh repartition. This parameter is off by default. If the flag is true, uniform refinements will run more efficiently, but at the same time, there might be extra ghosting elements. The number of layers of additional ghosting elements depends on the number of uniform refinement levels. This flag should be used only when you have a fine enough coarse mesh and want to refine the mesh by a few levels. Otherwise, it might introduce an unbalanced workload and a large ghosted domain.

  • skip_refine_when_use_split instructs moose to skip uniform refinements using pre-split meshes. The motivation of adding this parameter is to uniformly refine pre-split meshes to enable high-fidelity simulations when setting the parameter to be false.

Load command-line arguments from files for multiapp

An input-file parameter cli_args_files was added to load additional command-line arguments for the multiapp system from files. The parameters are populated to sub-applications during their creations. That is useful when we want to populate different parameters for each sub-application, and the total number of sub-applications is large. Otherwise, the input file will not be manageable if we add thousands of parameters directly to the input file.