Developer Manual
This manual provides the information needed for developers of MASTODON. This manual is actively being improved and more information is being added to make it more useful. Interested developers are therefore requested to reach out to the team as mentioned here.
Developing new objects
MASTODON is built upon MOOSE and therefore uses the MOOSE architecture and protocols for development. Developers therefore are highly encouraged to look into the MOOSE Framework and also reach out to the MASTODON team here when planning to develop new objects. Development and inclusion of a new object (material, boundary condition, etc.) in MASTODON (or MOOSE) involves the following steps:
Writing the code
Writing the documentation, which includes
Syntax information
Theory and references in the theory manual
Usage instructions in the user manual
Examples, if any
Creating test problems that will be included in the list of tests
MOOSE and MASTODON use specific formatting for all the C++ code in the repository. This formatting is explained in the MOOSE software coding standards.
Documenting new objects
Prior to merging the code, MOOSE and MASTODON require adequate documentation describing the implemented feature, such as materials, post processors, etc. Several tools are available for MOOSE-based documentation. For each new feature, the following documentation files are required.
Documentation of C++ objects
For each C++ object created, the developer should include the documentation using the MOOSE documentation system.
User manual
For each feature (such as material, boundary condition, etc., which may include one of more C++ objects), the developer must create one documentation file that describes the method of usage of this feature. This file must be named as <feature_name>-user.md and be placed in the appropriate sub folder in content/manuals/include. A rough template for the user manual document is below.
# <Name of the feature, e.g., lead-rubber isolator>
Introduction and link to the corresponding theory manual document.
Objects needed to simulate this feature. Links to the documentation of these
objects.
Associated actions, and usage in the Mastodon block, if available. Link to the
documentation of the corresponding Mastodon block action.
Any known quirks/limitations about the usage of the model that need to be known.
Theory manual
For each feature (such as material, boundary condition, etc., which may include one of more C++ objects), the developer must create one documentation file that describes the theory behind this feature. This file must be named as <feature_name>-theory.md and be placed in the appropriate sub folder in content/manuals/include. A rough template for the theory manual document is below.
# <Name of the feature, e.g., lead-rubber isolator>
Introduction about what the feature does and a link to the corresponding user
manual document.
Description of the physics, or the theory behind the feature including
references, equations, figures, etc.
Limitations, if any, of the formulation.