1. 07 May, 2020 1 commit
    • Benoit Le's avatar
      Update to take into account last commits in Xfiles + clang format · 22b16f02
      Benoit Le authored
      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.
      22b16f02
  2. 06 May, 2020 1 commit
  3. 11 Mar, 2020 1 commit
  4. 09 Mar, 2020 2 commits
  5. 06 Mar, 2020 1 commit
  6. 04 Mar, 2020 1 commit
    • Benoît LÉ's avatar
      Changed default value for boundary_list · 9d2032cc
      Benoît LÉ authored
      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.
      9d2032cc
  7. 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
      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.
      0f93c375
  8. 10 Feb, 2020 1 commit
  9. 31 Jan, 2020 1 commit
  10. 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.
      6c106abc
  11. 22 Jan, 2020 1 commit
  12. 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.
      e9b33a34
  13. 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.
      26d0b150
  14. 11 Dec, 2019 1 commit
  15. 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
      d8806340
    • 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
      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.
      18ff05e6
  16. 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.
      c16a04bc
    • Alexis SALZMAN's avatar
  17. 13 Nov, 2019 1 commit
  18. 06 Nov, 2019 1 commit
  19. 30 Sep, 2019 2 commits
  20. 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
      https://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/issues/21)
      b85b8924
  21. 19 Sep, 2019 2 commits
  22. 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.
      25755a76
    • 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
      fe68d87b
    • 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.
      bd85fe88
  23. 10 Sep, 2019 1 commit
  24. 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
      814952eb
    • 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).
      27a70519
  25. 19 Jun, 2019 1 commit
  26. 18 Jun, 2019 1 commit
  27. 14 Jun, 2019 1 commit
  28. 12 Mar, 2019 2 commits
  29. 01 Mar, 2019 1 commit
  30. 28 Feb, 2019 2 commits