MOOSE Newsletter (November 2018)

MOOSE Development Workflow

We have slightly modified the way MOOSE changes are submitted+merged on GitHub. In general, nothing should change from the workflow you are use to. From now on, all pull requests will be into the "next" branch instead of "devel". We've changed the default github branch for MOOSE to be "next" - so it will be automatically selected when you create new pull requests. The "devel" branch still exists and has the exact meaning as before, and you should still branch from "devel" when working on changes to MOOSE.

Automatic Differentiation

Making use of the MetaPhysicL package, MOOSE now has forward mode automatic differentiation (AD) capabilities. Where this capability is perhaps most useful is in Jacobian computation, as demonstrated in classes inherited from ADKernel. These derivative classes only have to override the computeQpResidual method; the Jacobian is computed automatically by carrying derivatives through the residual computation. The ADKernel and ADMaterial classes have been designed such that derivative computation is only conducted during the Jacobian computation phase; while computing the residual, derivative computations are not carried out, saving substantial expense.

More documentation will be added as AD percolates through the framework (e.g. addition of ADInterfaceKernel, ADDGKernel, ADIntegratedBC, ADNodalBC). For now the best documentation is the existing tests. Some example input files include: ad_material.i, ad_coupled_convection.i, and ad_simple_diffusion.i. For examples of writing ADKernels, see ADCoupledConvection.h, ADMatDiffusion.h headers and ADCoupledConvection.C, ADMatDiffusion.C source files. An example of an ADMaterial can be found in ADCoupledMaterial.h, ADCoupledMaterial.C.

Moving forward, the idea is for application developers to be able to develop entire apps without writing a single Jacobian statement, having confidence that the automatically computed Jacobians are accurate. This has the potential to decrease application development time by order(s) of magnitude. In terms of computing performance, note that presently AD Jacobians are indeed slower to compute than hand-coded Jacobians, but they parallelize extremely well.

Relationship Manager System Evolution

In October, the Relationship Manager system gained several new capabilities

Grain Tracker Enhancements

The GrainTracker continues to be improved upon, with robustness enhacements and new functionality in several areas. The GrainTracker has been updated to utilize the latest improvments added to the Relationship Manager system. The GrainTracker now creates separate Geomateric and Algebraic Relationship Managers to ensure the proper amount of solution information is necessary in distributed simulations for stitching together separate grain regions.

Other Grain Tracker enhancments added in October:

  • The GrainTracker has been enhanced to support "melt pool" simulations where the simulation may begin with zero grains. Previously the GrainTracker only supported simulations that began with a non-zero number of grains.

  • The GrainTracker no longer uses a recursive discovery method for identifying individual grain regions on each processor. Modern Linux and Mac operating system default to fairly small stack sizes (only a few Megabytes). If the GrainTracker is used on finer meshes or with larger grains, it was possible to run out of stack space creating a difficult to understand segmentation fault. Rather than require users to adjust stack spaces to use this common capability, the recursive algorithm was simply replaced with an iterative one, which allows for much larger recursive exploration of features.

  • Handles degenerative bounding boxes (e.g. 2D bounding boxes in 3D) for more robust fast intersection checking.

  • Additional algorithmic checks for difficult tracking cases involving nucleation and evolution in close proximity (e.g. more tracking robustness).

Vector Initial Conditions

Initial conditions can now be supplied for vector variables. Currently, only VectorConstantIC exists (see VectorConstantIC.h, VectorConstantIC.C, vector_constant_ic.i), but more can be easily added by overriding the value method.

Action Refactor

The MaterialOutputAction object and related objects were refactored and made simplier. Previously these tasks were designed as meta-actions. However, it was discovered that these Actions could be simplified by being converted into normal MooseObjectActions (more direct).

New Enhacements

  • Enable Mac OS 10.14 (Mojave) support and debugging through code signing (entitlements)

  • CSVDiffer.py (CSVDiff Tester) can now compare a subset of columns (more enhancements coming)

  • Migrate to the improved RandomIC in all tests (remove all deprecated tests from the framework and modules)

  • Don't update the "failed tests" list when running only failed tests (–failed-tests).

Bug Fixes

  • Avoid unecessary data structure copies (multiple) in SystemBase

  • Explicity set the current subdomain in ElementalVariableValue postprocessor (avoid assertion)

  • Avoid duplicate runs of mesh adaptivity and mesh modifiers when running MOOSE using a pre-split mesh fixes (https://github.com/idaholab/moose/issues/12084 and https://github.com/idaholab/moose/issues/12304)