1. 20 Feb, 2020 1 commit
    • Benoît LÉ's avatar
      Implementation of cylindrical boundary conditions · 0f93c375
      Benoît LÉ authored
      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
      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.
  2. 10 Feb, 2020 1 commit
  3. 31 Jan, 2020 1 commit
  4. 23 Jan, 2020 1 commit
    • Benoit LE's avatar
      Added integ2appro to computeMeanFieldnb. · 6c106abc
      Benoit LE authored
      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.
  5. 22 Jan, 2020 1 commit
  6. 08 Jan, 2020 1 commit
    • Benoit LE's avatar
      Squashed commit of the following: · e9b33a34
      Benoit LE authored
      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.
  7. 07 Jan, 2020 1 commit
    • Benoit LE's avatar
      Removed unused functions · 26d0b150
      Benoit LE authored
      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.
  8. 11 Dec, 2019 1 commit
  9. 27 Nov, 2019 2 commits
    • Benoit LE's avatar
      Safety updates in xEnergyModel · d8806340
      Benoit LE authored
      - 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
    • Benoit LE's avatar
      Renamed damage and damage derivative evaluators. · 18ff05e6
      Benoit LE authored
      - Takes into account commit 32fbe17bd67dd1fb33932f4bba9ced5db1ebe618 in Xfiles (renaming of xEvalGradTLSDamageFunction to
      - 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.
  10. 14 Nov, 2019 2 commits
    • Alexis SALZMAN's avatar
      xEnergyModel: make xEneryModel a little safer · c16a04bc
      Alexis SALZMAN authored
      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.
    • Alexis SALZMAN's avatar
  11. 13 Nov, 2019 1 commit
  12. 06 Nov, 2019 1 commit
  13. 30 Sep, 2019 2 commits
  14. 26 Sep, 2019 1 commit
    • Alexis SALZMAN's avatar
      Add d_integ_order in DamageGrowthBase to fix integration order · b85b8924
      Alexis SALZMAN authored
      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
  15. 19 Sep, 2019 2 commits
  16. 12 Sep, 2019 3 commits
    • Benoit LE's avatar
      Modified the way the force_first_initiation parameter is given to DamageGrowth* · 25755a76
      Benoit LE authored
      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.
    • Benoit LE's avatar
      Added a boolean parameter to switch between different search for initiations... · fe68d87b
      Benoit LE authored
      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
    • Benoit LE's avatar
      Moved test on Fast-Marching parameters consistency. · bd85fe88
      Benoit LE authored
      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.
  17. 10 Sep, 2019 1 commit
  18. 21 Jun, 2019 2 commits
    • Benoit LE's avatar
      Correction of some bugs related to softening functions · 814952eb
      Benoit LE authored
      - 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
    • Benoit LE's avatar
      Bug correction in compute_velocity_maxmode_FastMarching_test · 27a70519
      Benoit LE authored
      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).
  19. 19 Jun, 2019 1 commit
  20. 18 Jun, 2019 1 commit
  21. 14 Jun, 2019 1 commit
  22. 12 Mar, 2019 2 commits
  23. 01 Mar, 2019 1 commit
  24. 28 Feb, 2019 3 commits
  25. 25 Feb, 2019 1 commit
  26. 04 Feb, 2019 1 commit
  27. 29 Jan, 2019 1 commit
  28. 21 Dec, 2018 1 commit
  29. 15 Oct, 2018 1 commit
    • Benoît LÉ's avatar
      Add numerical diffusion with FM computation of non local fields · b56670f9
      Benoît LÉ authored
      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
  30. 11 Sep, 2018 1 commit