MOOSE Newsletter (January 2020)
MOOSE now supports grid sequencing, a technique in which a coarse grid solution is used as an initial guess for the fine grid solve. Current support is only for steady problems. Grid sequencing is useful when solving highly nonlinear problems because the initial guess is much nearer Newton's quadratic basin of convergence, which can result in significantly fewer non-linear iterations during the fine solve. Using grid sequencing is as simple as specifying
num_grids=<n> in the
Executioner block. When using grid sequencing, you should provide a mesh corresponding to the coarsest grid to be solved. An example for use of grid sequencing in mechanical contact is given in this input. Support for grid sequencing support for transient problems is planned soon.
RANFS Mechanical Contact
Contact module now has objects for solving frictionless mechanical contact using a RANFS algorithm, where RANFS stands for Reduced Active Nonlinear Function Set. RANFS has the following advantages:
Exactly solves the non-penetration condition; no
penaltyparameter is required
penaltyparameter is required, there are no detrimental effects on the condition number of the system matrix
Exact constraint enforcement is achieved without requiring explicit Lagrange Multiplier variables, which means: - No additional degrees of freedom - Important Matrix properties are preserved, e.g. if the structure of the matrix resulting from
Kernelsis positive-definite, then the matrix will remain positive-definite after application of the frictionless contact constraints. This allows use of multigrid methods which cannot be used in saddle-point problems that usually arise if using Lagrange Multipliers
The RANFS algorithm should make its way into the
ContactAction shortly. An implementation for frictional contact is also planned. A RANFS example can be found here.
MOOSE now supports the
MONOMIAL_VEC FEFamily. This can be useful for example if forming a vector from the gradient of another variable.
MONOMIAL_VEC is now used for the velocity auxiliary variable in MOOSE's
The Peridynamics module, which implements the peridynamic formulation for solution of mechanical and thermal problems has been added to MOOSE. Peridynamics is a mesh-free technique, and represents interactions between material points using bonds, which can be severed individually when a fracture criterion is reached. The major strength of this modeling technique is that it allows for arbitrary, unguided initiation and growth of fracture, making it particularly attractive for problems that involve fragmentation.
This module provides multiple variants of peridynamics, including bond-based, ordinary state-based, and non-ordinary state based formulations. The bond-based and ordinary state-based formulations are limited to elasticity prior to fracture, while the non-ordinary state-based formulation permits use of arbitrary TensorMechanics material models to represent constitutive behavior. A novel stabilization technique that does not require the use of artifical stiffness is used in the non-ordinary state-based formulation.
To use peridynamics in MOOSE, a user provides a finite element mesh, and material points are generated at the centroids of the elements in the user-supplied mesh, along with line elements to represent the bonds between those material points. Peridynamics models are solved using implicit time integration, and make use of MOOSE's ability to solve coupled physics models. Work is underway to allow the use of peridynamics in conjunction with finite elements, with the two domains interacting through contact constraints.
Shell Element for Mechanics
A four-noded shell element has been added to TensorMechanics to enable the efficient solution of mechanics problems on thin structures. These are topologically two-dimensional elements in three-dimensional space, and have the standard displacement degrees of freedom as well as rotational degrees of freedom. In the past, the TensorMechanics module only provided continuum elements, but this shell element, together with the already-available truss and beam elements, builds to a growing libary of structural elements.
Deprecation of DiracKernel Mechanical Contact Enforcement
The original implementation of mechanical contact enforcement in MOOSE used the DiracKernel system to enforce non-penetration constraints. Since that time, the Constraint system has been developed, which provides a much better way for enforcing constraints. An option to use the Constraint system to enforce mechanical contact has been available for several years now, and performs better than the DiracKernal-based system because it allows for all Jacobian entries related to contact to be correctly computed. The DiracKernel-based contact enforcement system is now marked as being deprecated, and will be removed on April 1, 2020. Users can select the new system by specifying
system=Constraint in the
Contact block. See the Contact moduele documentation for more information on its usage.
Please note that this only applies to contact enforcement using the DiracKernel system. The DiracKernel system is used for many other purposes in MOOSE, and will still be available after that time.
MooseIndex works properly when compiling MOOSE with the C++ 2017 standard.
TestHarness now reports error codes properly for unexpected failures (network, disk I/O, etc)
Transient simulation with subapp restarts from steady simulation with subapp
A steady simulation with subpp is used to generate initial solutions for transient simulation. The solutions of steady master-app and subapp can be loaded as initial solutions for transient master-app and subapp, respectively.
Preset boundary conditions
PresetBC and the like boundary conditions are Dirichlet boundary conditions that also apply their values directly to the solution at the beginning of the solve. For simplification, all
Preset prefixed objects (now deprecated) have been absorbed into the corresponding Dirichlet objects with a parameter
preset which will preset the boundary condition.
We have also began a transition to defaulting all Dirichlet like boundary conditions to presetting their values. The default for the
preset parameter is determined by a temporary legacy parameter,
use_legacy_dirichlet_bc, in each application (see here). All MOOSE modules and the test application have this legacy parameter set to
false, therefore the default for these applications is
preset = true. Other applications can utilize this new suggested default by setting said legacy parameter similarly.