parrot / allmd /2019_08.md
aikubo's picture
Upload folder using huggingface_hub
387e2e0 verified

A newer version of the Gradio SDK is available: 5.23.3

Upgrade

MOOSE Newsletter (August 2019)

Documentation

The Adaptivity documentation was improved: [Adaptivity.md].

The software quality documentation tools were improved to enable documentation from the framework, modules, and other applications to be inherited. See [sqa/index.md exact=True] for an example.

Coupling Relationship Managers

The RelationshipManager system now supports coupling functors, which can be used to tell PETSc the correct matrix sparsity pattern. This is useful for simulations that have degree of freedom coupling beyond traditional continuous FEM intra-element coupling. For example for discontinuous Galerkin finite element methods, element residuals will depend on neighboring degrees of freedom. Some MOOSE users like @WilkAndy require even more exotic sparsity patterns for schemes like the Kuzmin-turek FEM-TVD scheme. A RelationshipManager defining custom coupling can be added in a very similar way as that for geometric or algebraic ghosting. For example in the validParams template specialization for AdvectiveFluxCalculatorBase we add two layers of geometric, algebraic, and coupling ghosting using the code:

  params.addRelationshipManager("ElementPointNeighborLayers",
                                Moose::RelationshipManagerType::GEOMETRIC |
                                    Moose::RelationshipManagerType::ALGEBRAIC |
                                    Moose::RelationshipManagerType::COUPLING,
                                [](const InputParameters &, InputParameters & rm_params) {
                                  rm_params.set<unsigned short>("layers") = 2;
                                });

where the need for custom coupling is specified using the Moose::RelationshipManagerType::COUPLING enumerator.

Additional discussion of the RelationshipManager system can be found in its documentation.

MooseVariables as MooseObjects

MooseVariables are now MooseObjects. This should have a relatively small impact on the MOOSE community, however, application developers who add their variables through actions are encouraged to drop use of the deprecated FEProblemBase::add*Variable methods and switch to the new add*Variable(std::string type, std::string name, InputParameters params) API.