The formula which gives integ_order_elastic (integration order in the damaged zone) may give odd integration order.
Odd integration order may give negative weight in Gauss Legendre Quadrature, which can cause some factorizing issue
when solving the linear system to compute equilibrium. Therefore, if the formula gives an off value for
integ_order_elastic, we take the even number which is immediatly higher.

small detail change to make lib and test compile again with latest Xfile
version

These updates deal with the following point :

- [DamageGrowthBase.cc] DamageGrowthBase constructor : reInitLevelSetFromFrontWithHanging and reInitLevelSetFromFrontCGAL3WithHanging which are now template : no particular issue

- [DamageGrowthMechanics.cc] DamageGrowthMechanics::createMechanicalProblem() : DeclareInterpolationHanging has three more arguments

-  [DamageEvals.*] xUpperCreatorFilteredFilter and xUpperCreatorFilteredRecursive (in DamageEvals.*) : was_created_by tag removed, use new mechanism to get attached entity (maybe these two classes could be moved to xFEM ?)

- [DamageGrowthBase.cc,DamageGrowthMechanics.cc,DamageGrowthOctree.cc] xIntegrationRulePartition : at several places in the code, xIntegrationRulePartition were used, however since the new commit, a getPartition function must be given as the first argument. In the framework of TLSImplicit, it seems logical to use the getPartition from TLSGeomInterface. Therefore, the get_integ_rule function was use where xIntegrationRulePartition were previously created from scratch.

test/simple_square was not working since a parameter needed to be set in the damageinfo.dat. I added : d_integ_order = 1

Previous default value was 202, very dangerous if a mesh with a BC boudary with ID 202 is used and no gamma in is
wanted (may make you lose a few hours looking for a bug that does not exist). Changed it to -1, as it is unlikely that
somebody will assign a negative ID to a physical boundary.

Cylindrical Dirichlet boundary conditions can now be applied, using the keywords DISPLACEMENT_R and DISPLACEMENT_TETA. For now, only cylindrical coordinates with and origin of (0,0,0) and
a z axis (0,0,1) can be applied, which means that the structure must be oriented along the Z axis and centered on (0,0,0) (which should not be a problem for most of the cylindrical
problems).

It was chosen not to implement it for Octree computations, since Octree computations are performed on rectangular structures, but this could eventually be implemented if necessary.

See commit 63a68f9.

Following commit 3cc692f4 in Xfiles

Added an integ2appro to DamageGrowthMechanics::computeMeanFieldnb, in the case
where a Xbar vector is computed by integrating over an iso value instead of the
damaged zone for instance.

xOppositeP2Double was doing exactly the same thing as xfem::xCompl, so we remove it.

commit 524c88fc60f927e3ed6f6dbc82b4b24a58173880
Merge: 9a39c0e 26d0b150
Author: Benoit LE <ble@pc-str33.ec-nantes.fr>
Date:   Tue Jan 7 11:39:30 2020 +0100

    Merge branch 'master' into correctSearchForInit
Bug correction in search for init

Correction of  DamageGrowthMechanics::findInitiationPoints() : search for init is made after the level-set update, which means that the enrichments have been
destroyed. Therefore, the enrichment in disp_l does not work anymore (enrichment are created again at the begining of the next computation step). This
should not be a problem, since search for init is performed only in the sane zone with no enrichment (so disp_l should never be used where the
enrichments have been destroyed), however it has been observed that it can cause some bugs.

To fix this issue, a disp_l_continu xField is created, containing only the continus interpolation function. Then, the setEvalStrain function of xEnergyModel is
called before performing the search for init, which is realized with this new, continus field. At the end of course, setEvalStrain is called again to
set the strain evaluator with the classical disp_l xField.

Note that this was already coded before the commit of xEnergyModel and xDissipation model, but was probably forgotten when adding this two classes.

Bug noticed by A. Salzman.

Removed createValuesDiscontinuous, updateValuesDiscontinuous and createSpaceDiscontinuous from DamageGrowthMechanics, as
well as all the related implementations.

These functions were (probably ?) dealing with enrichment creation and update, but are not used anymore (this is done by the
TLSEnrichement class).

Also removed the ENRICH macro.

See issue #54 for explaination on comment and throw introduced
in DamageGrowthMechanics to suppress exportSupportComponentGmsh call
for now.

- Added a dummy copy constructor, making a throw when called. Otherwise, if one tries to copy an instance A into a new instance B, the default constructor is used. However, with this
default constructor, if A is modified, B is also modified, which is not wanted. A proper implementation of the copy constructor still needs to be found (it is unfortunately not trivial)

- Corrected use of  eval_tensor_4 union, especially in init() (no need to initialize all members of eval_damaged_hooke and eval_elastic_hooke) and clear() function (use of proper type to
delete eval_damaged_hooke and eval_elastic_hooke)

Modifications made after discussions with A. Salzman

- Takes into account commit 32fbe17bd67dd1fb33932f4bba9ced5db1ebe618 in Xfiles (renaming of xEvalGradTLSDamageFunction to
xEvalTLSDamageFirstDerivativeFunction)
- peval_damage and peval_grad_damage are renamed eval_damage and eval_damage_first_derivative (takes into account renaming of gradDamage),
since these evaluators are not pointers anymore.

The eval_strain pointer member have been modified to a xEvalWarper
object to secure a little xEneryModel class.

