Let us point that, there is no general guidelines, most troubles are behaviour specific. However, here are some advises to may help you. Note that those advises are worth considered during the behaviour implementation, before "real-world tests".
The first thing to do is to identify the trouble.
If your computations are very CPU intensive and if the divergence appends after a noticeable amount of time, it is worth enabling the generation of a
MTest file on failure. This feature is for example supported by the
I thus assume that your are using
You can use
--debug command line option when compiling the
MFront file. This will print some information about convergence at runtime. For example, it may show:
In this case, you may want to print some of your variables to see what is happening. If the large values appears due to unrealistic prediction of the stresses, in particular at the second iteration, the
Implicit scheme allows you to limit the
Newton steps or use more robust algorithms (
LevenbergMarquardt). Otherwise, you must check your units.
In the second case, the trouble may be related to your implementation of the Jacobian matrix (assuming you are using an
Implicit scheme with analytical jacobian). In this case, it is worth comparing your jacobian to a numericall one (see
@CompareToNumericalJaobian). As this comparison is CPU intensive, please consider specifying this keyword in the command line rather than in your implementation to avoid forgetting removing it in your real-world tests:
$ mfront --obuild --interface=castem --@CompareToNumericalJacobian=true norton.mfront
Spurious oscillations may also be caused by an ill-conditioned system, see the
In this case, you may want to build your
MFront libraries with debugging symbols. This can be done by defining the
CXXFLAGS environment variable before the behaviour compilation. For example:
$ export CXXFLAGS="-g" $ mfront --obuild --interface=castem norton.mfront
or even better
$ CXXFLAGS="-g" mfront --obuild --interface=castem norton.mfront
c-shell, you must use the following lines:
$ setenv CXXFLAGS "-g" $ mfront --obuild --interface=castem norton.mfront
You can then launch
MTest in the
gdb debugger like this:
$ gdb --args mtest -fpe norton.mtest
You must type
gdb to start the computations. The
-fpe command line option will cause the program to fail a the invalid operation and
gdb will show you which line causes the trouble. Beware that this line may be in the generated code. In this case, this information will not be useful and you shall return to manual search of the problem.
For all domain specific languages,
MFront defines the real
typedef which is used to abstract to floating-point type used by the calling solver. For example, if the calling solver works in double precision, real will be a
double. If the calling solver works in quadruple precision, real will be a
Thus, we do recommend not to use the numerical types defined by the
C++ language directly.
We now get more specific and only deal with mechanical behaviours.
For scalar values,
MFront introduces many different
typedef to be able to express the nature of the variable :
For vector values,
MFront introduces these
For symmetric tensor values,
MFront also introduces many different
Finally, for tensor values,
MFront introduces these
For the moment, distinction between those various types is only informative. We hope to introduce more severe tests in future versions of
MFront so that we won't be able to add a
StressStensor and a
TFEL library already provides the mandatory types to do that.
You can also directly use to types provided by the
TFEL library. The most interesting ones for the end user are :
tvector<N,Type>(fixed sized vector)
tensor<N,Type>(non symmetric tensor)
tmatrix<N,M,Type>(fixed sized matrix)
st2tost2<N,Type>(linear application changing a symmetric tensor to a symmetric tensor)
st2tot2<N,Type>(linear application changing a symmetric tensor to a non symmetric tensor)
t2tost2<N,Type>(linear application changing a non symmetric tensor to a symmetric tensor)
t2tot2<N,Type>(linear application changing a non symmetric tensor to a non symmetric tensor)
N is the size for vectors, the number of rows for matrices and the spatial dimension for the other types.
M is the number of columns for the matrices.
Type is the underlying numeric type.
The difference between those types is currently purely informative : the user can use these types to improve the readability of their code which is strongly encouraged.
TFEL library has support for quantities (number associated with units) which allows to checks for the consistency of operations at compile-time (no cost at runtime). However, support for this feature has not been enabled in
MFront yet : for the moment, we only have introduced the associated types.
The following figure shows how the various blocks defined by the user may be used when using the
Implicit domain specific language: