-
Notifications
You must be signed in to change notification settings - Fork 0
MOOSE FAQ
- Supported Finite Element Types
- String-Derived Types
- MooseEnum
- Moose Setup
- Coupling to an Arbitrary Number of Variables
- AuxKernels
- BoundaryConditions
- Functions
- UserObjects
- Preconditioning
- Restart
- Misc
- Warnings
- Petsc 3.1 to 3.3
The following is a list of finite element families and their valid orders within the MOOSE framework.
Any families with a * next to their name haven't been used yet by anyone using MOOSE (as far as the authors know). "ANY" means that you can use any order from FIRST through FORTYTHIRD.
-
BERNSTEIN
*: ANY -
LAGRANGE
: FIRST, SECOND, THIRD (THIRD only in 1D) -
L2_LAGRANGE
*: FIRST, SECOND, THIRD (THIRD only in 1D) -
CLOUGH
: SECOND, THIRD -
HERMITE
: THIRD -
HIERARCHIC
: ANY -
L2_HIERARCHIC
*: ANY -
MONOMIAL
: ANY -
SCALAR
: ANY -
SZABAB
*: FIRST through SEVENTH -
XYZ
: ANY
MOOSE has a number of string-derived types that are provided to improve type safety when writing Custom Actions, and for use within the Peacock GUI. When writing Custom Actions, you will encounter compile-time (rather than run-time) errors about missing Parameters if you fail to provide parameters of the correct types.
Some of the more common types are:
-
NonlinearVariableName
: This is the type that represents one of the nonlinear variable names in your system. Usually these are defined in the[Variables]
block. An example of using this type with a params object is given below:
params.set<NonlinearVariableName>("variable") = "density";
-
AuxVariableName
: This is the type that represents one of the auxiliary variable names in your system. Usually these are defined in the[AuxVariables]
block. -
VariableName
: This is a type for a generic variable name. This applies mainly toElementPostprocessors
,SidesetPostprocessors
, andNodalPostprocessors
when a variable name is expected.
MooseEnum
is a class designed to be a "smart" replacement for the
C++ enum
type. MooseEnums
are intended for use anywhere in a input
file where your parameter has some fixed number of options. By using a
MooseEnum
in your MOOSE object, your options will be propertly read
from the input file and checked against a master list of valid
options. In addition, pick-lists will be automatically displayed when
using Peacock. Note: MooseEnum is case-preserving, but not
case-sensitive.
An example of declaring and immediately using a MooseEnum
in a
validParams()
function is given below:
#include "MooseEnum.h"
template<>
InputParameters validParams<MyObject>()
{
// Create a list of options (comma separated list of options
// in a single string), and optionally supply a default option
// as the second argument in the constructor
MooseEnum myOptions("Option1, Option2, Option3, ...OptionN", "Option1");
InputParameters params = validParams<ParentObject>();
params.addParam<MooseEnum>("myProperty", myOptions, "A property used in my calculation");
return params;
}
You can extract a MooseEnum parameter like any other type, and it can be reassigned. The assignment will throw an error if the assigned string is not valid for the MooseEnum (as defined in its constructor).
MooseEnum foo = getParam<MooseEnum>("myProperty");
foo = "Option2";
The MooseEnum can be compared to string literals:
if (foo == "Option1")
{
// Do something with "Option1"
}
Or used in a switch statement (by default, the enumeration numbering starts at 1):
MooseEnum test("first, second, third", "first");
switch (test)
{
case 1:
// do something with "first"
break;
case 2:
// do something with "second"
break;
case 3:
// do something with "third"
break;
default:
mooseError("Unhandled enumeration!");
}
In this section, commands which are to be typed into the shell are
preceded by a dollar sign $
, to represent the shell prompt.
Building MOOSE
First, make sure you have the latest version of the repository. MOOSE is constantly being updated. Update your local repository:
$ cd ~/projects/trunk
$ svn up
If you are receiving errors during the building of MOOSE or your application, there is a possibility that libMesh is not compiled correctly. To verify libMesh is not the issue, first make sure you are up to date, and then try rebuilding it:
$ cd ~/projects/trunk
$ svn up
$ cd ~/projects/trunk/libmesh
$ ./build_libmesh_moose.sh
During the configure stage, verify you can find status messages similar to the following somewhere in the output:
---------------------------------------------
----- Configuring for optional packages -----
---------------------------------------------
checking for /opt/packages/petsc/petsc-3.1-p8/gnu-opt/include/petsc.h... yes
<<< Configuring library with MPI from PETSC config >>>
<<< Configuring library with PETSc version 3.1.0 support >>>
<<< Configuring library with Hypre support >>>
If you don't see this text, or there are errors about not finding PETSc, then please scroll down to the Environment section below, and verify that your environment is correct. Building libMesh may take a few minutes. Once it is complete, navigate to your application and run make there:
$ cd ~/projects/trunk/<your_application>
$ make -j4
If there is an error during the building of your application, running
the run_tests
script in each directory your application depends on
is a good way to isolate issues. For MOOSE, for example, there is a
separate location where tests are run from:
$ cd ~/projects/moose_test
$ make -j4
$ ./run_tests -j4
Environment
If something in your environment is not set correctly, check that the following environment variables are set.
- Verify that PETSc is indeed installed in $PETSC_DIR:
$ echo $PETSC_DIR
/opt/packages/petsc/petsc-3.1-p8/gnu-opt
- Verify that MPICH is installed:
$ echo $MPI_HOME
/opt/packages/mpich2/mpich2-1.4.1p1/gnu-opt
- Verify that we will actually be using said MPI installation:
$ which mpicc
/opt/packages/mpich2/mpich2-1.4.1p1/gnu-opt/bin/mpicc
- Verify libMesh will be using mpicc during the build:
$ echo $CC
mpicc
- Verify that gfortran is in your PATH:
$ which gfortran
/usr/bin/gfortran
If each of these tests produces reasonable output, but libMesh still fails to configure/build, then you should contact Jason Miller for further assistance.
If you're in a hurry, a simple last-step cop-out is to try reinstalling the MOOSE package. The MOOSE package may be re-installed safely multiple times, and this procedure may solve a possible environment issue.
If you are not using the MOOSE redistributable package, you are responsible for building the following pieces of software yourself:
- C, C++, and Fortran compilers. We recommend Clang with GNU Fortran or the GNU Compiler Collection.
- An MPI library. We recommend either mpich or openmpi.
- HYPRE
- PETSc
- libMesh
The trick here is to do "vector coupling". What this means is coupling to an arbitrary number of variables simultaneously.
How do you do such a thing? The input file syntax is as follows:
[AuxKernels]
[./]
type = SummingAux
variable = the_sum
coupled_vars = 'var1 some_other_var var25'
[../]
[]
That will couple var1
, some_other_var
and var25
into SummingAux
as
coupled_vars
. Note: coupled_vars
is the name of the coupling
parameter that you added using params.addCoupledVar()
like usual.
Now... how do you get out the value of each one? This requires some slightly more advanced C++ code involving pointers. In your class you do this:
In your header file:
class SummingAux : public AuxKernel
{
private:
std::vector<VariableValue *> _vals;
std::vector<VariableGradient *> _grad_vals;
...
};
In your source file:
SummingAux::SummingAux(const std::string & name, InputParameters parameters)
: AuxKernel(name, parameters)
{
int n = coupledComponents("coupled_vars");
_vals.resize(n);
_grad_vals.resize(n);
for (unsigned int i=0; i<_vals.size(); ++i)
{
_vals[i] = &coupledValue("coupled_vars", i);
_grad_vals[i] = &coupledGradient("coupled_vars", i);
}
}
What this is doing is filling up vectors of VariableValue
and
VariableGradient
pointers. You can then loop over them as follows:
for (unsigned int i=0; i<_vals.size(); ++i)
the_sum += (*_vals[i])[_qp]
Or whatever your particular application requires. The trick is that
you have to dereference the pointers in the vectors (that's the
(*_vals[i])
part) and then index by _qp
like you normally do for a
coupled variable.