Now setEvalStrain may be called after setEnergyAssymTensionCompression
without problem as setEnergyAssymTensionCompression use now the eval_strain
warper. setEvalStrain is now changing the underlying evaluator, not the
eval_strain itself.

This do not prevent the case where setEnergyAssymTensionCompression is
called without any call to setEvalStrain. In this case at run time any
attempt to use evaluator reference provided by getEvalXX methods will
lead to dereference a null pointer ...

Be careful, the actual copy constructor behavior will generate a object
strongly connected with the original instance. Calling setEvalStrain for
the original instance or its copy will change the underlying strain
evaluator for both ...

This commit is an intermediate step. Maybe future will be to add
new factory class either to generate xEneryModel or to update during
copy the set of generated instance. Depending on followed solution
pointer may be transformed in unique pointer and xEnergyModel
instance copy prevented.

Takes into account commit c8b56a21 in Xfiles/xTensor.

Added a power softening function, which is convex with respect to phi, provided that a Poly2Revert damage profile is used.

Modified the type of hardening_power in DamageInforParser.h to double.

Form B.Le an A.S. work

This commit remove the hard coded assertion that d(phi) is a function
corresponding to a polynomial of order 3.
Now a d_integ_order parameter is used in formulas to represent needed
integration order for d(phi).
This parameter is set by default to -1 so that user who choose damage
shape function that are not polynomial must enter (in damageinfo.dat file)
a value for this parameter. Otherwise polynomial damage shape
function impose appropriate value to this parameter and default or
user imposed values are ignored.

Note that formula for integ_order_velocity is only correct for Ybar and
not for Ycbar,... (see issue
https://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/issues/21)

Modification of DamageGrowthMechanics::computeModesDiffusionMatrix to use upper creator given by TLSGeomInterfaceSignedVectorDistanceFunction (getFrontUpperCreatorFunction()) instead of a mere
xUpperCreator. In case of iso-zero passing exactly on a node, using a xUpperCreator made the computation abort (xUpperCreator is not able to return the upper creator entity).

To avoid increasing the number of arguments of DamageGrowth* constructors, force_first_initiation is now given to it using the damageinfo (xParseData). In the exemple of DamageTest or DamageOctree, it is set
to 1 before constructing DamageGrowthMesh/DamageGrowthOctree, which means that any value given by the user in the damageinfo.dat will not be taken into account. Of course, depending on the
new DamageTest that may be eventually added, the freedom to input this parameter via the damageinfo.dat can be given to the user if necessary.

After some discussion with A. Salzaman, it seems that using this damageinfo should be used to input parameter to DamageGrowth*, without adding new arguments to the constructors. The only
additional arguments should be classes, object, etc that can be given using a xParseData.

Added a boolean parameter to switch between different search for initiations at first computation step

A new boolean member "force_first_initiation" was added to DamageGrowthBase. It it used in findInitiationPoints() to eventually force a damage initiation at first computation step.

In the first implementation of the TLS, where the problem is solved for a reference load, a damage zoned is inserted at the first computation step where Y is maximal, even if max(Y) < Yc. A damage front is necessary to compute load
factor. For the next steps of course, new damaged zone can be inserted only where max(Y) > Yc

By introducing this force_first_initiation parameter and setting it to false, damage initiation is allowed IF and ONLY IF max(Y) > Yc. This makes the findInitiationPoints() function more general.

Two remarks about this parameter:
- It was chosen not to give it as a default parameter of the DamageGrowth* family, since the way of dealing with the first damage initiation will be very specific to the TLS formulation/DamageTest (Quasi-static with a computed load factor, or
a more classical approach with imposed load). Furthermore, we hope that it will encourage people adding new versions of the TLS to be careful about the meaning of this parameter
- This parameter could eventually be given in damageinfo.dat. For now we do not think that it is necessary, since for a given DamageTest, its value should not changed anymore

Moved test which was checking that when Fast-Marching modes are used (fast_marching_modal_space > 0), the correct TLSGeomInterface is used (tls_geom_interface = 3), inside DamageGrowthBase constructor, right after these parameters
are initialized.

This was previously checked when calling compute_velocity. The problem is that in some situation (in some further deloppement for instance), compute_velocity may not be called at the begining of the computation (for instance, if we
have a non damaged body for several computation steps). In such a situation, the user may realize that he/she chose the wrong parameters only after running several computation steps. This is now fixed.

- Corrected compute_velocity_maxmode_FastMarching_test so that it can be used with non constant softening function (may not be recommended but at least it is possible)
- Modified a bug in xEvalHardeningPower and xEvalHardeningDerivativePower, formulas were wrong (bug found by Benjamin Shiferaw during his phd, 2018-2019)
- Modifed xEvalHardeningPower and xEvalHardeningDerivativePower so that the exponent beta (in H(D)=1+alpha*D^beta) is an integer, otherwise we don't have H(0)=1

Corrected a bug in compute_velocity_maxmode_FastMarching_test, which was making the damage zone
grow larger than expected when using it with a constant sofetning function. Removed the
macro which were preventing to use it by default.

Remark : this bug was found by Sai Praneeth Devadula during his master internship (2019).

Modified CMakelists.txt to include xExport.

Refactoring 2019:  takes into account new libs in Xfiles and new namespaces + rename  DamageBand -> TLSImplicit