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

NOTICE is renamed README.

DamageBand is under GNU GPL license

Taking into account modifications on xDeltaTime.

See merge request TTK/DamageBand!20

Modified include and added a "using eXlibris_tools::xDeltaTime" to take into account commit 7a5f0493 in Xfiles by A.
Salzman.

Add numerical diffusion with FM computation of non local fields

Closes #14

See merge request TTK/DamageBand!19

Added the possibility to introduce numerical diffusion when computing non local fields, using modes built with the Fast Marching approach (see user documentation). Note that it uses the same diffusion parameter penalty_coef in damageinfo.dat than the Lagrangian computation, which is noted "beta" in the user documentation.

Note that this method may not be optimal for several reasons:
1) Compared to the "classical" computation, which uses only a matrix-vector product, it requires to solve a linear system

2) The assembling of the matrix may not be optimal. Indeed, let:
   - m be the number of modes
   - n be the number of nodes in the damaged zones and the narrow band
   - K_m be the modal diffusion operator (size m*m)
   - K be the nodal diffusion operator (size n*n)
   - M the mode matrix (size m*n)

K_m can be computed as K_m = M*K*M' , where X' is the transpose of matrix X.

In DamageBand, M is given as M1 and M2, where M1 corresponds to the n1 nodes inside the damaged zone, and M2 to the n2 nodes which are in the narrow band. We can write M = [M1 M2].

Within this commit, M1 and M2 are copied into a single xDenseMatrix M, M' in another xDenseMatrix matrix. Then U=K*M' is computed using the gemm function of xGenericSparseMatrix, and finally K_m*M*U is obtained using the gemm function of xDenseMatrix. Another way to build K_m would be to consider that :

 K_m= M1*K11*M1' + M1*K12*M2' + M2*K21*M1' + M2*K22*M2 and K=[K11 K12; K21 K22], where index 1 corresponds to nodes in damaged zone and index 2 to nodes in the narrow band.

However, this would require to implement the gemm function for C = A.B', which is not trivial. Also, a thorougher investigation would be necessary to determine if it would really be faster.

3) Aggregating adjacent modes to get evenly wide modes could also be another way to introduce diffusion, or eventually complementary to the diffusion introduced in this commit

Note that a few functions have been introduced in this commit:

- computeMeanElementSizeInDamagedBand : performs computation of the mean element size in the damaged band. It just consists in the few lines of code which were initially at the begining of the compute_velocity function. Putting them in another function makes the code easier to read, and factorizes lines of codes
that would have been copy/pasted, if one wants to add another compute_velocity function

- createModesVelocityProblem : the idea of this function, similarly to what is done in compute_elastic by the createMechanicalProblem function, is to factorize steps common to any computation using the FM modes computation of non local fields. For now it only contains:
    - the createModalLocalisationSpace function
    - the export of the different modes
    - the computation of the diffusion operator K_m, if penalty_coef>0.

One could imagine that in the future, if modes computation requires other pre-treatments, they could be put inside this function

This commit requires functionnalities introduced by commit 2ce67f257db9ff9de0c13f968d72f8af9835d269 in Xfiles.

Fixes #14

Factorization of the searchForInitiations functions

Closes #7

See merge request TTK/DamageBand!18