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 `castem`

(`Cast3M`

), `aster`

and `cyrano`

interfaces.

I thus assume that your are using `MTest`

.

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:

- large values of the residual.
- a divergence (residual growing) or spurious oscillations in the residual.
`NaN`

propagation.

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 (`PowellDogLeg`

, `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 `setNormalisationFactor`

method.

`NaN`

propagation.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`

In `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 `r`

in `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.

`MFront`

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 `typedef`

to `double`

. If the calling solver works in quadruple precision, real will be a `typedef`

to `long double`

.

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 :

`real`

, `frequency`

, `stress`

, `length`

, `time`

, `strain`

, `strainrate`

, `temperature`

, `energy_density`

, `thermalexpansion`

, `massdensity`

For vector values, `MFront`

introduces these `typedef`

:

`TVector`

,`DisplacementTVector`

, `ForceTVector`

For symmetric tensor values, `MFront`

also introduces many different `typedef`

:

`Stensor`

, `StressStensor`

, `StressRateStensor`

, `StrainStensor`

, `StrainRateStensor`

Finally, for tensor values, `MFront`

introduces these `typedef`

:

`Tensor`

, `DeformationGradientTensor`

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 `StrainStensor`

. The `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)`stensor<N,Type>`

(symmetric tensor)`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)

where `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.

`Stensor`

, `StressStensor`

and `StrainStensor`

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.

The `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: