MOOSE Newsletter (May 2018)

True Explicit

MOOSE has had an explicit-euler option for a long time. Unfortunately, it still involved a lot of the nonlinear solution algorithm and included a linear solve using the mass matrix. Now a true Explicit capability has been merged into MOOSE. This new capability differentiates itself by being extremely lean and fast and providing the ability for lumped-mass explicit updates that don't even need to solve a linear system. For more information see ActuallyExplicitEuler

Vector Finite Elements

MOOSE now supports vector finite elements. Currently available element types are LAGRANGE_VEC and NEDELEC_ONE. The former is equivalent to a vector of scalar LAGRANGE elements and is useful in applications like tensor mechanics or Navier-Stokes in which the user would have to specify multiple kernel blocks for displacement or velocity components. NEDELEC_ONE elements are specifically tailored for PDEs involving curl operators such as Maxwell's equations. Introductory examples can be found in the MOOSE test suite (/test/tests/kernels/vector_fe).

Control System Improved

The Controls System was updated to improve performance and usability. With respect to performance all parameters that are declared as controllable are cached during object creation. This allows retrieval to be more efficient and easier; previously every object and parameter was interrogated with every call to change it. With respect to usability, the ControllableParameter objects are no longer templates, only the get/set methods on this object require a template argument. This allows for Control objects to be generic, for example the SamplerReceiver now allows for vector parameters to be modified.

Hypre Documentation

Not really a new capability in MOOSE: but still important! A new set of documentation about how to use the Hypre BoomerAMG Preconditioner has been developed. The document goes over both basic and advanced usage and is a must read for anyone regularly using Hypre. Here is a direct link but you can always get to it from the Application Development page.


Debugging MOOSE-based executables (especially in parallel) got a large upgrade this month. It is now straightforward to start a MOOSE-based solve and have it pop up interactive debugging windows that are attached to each MPI process using --start-in-debugger. For larger jobs, --stop-for-debugger, gives you time to attach to whatever processor you wish. For more information see Debugging.

WorkBalance, StatisticsVectorPostprocessor and VectorPostprocessorVisualization

A new capability has been merged that allows for better inspection of work balance (or imbalance!) in parallel. The WorkBalance VectorPostprocessor will output many different metrics detailing how much work and communication each MPI process is doing. For more information see WorkBalance

In order to understand the output of WorkBalance you can use the new StatisticsVectorPostprocessor. It allows you to compute aggregate statistics of another VPP (like WorkBalance) such as: min, max, average, stddev, etc.

In addition, if you would like to visualize a VPP where the vectors are n_procs in length you can use the VectorPostprocessorVisualizationAux AuxKernel. For instance, this can be used to visualize the num_elem vector from WorkBalance so you can visually inspect the performance of your partitioner.

MOOSE base reorganization

In case you haven't noticed, MOOSE went through a signficant reorganization. The main activity was moving files out of base and creating new subdirectories like loops, systems, problems, etc. The base directory had outgrown itself - and it was time for some spring cleaning! In addition to better organization this also sped up compile times on laptops by 25% (even beyond the huge speedup gained by Unity Builds).

Custom Line Searches

MOOSE now allows implementation of custom line-searches for custom non-linear solution algorithms. Users wishing to create their own line search have to inherit from the LineSearch class and override the lineSearch method. A demonstration of a custom line search implementation can be found in the PetscContactLineSearch; this class will cut the line search parameter (lambda) up to a specified number of times as long as the residual is decreasing. This is effectively an intermediate between basic and bt line-searches: it performs a search to reduce the residual but will allow temporary increases in the non-linear residual. Moreover, while the contact set is changing early in the non-linear solve, a custom linear tolerance can be set in order to avoid over-solving.

Mesh Splitting

Functionality for an automated pre-split mesh workflow for use with distributed mesh has been implemented. This allows large meshes to be easily partitioned and split into configurations for performing parallel runs on specific numbers of processors. This helps reduce memory usage and drastically speed up setup/initialization time among other improvements.

Parameter-specific Error Messages

When performing input parameter specific error checking for your moose objects and actions, consider using the new paramError and paramWarning functions. These functions act like mooseError and mooseWarning, except they take an extra argument specifying an input parameter name that is used to annotate the error/warning output with relevant input-file location information. For example:

MyObject::MyObject(InputParameters & params)
    if (getParam<int>("foo") < 42)
      paramError("foo", "value must be greater than or equal to 42);

Would give users an error like:

yourinput.i:23: (UserObjects/yourobject/foo) value must be greater than or equal to 42

where 23 is the line number in the input file.

Parameter Error Checking

Additional checking has been implemented that warns when moose object parameters are set without ever having been specified in the validParams functions. This prevents setting parameters in-code that end up being silently ignored by the destination object - which happens sometimes due to typos or merting multiple parameters before object creation among other ways. The error messages look like this:

Attempted to set unregistered parameter(s) for YourObject object:
    foo, bar, foobar, etc.

Plugin for XFEM Result Visualization in ParaView

The MOOSE XFEM module allows for arbitrary mesh-independent discontinuities to be represented in a finite element model using the extended finite element method (XFEM). The simulation results from this technique require some additional processing to be correctly visualized because the technique generates pairs of overlapping elements that need to be clipped to show only the physically relevant parts of the solution.

A plugin for visualizing results generated using that technique has been merged into the master branch of the open-source ParaView visualization tool. This plugin has been openly available for some time on github, but to use it, it was necessary to build ParaView from source. Now that this plugin is part of ParaView, it is available in its nightly builds, and will be part of the upcoming 5.6 release. This plugin can be enabled within ParaView by selecting Tools->Manage Plugins->MooseXfemClip, selecting the Auto Load option, and then restarting ParaView. If the results of a MOOSE-based model using XFEM are loaded, this filter can be applied by selecting Filters->Alphabetical->MooseXfemClip.