Documentation for MOOSE comes in many flavors:
The Getting Started link to the left details how to get everything put in place to use MOOSE.
The Wiki on this website is the primary source for documentation and contains an abundance of information about every aspect of using MOOSE-based applications, creating applications using MOOSE and developing MOOSE itself.
MOOSE and MOOSE-based applications are developed using C++. However, the MOOSE team works hard to ensure that the code is easily approachable by people not proficient in C++. To this end we have developed a set of pages with the C++ essentials you'll want to be familiar with before diving into MOOSE itself.
MOOSE includes a tutorial that demonstrates how to create and grow your application, simply follow the tutorial pages on the wiki and follow along in the code in the tutorials directory.
MOOSE includes a set of example applications that each show how to use a different portion of the system. The examples are located in the
examples directory and can also be viewed on GitHub.
MOOSE-based applications take text-based input files, the syntax for these input files can be dumped out of any MOOSE-based application using:
We also take this information and turn it into handy web-pages that you can browse here.
To add your application to this list simply email the MOOSE-users mailing list.
The next level of documentation is the raw Doxygen pages. Our Doxygen pages detail the complete API available to you as an application developer. The Doxygen documentation is updated every time the code changes.
MOOSE has an extensive set of tests that are categorized and grouped for easy browsing. This is the go to place for more in-depth examples. The tests will be in the
test/tests directory in your MOOSE clone but can also be accessed on GitHub.
Every time MOOSE changes it is tested. Currently, we run about 1,000 tests of the framework across multiple platforms with multiple compilers. As part of this process we keep track of exactly which lines of code are being tested by our tests so that we can make sure we're testing the framework well.
In addition to the test coverage another automatic metric that we collect is "Test Timing". For this timing we scale the tests up a bit (so they take a bit longer) then we track how long they take to run as we change the software. This let's us keep an eye on our changes are impacting performance.
let's do something great
1 month, 1 week ago