1. 10 Nov, 2020 2 commits
    • Nicolas CHEVAUGEON's avatar
      [xFEM] xBoundary.h/cc are moved to xFEM/src/attic · 5c4579b3
      Nicolas CHEVAUGEON authored
      class xBoundary was only used as a parameter to some
      Mechanics::TreatmentOfNatEnv that was never actually used and which was
      passed around via a member of xData. It is nothing more than an early
      implementation of xSubMesh that was passed around via cut and past for a
      long time ... Therefore, xBoundary is now made obsolete and the files
      xBoundary.h/cc are moved to xFEM/src/attic.
      all its' use will be removed from xTest.
      Note : My first clang-format related bug.
      The file xDistanceNearestPointGenerator.h need to be included before
      xDistanceNearestPoint.h, otherwise some test case can't compile !!! indeed,
      it add some overload to cgal AABBPrimitive that needs to be visible for
      template instanciation that can take place via  xDistanceNearestPoint.h.
      But clang-format messed around and I had to force the inclusion of xDistanceNearestPointGenerator.h before xDistanceNearestPoint.h, by including it at the
      beginning of xDistanceNearestPoint.h, and preventing clang-format to reorder
      the include by inserting some comment.
    • Nicolas CHEVAUGEON's avatar
      m] library xGeomTools added · bc14d18b
      Nicolas CHEVAUGEON authored
      Main changes :
      - A new library xGeomTools is added in xGeom.
        *This library is meant to collect "simple" geometrical classes/functions.
         By "simple" we mean that they dependent only on xtensor, and xtool.
        *All the classes and functions of xGeomTools are in namespace xgeom.
        *For this commit it contains :
         xBoundingBox.h/cc, xOctreeGrid.h, xRegularGrid.h/cc, xSimpleGeometry.h,
         moved from xTensor or xFEM.
        *Previous library xGeom is split in two libraries : xDistanceNearest and
         xScanElement in respectivevly xGeom/xDistanceNearest
         and xGeom/xScanElement,
        *The old xGeom library do not exist any more.
        *Note that the 3 libraries contained in directory xGeom populate
         the namespace xGeom.
        *Global build option BUILD_XGEOM is removed.
          BUILD_XSCANELEMENT are added.
        *xGeom/CMakeLists.txt is removed
        *xUTil/cmakeUtil :
         FindxGeomTools.cmake, FindxDistanceNearest.cmake, FindxScanElement.cmake
         added, FindxGeom.cmake is removed.
        *xAnalyticalSolution, xCrack, xDoubleCut, xLegacySimpleCut, xDomainDecomp,
         xExport, xExt, xFEM, xInterfaceAOMD, xMeshInterface, xOctree, xMapping,
         xTLS, now depend on  xGeomTools.
        *xOctree and xTLS now depends on xDistanceNearest
      - xBoundingBox :
        *added member functions  inclose(), now used in xMesh, xSubMesh
        and xLagrangeMapping.
        *added default constructor and constructor for 2 xPoint.
        *default constructor now build an  empty "bb"  by havinh min(i) > max (i)
      - xRegularGrid : dependencies to xMesh are removed.
      - xMesh.h :  part of previous xOctreeGrid that was dependent of xMesh are
        no directly implemented in xMesh. (see xMesh::createGrid() and
      Miscanelous changes along the way (removing useless dependencies)
      - xValue.cc : removed "useless" inclusions of "xApproxFunction.h",
        "xField.h", "xLevelSet.h", "xSpacePolynomial.h", "xTensors.h",
        "xTensorsPtr.h" "xVector.h" as well as useless using AOMD::mEdge
        and using AOMD::mEntity.
      - xValue.h : removed useless inclusions of  <set>,
        <boost/graph/adjacency_list.hpp>, <boost/graph/connected_components.hpp>,
        "xTensorsPtr.h", "xDebug.h", "xNearestNeighborInterface.h"
      - xValue_imp.h : removed useless includes "mEdge.h" and "xGeomeElem.h"
      - xValueManager.h - removed dependencies to xMesh.
      - some of AOMD include cascading in other files because of the previous
        removed inclusion were putting std::string in global namespace.
        std::string is now added in the following files :
        std::string xExport.h, xExportEnsight, xExportGmsh.h
        xExportTranslate.cc/h, xField.h, xFEM/src/xSpacePolynomial.h.
      - xData.cc inside void xData::ReadInfo(const char *filename),
        unused variable xBoundary crvboundary; is removed.
      - all modified and added files are clang-formatted.
  2. 17 Sep, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xFEM,xCut] remove AOMD dependancy and friend to xSupportComponent class · 5f4ffd7b
      Alexis SALZMAN authored
      In this commit xSupportComponent is no longer derived from attachable
      model of AOMD. This make it more general.
      In the same spirit the friend class xPhysDomain is removed. It was
      intended to avoid some component creation in instance of
      xSupportComponent by anything but xPhysDomain. Now the method is made
      public and  xSupportComponent instance can be modified.
      As this class is a key feature of future mesh tool chain this
      generalization was mandatory to fit to : A block of the tool chain
      provide a service to access support component via a functor that return
      const xSupportComponent.
      This functor type is now given by xSupportComponent.h header.(TODO
      must replace some typdef in xDoubleCut)
      xDoubleCut has to be modified accordingly. Now in xPhysDomain class
      use of tag for xSupportComponent is replaced by
      xAttachedDataManagerAOMDGeneric mechanism. Not that knowsupportcomponent
      member is suppressed and its action treated via the new usage of
      Note also that update with change of definition is now dealing
      correctly with support (see dom5 in disk example which is now cleanly
  3. 09 Sep, 2020 1 commit
  4. 01 Sep, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [Xfiles] removing using xxx in global namespace in headers. · af6f2b76
      Nicolas CHEVAUGEON authored
          - lot of using std or using xfem or using std::string etc ..  were still present in global namespace in some header. Following a discussion with A. Salzman, I removed most of them.
          - In the transition from mPoint to xPoint, Some using point = xtensor::xPoint were defined inside some class (xMapping, xElementfor example... ). They were identifyed as confusing by A. Salzman and are now removed.
          Most of the changes in this commit reflect the previous change. The guideline is to avoid hiding namespace at least at global scope in header-file. This can avoid some confusion and some surprising and hard to track effects where some stuff compil or not depending on the order of inclusion of header files.
  5. 24 Jul, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xcut] xPhysSurByTagging : no more direct aomd tag · 4c99be34
      Nicolas CHEVAUGEON authored
      Two tag on aomd entities, only owned by xPhysSurfByTagging needed to be replaced by a datamanager : the tag_support, and the tag_entities. they are used to store on entity information relative to their position with regard to the iso-0 of the level-set use to construct the xPhysSurf.
      information related to tag support are only relative to entities of the base mesh on wich the leve-set is defined and the migration for this case was quite easy.
      for the entities tag, the job was more difficult since the data is associated on entities of  :
      - The base mesh
      - a partition mesh attach to any entity of the base mesh, and that eventually recursivelly.
      - of the boundarymesh that represent the iso-zero and also on partition mesh related to entities of the boundary mesh
      The above is difficult because no entity should be destroyed before the data associated to it had the chance to be cleared. This contrast with the "automatic" cleaning behaviour of the data directlty attached to the entity via the direct aomd tag mechanism.
      The Major part of this commit is therfore the rewrite of the clear() function of xPhysSurfByTagging, that take properly (I hope ) into account the fact that multiple xPhysSurfByTagging can be contructed on the same mesh and can create a recursion in the partition up to level 2.
      This rewrite give us a little better functionality for xPhysSurfByTagging :
      It is now possible to create Two xPhysSurf that have partition mesh that intersect and then destroy the second  and recover the state has if the second one was never created. This is nice, and make global call to cleanPartition() not usefull any more, and potentially damaging (if you delete the partition before clearing your xPhysSurf you will get into trouble ... see above). On the other hand, it also mean that promotors need to be preciselly stated and that xPhysSurfbyTagging abject must always be destroyed ore cleared in reverse construction order.
      small details :
      xPhysSurfByTagging :
       - added a public clear member function.
       - destructor now calls clear().
       - clear called by construct_ ()and therefore by constructor and by update.
      xTLSGeomInterfaceV0 : this version use 3 xPhysSurByTagging. it's clearing function have been rewrittre to  delete it's xPhysSurf in reverse construction order.
      Note :
      There is only one raw tag left in xcut/xlegacysinglecut : the tag related to "sideof" I need to coordinate with B. Le to finish this one. I think it should desappear ...
      Last Note : I got caught by the old compiler on titan (g++ 4.8) I had a
      very strange bug : in a constructor I was using the new {} syntaxe to
      call the constructor of each member of a class befor entering
      constructor scope, instead of the old (). I was using into to initialise
      a const reference to a xPhysSurfByTagging with another const reference
      to the same type .... Turn out that it was calling the copy constructor
      od xPhysSurByTagging in this case, but not when using the () !  Note that with a more recent
      compiler, this trouble did not show up. To avoid this to happen again I
      marked the copy constructor as deleted for xPhysSurfByTagging. We really
      should do the same for all class that we want to make sure that no
      default copy constructor would be instancied ...
  6. 22 Jul, 2020 2 commits
  7. 21 Jul, 2020 3 commits
    • Nicolas CHEVAUGEON's avatar
    • Nicolas CHEVAUGEON's avatar
      [xcut/xDouvleCut] xSignedVectorLevelSetData is not derived from mAttachableData any more. · 4e0c6873
      Nicolas CHEVAUGEON authored
      Since it is not directly attached to mEntity via tag, it's not needed
      any more to have xSignedVectorLevelSetData  derived from
    • Nicolas CHEVAUGEON's avatar
      [xcut] xSignedVectorLevelSet aomd tag usage replace by datamanager · ae375cff
      Nicolas CHEVAUGEON authored
          * xSignedVectorLevelSet is now using a datamanager to store SVLSdata at vertex instead of AOMD tag.
          * xSignedVectorLevelSet was a template on the iterator used to construct it. Template parametrization was needed to store the iterator needed for the clean up of tagged vertex. With the use of DATAMANAGER to store the xSignedVectorLevelSetData, we do need this template parameter any more at class level. Now only the constructor on iterator are template.
          * The members for xSignedVectorLevelSet that are not template anymore are moved to the new xSignedVectorLevelSet.cc file.
          * This as concequencies first on xIsoMathReWithSVLS, which is not a template any more, and it's member implementation have been moved to xIsoMathRep.cc
          * This also have consequencies on the different xeval build on to of a xSignedVectorLevelSet : they don't need to be template any more on the previous xSignedVectorLevelSet Iterator's type.
          * At all places where a xSignedVectorLevelSet or an  xIsoMathReWithSVLS is declared, the template parameter needed to be removed. In particular in TLSGeomInterfaceSignedVectorDistanceFunction.cc/h TLSGeomInterfaceSignedVectorLevelSet.cc/h
          * xSignedVectorLevelSetData as been changed slightly to allow for default constructor and assignment operator nedded to be used in a DataManager concept (Note :  it is not the first time I needed to do something similar ... I don't like it. It would be better if the DataManager had somesort of "emplace" setData function)
          Note : We have two differents class for very similar concept : xSignedVectorLevelSet and xVectorLevelSet. The difference is that xSignedVectorLevelSet carries a "metric" information at each vertex where it is defined. I'm thinking about removing xVectorLevelSet in a futur commit. But first the mechanism to store/compute the "metric" need to be changed since it still rely on AOMD tag.
  8. 13 Jul, 2020 1 commit
  9. 02 Jul, 2020 1 commit
  10. 01 Jul, 2020 1 commit
  11. 30 Jun, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem] About xMesh::del · 746332b0
      Nicolas CHEVAUGEON authored
      When changing xMesh from a derived class of mMesh to a class containing an mMesh,
      the fact that void xMesh::del(AOMD::mEntity *pe) was an overload was overlooked.
      mMesh::DEL(AOMD::mEntity *pe) call the del virtual function. Since xMesh is not derived from mMesh any more xMesh's del is not called any more when calling DEL on an mMesh pointer or reference.
      To avoid the ambiguity, I removed the del function from xMesh. Whenever one want to DEL a mEntity from a mMesh embedded in an xMesh, one should first call clear(pe) on the xMesh to make sure all the data belonging to the xMesh and associated to pe are cleared.
      This change have been implemented where needed in the library. It fix the issue with test case simple_use_xphysurfCutDom.
  12. 25 Jun, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xmapping] made fully independent from Trellis · 23c79dc2
      Nicolas CHEVAUGEON authored
      xmapping now have it's own enum type xReferenceElementType defined in
      xReferenceElement. It is there to replace Trellis mType inside xMapping.
      The xMappingBuilder are moved to xfem. Rational : The builder work on
      mEntity that are not supposed to be known by mapping.
      This being done the only dependencie left in xMapping is the dependecies to
      a function is added in xAOMDEntityUtil.h to get the xReferenceElement from
      the mEntity, as well as conversion fonction from xReferenceElement to
      mType. In the current version of the library, this function is only used
      in xfiles to create  a Trellis_Util::GausIntegrator out of a xMapping.
      Therefore these conversion function might become useless when we make
      our own Trellis free Integrator.
      Most of the other change in this commit are consequencies of the above.
      Small other minor change are listed below :
      -xfiles_dependence.dot has been updated with xmapping dependencies.
      -delete mapping added in xElement::xyz2uvw ...
       this was missing and was causing a memory leak.
        (Note : It might be better for the builder to return smart pointer to
        mapping instead of newed pointer ... )
      - xTensor2 semi-colon were removed where it was useless and issued a warning.
      - xVector : copy assignement added. Rational : since we have a no default copy
        constructor, a default copy assignement is deprecated in the standard
        according to gcc
  13. 17 Jun, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xmapping] xmapping now use xtensor::xVector<> and xtensor::xTensor2<> · 05482f34
      Nicolas CHEVAUGEON authored
          up to now, xmapping was using Trellis_Util::mVector and Trellis_Util::mTensor2.
          This commit change that to further reduce it's dependencies to Trellis, and replace them with xtensor::xVector<> and xtensor::xTensor2<>.
          implyed changes in xmapping :
          - FEM/src/xMapping.h : do not include mTensor2.h and mVector.h any more.
          - xMapping/test/testxLagrangeMapping/main.cc : a binary operator - for mTensor2 was implemented to facilitate the tests. This operator already exist for xTensor2<> and is removed from this main.
          Implyed or other changes outside of xmapping :
          - xCut/xLegacySimpleCut/src/xRefCutToAOMD.h was including xMapping.h. It is useless at current stage and this include is removed.
          - xFEM/src/xGeomElem.cc : some implemetation are simplifyed since we do not need to convert some xVector<> to mVector or xTensor2<> to mTensor2 when calling xMapping members functions.
          - xTLS/src/xRefCutToCGAL.h was including xMapping.h when it just needed a forward declaration of xMapping. This is fixed.
  14. 15 Jun, 2020 1 commit
  15. 04 Jun, 2020 1 commit
  16. 03 Jun, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem] xMeshFwd.h and xIntegrationRuleFwd.h removed. · 071f55cd
      Nicolas CHEVAUGEON authored
          Added xPartition.h where can be found the definition of xPartition and
          Added xIter.h where can be found the definition of xIter and xClassIter
          xScalarFunctionDerivDiscXFEMOctree, previoulsy in xApproxFunction.h is
          moved to it's own file : xApproxFunctionDerivDiscXFEMOctree.h
          datamanagerxMesh_t and partmanagerxMesh_t are removed.
          Other files are modifyied accordingly and clang-formated.
  17. 12 May, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      clang-formated · de534315
      Nicolas CHEVAUGEON authored
          removed comment and added file xFEM/src/xDomain.h
      [xfem] xDomain, zone_tag.
      Previously, we had a raw aomd tag, zone-tag, created throught xDomainStringManager with the name "zone". It was use to set that a mesh entity was belonging to a "zone" with a id related to a zone_name throught xZone. It was set for example using xClassifyOn and It was used in particular by the xEntityFilter xAccept, xAcceptNot, xAcceptOnZoneId, xAcceptUpperAdjancencies And xGeomElem getZone() member function.
          * I replaced the usage of a raw aomd tag by a new class xDomain defined in xDomain.h, implemented using an xDataManagerAOMD.
          * xClassifyOn, xAccept, xAcceptNot, xAcceptUpperAdjancencies and  xGeomElem::getZone() are reimplemented using this xDomain.
          *xAcceptOnZoneId was not reimplemented since it was almost the same as  xAccept. Previous usage of xAcceptOnZoneId(int) can be safely replaced by xAccept(int)
          *xDomainStringManager.h and xDomainStringManager.cc that where previously only use to set up the aomd tag zone_tag are removed.
          *xDomainAttachableData.h that used to define an mAttachableData suittable to attach domain information is now useless and removed
          *Since it was previously stored as an attachData, it was automatically destroyed each time an mEntity was destroyed. To have the same effect, the xMesh::del(mEntity *e) have been updated to clear the xDomain from mention of e.
          *The header inclusion #include "xDomainAttachableData.h", "xDomainStringManager.h" are removed where needed in the library :
           - xCut/xLegacySimpleCut/src/xMeshCut.cc, xFEM/src/xEntityFilter.cc, xFEM/src/xEntityToEntity.cc, xFEM/src/xGeomElem.cc, xFEM/src/xIntegrationRule.cc, xFEM/src/xMesh.cc, xPhysics/src/xpThermic.cc
          all the following files are clang-formated :
       Changes to be committed:
      	modified:   xCut/xLegacySimpleCut/src/xMeshCut.cc
      	new file:   xFEM/src/xDomain.h
      	deleted:    xFEM/src/xDomainAttachableData.h
      	deleted:    xFEM/src/xDomainStringManager.cc
      	deleted:    xFEM/src/xDomainStringManager.h
      	modified:   xFEM/src/xEntityFilter.cc
      	modified:   xFEM/src/xEntityFilter.h
      	modified:   xFEM/src/xEntityToEntity.cc
      	modified:   xFEM/src/xEntityToEntity.h
      	modified:   xFEM/src/xGeomElem.cc
      	modified:   xFEM/src/xIntegrationRule.cc
      	modified:   xFEM/src/xMesh.cc
      	modified:   xPhysics/src/xpThermic.cc
  18. 10 May, 2020 2 commits
    • Nicolas CHEVAUGEON's avatar
      [xcut] xPhysSurf Updated to use cut function of xcut/xLegacySimpleCut/xMesh.h/cc · eae565dc
      Nicolas CHEVAUGEON authored
      xPhysSurf now store references to datamanager passed at construction to update them and pass them to the cut function. the datamanager have for now default value to the corresponding data Manager in xMesh. It uses the cut function defined in xcut/xLegacySimpleCut/xMesh.cc/.h
      XPhysSurfOctree and xPhysSurf3 (from xPhysics) have also been updated.
       xPhysSurfOctree octree now use internal datamanager instead of some xMesh static tags to store it's internal data.
      Since xPhysSurfOctree have been changed a lot, the interface and the implementation of xScalarFunctionDerivDiscXFEMOctree (xfem/xApproxFunction.h.cc) have been updated.
      some loop are rewritten as range loop.
       modified and clang-formated :
    • Nicolas CHEVAUGEON's avatar
      [xcut] xMeshCut.h/cc : slight changes to avoid silent usage of xMesh::get_was_created_by() · dc7a1de9
      Nicolas CHEVAUGEON authored
      getOriginalCreator and , classifyElement,that return recursively the creator of an entity now take the datamanager that store the creator information as an input argument instead of using the xMesh::get_was_created_by() static member.
  19. 07 May, 2020 3 commits
    • Nicolas CHEVAUGEON's avatar
      [xFEM xLevelSet] · 0ef7f77b
      Nicolas CHEVAUGEON authored
      * xLevelSet members takeTraceOn and interpolateTo have an interface change :
        void takeTraceOn(const xMesh& target_mesh, const datamanagerxMesh_t<AOMD::mEntity*>& was_created_by,
                          const datamanagerxMesh_t<double>& r_on_edge, xLevelSet& trace) const;
        void interpolateTo(const xMesh& mesh_new,
                            const datamanagerxMesh_t<AOMD::mEntity*> &was_duplicated_from,
                            const datamanagerxMesh_t<AOMD::mEntity*> &was_created_by,
                            xLevelSet& lsnew) const;
        Rational : we need to know what data are needed for this function to work. I'm trying to make the silent
        use of data, previously managed directly by tagappear in the interface.
        Related changes :
          lCrack.cc, xMeshCut.cc, xRefCutToAOMD.cc, xDoubleCutting.cc
          now call the revised version of xLevelSet::takeTraceOn, xLevelSet::InterpolateTo
      * Added xLevelSet Function :
        double &at (const AOMD::mVertex& v);
        const double &at(const AOMD::mVertex& v) const;
        this function return ref to the value stored at vertex v or throw. Rational : we already have double & operator()(AOMD::mEntity  * ), used to set values at vertices, but this function can silently add data in the associative map, breaking the support. I think it's usage should be replaced everywhere by .at(const vertex &) and the function removed from xLevelSet.h
        other member function in xLevelSet are now implemented using .at(v)
      * Some other minor changes are applied in xLevelSet member function implementation to simplify them or get ride of compiler warning  :
        void xLevelSet::complement()
        bool xLevelSet::isDefinedAt(mEntity* v)
        void xLevelSet::setSupport(const xRegion& m, const double& val)
        std::vector<double> xLevelSet::getVals(const mEntity& e) const
        double xLevelSet::getVal(mEntity* e, const Trellis_Util::mPoint& uvw) const
        xtensor::xVector<> xLevelSet::getGrad(mEntity* e, const Trellis_Util::mPoint& uvw) const
      * xLevelSet.h and xVectorLevelSet.h were included in xAlgorithm.h for no reasons. I removed these inclusions.
      side effect : xVectorLevelSet.h was pushing std::set and std::string to global namespace ... After removing the inclusion
      of xVectorLevelset.h in xAlgorithm.h, xAlgorithm was not knowing set anymore. All the reference to set in xAlgorithm.h are replaced by std::set
      using std::set and using std::string are removed from xVectorLevelSet.h
      The following files are clang-formated :
    • Nicolas CHEVAUGEON's avatar
      [xFEM, xcut] Moving cut related function out of xMesh class to xcut namespace. · 97286dad
      Nicolas CHEVAUGEON authored
      Rationnal : xMesh class used to contain function related to the cutting of a mesh. This won't be acceptable in a future were we want to have a generic mesh query interface (that can not modify or create a mesh). All the cut function should be outside of xMesh, the functionalities should be implemented in xcut.
      In order to do that in staged commit, the file xMeshCut.cc that contain the old implementation of the cut function of xMesh is renamed to xMeshCut_depracted.cc. This file will be removed in a futur commit.
      All the needed function are reimplemented with a new interface in xCut/xLegacySimpleCut/src/xMeshCut.h/cc in the xcut namespace, as non-member function of xMesh. No tag are supposed to be used in theses  versions, only data_manager. For the current commit, these versions are not use in the library.
      Function declared in xMeshCut.h:
      void createIsoZeroMeshFromLevelSet(const xfem::xLevelSet& ls,
                                                xfem::xMesh & imesh,
                                                datamanager_t<AOMD::mEntity*>& was_created_by,
                                                datamanager_t<double>& r_on_edge, const bool simplex_only = true, const bool debug = false);
      inline void createIsoZeroMeshFromLevelSet(const xfem::xLevelSet& ls,
                                                xfem::xMesh & imesh,
                                         const bool simplex_only = true, const bool debug = false){
          datamanager_t<AOMD::mEntity*> was_created_by;
          datamanager_t<double> r_on_edge;
          createIsoZeroMeshFromLevelSet(ls, imesh, was_created_by, r_on_edge, simplex_only, debug);
      void cutAlongInterface(const xfem::xMesh& interface,
                              const datamanager_t< AOMD::mEntity *> &was_created_by,
                              datamanager_t< xfem::xMesh > &partition,
                              datamanager_t< AOMD::mEntity *> &is_duplicated_in,
                              datamanager_t< AOMD::mEntity *> &was_duplicated_from,
                              datamanager_t< AOMD::mEntity *> &is_in_partition_of
      void cutAlongInterfaceRecursive(const xfem::xMesh &interface, const xfem::xLevelSet& ls,
                                       const datamanager_t< AOMD::mEntity *> &was_created_by,
                                       datamanager_t< xfem::xMesh > &partition,
                                       datamanager_t< AOMD::mEntity *> &is_duplicated_in,
                                       datamanager_t< AOMD::mEntity *> &was_duplicated_from,
                                       datamanager_t< AOMD::mEntity *> &is_in_partition_of);
      void cutMesh(const xfem::xMesh &base_mesh, const xfem::xLevelSet& ls, xfem::xMesh& iso_zero_mesh,
                   datamanager_t< AOMD::mEntity *> &was_created_by,
                   datamanager_t< double > &r_on_edge,
                   datamanager_t< AOMD::mEntity *> &is_duplicated_in,
                   datamanager_t< AOMD::mEntity *> &was_duplicated_from,
                   datamanager_t< xfem::xMesh >    &partition,
                   datamanager_t< AOMD::mEntity *> &is_in_partition_of,
                   xfem::xEntityToEntity classify_in,
                   xfem::xEntityToEntity classify_out,
                   bool create_partition,
                   bool keep_old_partition,
                   bool recursive);
      void cutMesh(const xfem::xMesh &base_mesh, const xfem::xLevelSet& ls, xfem::xMesh& iso_zero_mesh,
                   xfem::xEntityToEntity classify_in,
                   xfem::xEntityToEntity classify_out,
                   bool create_partition,
                   bool keep_old_partition,
                   bool recursive);
      AOMD::mEntity* getOriginalCreator(AOMD::mEntity* egros);
      Minor changes :
      - centroid function now implemented in xinterface::aomd in file xInterface/AOMD/general/src/xAOMDEntityUtil.h :
      Trellis_Util::mPoint centroid(const AOMD::mEntity& e)
       - xMeshFwd.h contains a new declaration :
      template <typename T>
      using datamanagerxMesh_t = xinterface::aomd::xAttachedDataManagerAOMD<T>;
      rational : it permit to export the data manger used internally in class xMesh whithout having to include xMesh.h It will be used more rationnaly in a next commit.
      - The following files are clang-formated to help the next commit:
    • Nicolas CHEVAUGEON's avatar
      [xFEM/xMesh] static xMesh tags is_the_copy_of_tag and has_a_copy_tag are removed. · 65fe407b
      Nicolas CHEVAUGEON authored
      They where used by the void 'xfem::xCopyMesh (xMesh *in, xMesh *out, bool clean_tag_on_source_mesh = true)'  function. The previous function is therefore rewritten, in two variants in xMesh.h :
      void xCopyMesh(const xMesh& in, xMesh& out, xMesh::datamanager_t<AOMD::mEntity*>& is_copied_to, xMesh::datamanager_t<AOMD::mEntity*>& is_the_copy_of);
      void xCopyMesh(const xMesh& in, xMesh& out);
      The first one copy mesh in into mesh out, keeping track of the relations between entities of the 2 meshes, using datamanager. The second one do not keep track.
      xCut/xLegacySimpleCut/src/xPhysSurf.cc is updated for this change.
  20. 04 May, 2020 1 commit
    • Alexis SALZMAN's avatar
      [SOME] Add boost finding in some CMakelists.txt · 93d77713
      Alexis SALZMAN authored
      When boost lib is not installed in your system in /usr/include
      the set of lib modified by this commite were in default. As they
      use xTool xIteratorTools.h they depend on boost header and no
      cmake operation give them access to none system boost version. The simple
      addition of some Find Boost mechanism covers this prb. Not sure that
      it is the best way to solve this issue ... as already said
      modern-cmake may be used and in this case give dependency of xtool
      to correct boost.
      Please in future pay attention to boost dependency. If you add any don't
      forget to add find in cmake. Boost are not always installed in
      Durty hack to chose the right mkl lib on new c6 Liger install. Should be
      completely revisited ....
  21. 16 Apr, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem] some Tag in xMesh replaced by datamanager. · ed62fc25
      Nicolas CHEVAUGEON authored
            some static Tag in xMesh are replaced by static datamanager :
            is_duplicated_in, was_duplicated_from, is_in_partition_of
            Each one now as it's get and get_const associated member.
            -Applied in the following in xMesh.cc xMeshCut.cc :
              void xMesh::setDataManagers(), void xMesh::clear(mEntity *),
               mEntity *getSource(mEntity *e),
              xMesh *xMesh::refineInNewMesh(int n, bool debut),
              void xMesh::attachSimplicies(mEntity* e),
              xMesh* xMesh::cutElement(mEntity* e, mEntity* e_interface) and
              mVertex* xMesh::vertexInBetween(mEntity* v0, mEntity* v1,
                      const std::vector<mVertex*>& vertices)
            -Applied in xFEM/src/xEntityToEntity.cc/h :
               xPartitionCreatorRecursive and  xUpperAdjacencyPartition
            -Applied in xFEM/src/xEnv.cc : xEvalNormal
            -Applied in xFEM/src/xLevelSet.cc : xLevelSet::interpolateTo
          Implied interface change:
          xRefCutToAOMD.h/cc :xRefCutToAOMD does not use any of the all xMesh tag now.
          Instead it update and use datamanagers that are passed at construction
          xRefCutToAOMD constructor now takes as parameter the datamanagers to store
          the cut results (was_created by, r_on_edge, partition, was_duplicated_from
          and is_in partition of). Note That it still use it's own private tag
          (tag_entities and tag_support ) that will be removed in a next commit.
           applyied in :
            xCut/xLegacySimpleCut/src/xPhysSurfByTagging.cc Wich construct a xRefCutToAOMD
            using the static datamanager from xMesh.
      clang-format following mod files :
              modified:   xCut/xLegacySimpleCut/src/xPhysSurfByTagging.cc
              modified:   xCut/xLegacySimpleCut/src/xRefCutToAOMD.cc
              modified:   xCut/xLegacySimpleCut/src/xRefCutToAOMD.h
              modified:   xFEM/src/xApproxFunction.cc
              modified:   xFEM/src/xEntityToEntity.cc
              modified:   xFEM/src/xEntityToEntity.h
              modified:   xFEM/src/xEnv.cc
              modified:   xFEM/src/xLevelSet.cc
              modified:   xFEM/src/xMesh.cc
              modified:   xFEM/src/xMesh.h
              modified:   xFEM/src/xMeshCut.cc
  22. 13 Apr, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem, xcut] r_on_edge and is_the_creator_of · 79eb01a3
      Nicolas CHEVAUGEON authored
      CHANGES in xMesh.h/cc and xMeshCut.cc
      -static unsigned int xMesh::get_r_on_edge_tag() replaced by
        xMesh::datamanager_t<double> &xMesh::get_r_on_edge()
        and xMesh::datamanager_t<double> &xMesh::get_const_r_on_edge()
        The tag r_on_edge is for now replaced by a global datamanager in xMesh which
        is filled up by both   xRefCutToAOMD and createInterfaceFromLevelSet to store
        the position of the nodes of an interface mesh describing an isolevel of a
        level set on their parentedge. It is typically used in class xLevelSet to
        reinterpol data defined on the edge's node to the intersection point.
        void xMesh::clear(mEntity *) and void xMesh::setDataManagers() are updated.
      -The old global xMesh tag is_the_creator_of, was in fact used only
        "locally" both in xMesh member function  createInterfaceFromLevelSet and
        in xRefCutToAOMD. There is no need to keep a global data of any kind.
        Its is therefore replaced by a local datamanager for this two case.
        In The first case it is destroy at exit of the createInterfaceFromLevelSet
        and in the second at the destruction of the object xRefCutToAOMD.
      - xMesh::createInterfaceFromLevelSet -> interface changed:
         void createInterfaceFromLevelSet(const xLevelSet& ls) ->
         void createInterfaceFromLevelSet(const xLevelSet& ls,
                                     datamanager_t<AOMD::mEntity *> &was_created_by,
      		               datamanager_t<double> &r_on_edge);
        Now the function clearly take two datamanager to represent was_created by
        and r_on_edge.   It was possible to change the interface of
        createInterfaceFromLevelSet so that   (almost) all the data that it
        filled up appears in it's description.
        (it indeed filled up both a was_created_by_tag and r_on_edge.) There are still
        some stuff that happen behind the curtain in this function for cases where non
        -simplex entities in the support of the level-set are cut by the iso-zero
        ("simplexisation" ...) that I plan to improve in a next commit.
        The interface change is applyied were it is used :
        xCrack/src/JintParks.cc, xCut/xLegacySimpleCut/src/xPhysSurf.cc,
        xExt/src/DoubleCutting.cc, xLevelSet.cc
      - xCut/xLegacySimpleCut/src/xRefCutToAOMD.cc/.h are updated to reflect the
        changes with r_on_edge and is_the_creator_of.
      The 9 modified files are also clang-formated :
  23. 10 Apr, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem] Reduces dependencies on xMesh.h. This has implications in other parts of the lib. · 9c703287
      Nicolas CHEVAUGEON authored
          Currently, xMesh.h, by cascading include, is visible by a too large part of
          the library. Change one Character of xMesh.h, and you need to recompile
          the world. The aim of this commit is to reduce these dependencies.
          It affect lots of files but only a little in each. As discuted in meeting,
          I won't clang format them all for this push, But I clang format the added files.
          ADDED FILES :
          1 xFEM/src/xMeshFwd.h
          2 xFEM/src/xIntegrationRuleFwd.h
          3 xInterface/AOMD/general/src/xAOMDEntityUtil.h
          4 xInterface/xOctree/src/OctreeUtilities.cc
          1 xMeshFwd.h : A forward header fo xMesh.h. Include this where you need to
           forward declare the type defined in xMesh, but not there full declaration.
           Typically include it in place of xMesh.h wherever you need the type previously
           defined in xMesh but not their full description (you only declare pointer or
           refs to xMesh, you just need xIter, xClassIter or xPartition or the type of
           partman used inside xMesh (parmanxMesh_t) )
          2 xIntegrationRuleFwd.h, same philosophie as above, a forward header for
           xIntegrationRule. it forward declare class xIntergrationRule and define the
           type def xGetPartion (the function used to parametrize how to get the sub
           elements in the xIntergrationRulePartition familly.
          3 xAOMDEntityUtil.h Some function previously defined in xMesh.h/cc,
           are in fact simple utility function applied on mEntity.
           There are place in the code where they are needed, but where you don't need
           xMesh. For now I moved the following one there, in namespace xiterface::aomd :
            - void getSubentities(AOMD::mEntity* e, const int d,
                                  std::vector < AOMD::mEntity * > &l);
            - void getSupportBoundary(AOMD::mEntity *in,
                                     std::set<AOMD::mEntity *> &supportBoundary )
           They are used in :
            xGeom/src/xDistanceNearestPointGenerator_imp.h, xTLS/src/xRefCutToCGAL.cc
          4 OctreeUtilities.cc This is an implementation file for OctreeUtilities.h
            Following function are moved to the .cc :
            xLevelSetTo_ls_xyz_t_Adaptator::xLevelSetTo_ls_xyz_t_Adaptator(xLevelSet &ls_)
            double  xLevelSetTo_ls_xyz_t_Adaptator::operator()(x,y,z).
            using namespace xfem and using namespace xoctree; are removed from the global
            scope in OctreeUtilities.h
          - xIntegrationRulePartition familly : the getpartition function that
            parametrize how to go from the integ entity to it's sub entity must now be
            given explicitly as a first argument.
            Rational : when first introduced, this parametrization could be implicit
            thanks to a default argument set to the static xMesh::getPartition.
            This implied an unwanted dependencies of xIntegrationRule to xMesh, and make
            user code unclear on the real dependencies of there Integration rule to
            there cutting process. Concerned files :
            xCrack/src/IntegratorSingularCrack3D.cc, xFEM/src/xIntegrationRule.h,
            xFEM/src/xIntegrationRule.cc, xFEM/src/xIntegrationRuleStored.h,
            xFEM/src/xIntegrationRuleStored.cc, xPhysics/src/xpElastic.cc,
            xPhysics/src/xpFluidMechanics.cc, xPhysics/src/xpFluidMechanics.cc,
            xPhysics/src/xpThermic.cc, xTLS/src/TLSGeomInterface.cc,
          - xCrack/src/xcFront.h : added begin and end to iterate on front_parts.
            used to simplify loops in
            in xCrack/src/xcFrontDomainManager.cc, xCrack/src/xcFrontManager.cc,
          - xCrack/src/xcInteractionIntegralsOnCrack.h
            xAcceptLocalPart is now template on the DATAMANAGER that store was_created_by
             affected files : xCrack/src/xcInteractionIntegralsOnCrack.cc
          - xFEM/src/xAlgorithm.h :
            DeclareInterpolationHanging : the datamanager needed need now to be
            explicitlty given (no default value). Rational:  again the default
            value hide to  the user the real dependencies of the algorithm.
          - xFEM/src/xValueCreators.h :
            * xMirrorCreator : used to interconnect xValue on "mirror" entity,
            typically used for periodic Boundary condition. Previously, it was
            using an xMesh pointer and internal call to AOMD's lookupForMirrorEntities,
            on this mesh. This is too dependend on both xMesh and AOMD. Looking closely,
            all that is needed for this algorithm to work is a way to get from one entity
            a list of entity it mirror. The new interface is based on that.
            At construction, full control is given to the user which just have to give
            an std::function that take a pointer to a mesh entity and return the list
            of mirror entity. the pointer to the mesh itself is not needed anymore.
            * xValueCreatorRegularAndHanging : no default value any more for the
            isHangingOn at construction (same rational as for the use of the other
            static datamanger of xMesh, if you use them, do it explicitly.)
            the pointer to the mesh is not needed any more at construction.
          - replaced xMesh.h by xMeshFwd.h or include xMeshFwd.h or remove include xMesh.h
           in the following files :
            xCrack/src/CrackPostpro.h, xCrack/src/lCrack.h, xCrack/src/xcFront.h,
            xCrack/src/xcFrontDomain.h, xCrack/src/xcCrackBase.h,
            xCrack/src/xcFrontDomainManager.h, xCrack/src/xcFrontPart.h,
            xCrack/src/xcFrontSpaceManager.h, xCut/xDoubleCut/src/xElemCutDomainData.h,
            xCut/xDoubleCut/src/xPhysDomain.h,   xCut/xDoubleCut/src/xPolytopeOFF.cc,
            xCut/xLegacySimpleCut/src/xRefCutToAOMD.h,  xExport/src/xPostPro.h
            xExt/src/DoubleCutting.h, xFEM/src/xApproxFunctionCorrectedShifted.cc,
            xFEM/src/xData.h, xFEM/src/xElement.cc,  xFEM/src/xGatherMesh.h,
            xFEM/src/xIntegrationRule.cc, xFEM/src/xIntegrationRule.h, xFEM/src/xRegion.h,
            xFEM/src/xRegularGrid.h, xFEM/src/xMeshFwd.h, xFEM/src/xSubMesh.h,
            xFEM/src/xSubMeshManager.cc, xFEM/src/xSubMeshManager.h, xFEM/src/xValue.cc,
            xFEM/src/xValue.h, xFEM/src/xValueManager.h, xFEM/src/xValue_imp.h
            xFEM/src/xVectorField.cc (include xRegion instead), xFEM/src/xVectorField.h,
            xFEM/src/xVectorLevelSet.h, xGeom/src/xDistanceNearestPointGenerator.h
            (use "xAOMDEntityUtil.h"), xInterface/xOctree/src/surf2LevelSet.h,
            xTLS/src/TLSGeomInterfaceSignedVectorLevelSet.h, xTLS/src/TLSVelocity.h,
          - include xMesh.h in the following files :
            xCrack/src/ExportSensors.cc, xCrack/src/JintModalParks.cc,
            xCrack/src/lCrack.cc,  xCrack/src/xcFront.cc
            xCrack/src/xcFrontDomain.cc,  xCrack/src/xcFrontDomainManager.cc
            xExport/src/xPostPro.cc,  xExt/src/SpaceLagrangeDualBoundary.cc,
            xExt/src/SpaceLagrangeDualNewBoundary.cc, xExt/src/SpaceLagrangeDualSimple.cc,
            xFEM/src/xApproxFunctionCorrectedShifted.cc, xFEM/src/xCommandOnGeomElem.h,
            xFEM/src/xExtendShapeFcts.h, xFEM/src/xGatherMesh.cc,
            xFEM/src/xNonLocalInfoForKeysAndFcts.h, xFEM/src/xRegularGrid.cc,
            xFEM/src/xSubMesh.cc, xFEM/src/xValueCreators.cc,
            xInterface/xOctree/src/surf2LevelSet.cc, xPhysics/src/xPhysSurf3.cc,
            xPhysics/src/xpElastic.cc, xPhysics/src/xpFluidMechanics.cc,
           -removed useless forward declaration of xMesh in :
            xCrack/src/xcFrontSpaces.h, xCrack/src/xcInteractionIntegralsOnCrack.h,
            xCut/xLegacySimpleCut/src/xPhysSurfParameter.h, xExport/src/xSensors.h,
            xExt/src/xPhysBand.h, xPhysics/src/xpFluidMechanics.cc,
            xTLS/src/TLSEnrichment.h, xTLS/src/TLSGeomInterfaceVectorLevelSet.h,
            xTLS/src/TLSValueCreatorRampHeaviside.h, xTLS/src/TLSVelocity.h,
           -replaced include xIntegrationRule.h by xIntegrationRuleFwd.h
            or remove xIntegrationRule.h :
            xCut/xDoubleCut/src/xPhysDomain.h, xFEM/src/xAlgorithm.h, xFEM/src/xField.h,
            xFEM/src/xIntegrationRule.h, xFEM/src/xSpace.h, xTLS/src/TLSGeomInterface.h
          - Trellis/Util/Util/include/mPoint.h
            Added stream operator <<  for mPoint.
          - lCrack.cc/h :
            int lCrack::dim() const,  void lCrack::setV1Ddebug(std::function ...),
            lCrack::~lCrack  are moved to lCrack.cc.
            using namespace xfem moved from global scope to inside namespace xcrack
          - xCut/xDoubleCut/src/xElemCutDomainData.cc :
            now include "mVertex.h"
          - xCut/xLegacySimpleCut/src/xPhysSurf.cc/h  :
            int   xPhysSurfBase::dim() const,   xPhysSurf::~xPhysSurf() and
            xPhysSurfOctree::xPhysSurfOctree  implementations moved to xPhysSurf.cc
          - xExt/src/SpaceLagrangeDualBoundary.cc/h :
            OutsideVertex::OutsideVertex(const xLevelSet* f) and
            AOMD::mEntity* OutsideVertex::operator()(AOMD::mEntity* e) are now
            implemented in the .cc file
          - xFEM/src/xData.cc : data member in xData::nb_evo now initialized to 0
          - xFEM/src/xElement.cc :
            xElement::xyz2uvw(const Trellis_Util::mPoint& xyz) this function that
            invert the mapping was constructing a temporary xMesh in case of QHAD and HEX,
            containing only one element..  This was way more to much than needed,
            since Trellis_Util::Mapping used in this function just need an mEntity.
            I replaced the construction of an xMesh by the construction of the correct
            mEntity only.
          - xFEM/src/xLevelSet.h :  added now needed include unordered_map
          - xFEM/src/xLevelSetOperators.cc :
            call xRegion::dim() instead of xRegion::getMesh()->dim() rational :
            remove deps on xMesh, clearer.
          - xFEM/src/xLevelSetOperators.h :
            removed using std::cout/endl at global scope, added include xEntityFilter
          - xFEM/src/xMesh.h :
            removed using std::map, std::vector, std::set, std::string at xfem scope,
            now   include  xMeshFwd.h, getSupportBoundary and getSubentities now moved to
          - xFEM/src/xRegularGrid.h/cc :  xRegularGrid::xRegularGrid implementation
            moved to .cc
          - xFEM/src/xRegularGrid.h : #define TOL 1.e-06 at xfem scope,
            replaced by  constexpr static  double TOL  = 1.e-06; in xfem::xRegularGrid
          - xFEM/src/xSpace.cc now include "xIntegrationRule.h"
          - xFEM/src/xValueCreatorLinkOnFrontFiltered.cc, in ::buildTable
            a non-standard variable size array was used (vertices).
            Replaced by a std::vector.
          - xFEM/src/xVectorField.cc some loop where rewritted.
          - xInterface/xOctree/src/surf2LevelSet.cc implementation of  surface2LevelSet
            constructors,  computeWeightedPseudoNormals::proceed(),
            surface2LevelSetNarrowBand  are moved to the .cc
            rational : these functions call some xMesh member functions)
          - xPhysics/src/xpEval.h/cc ElementLengthMaterialVariablesVisitor_c moved to .cc
            rational : constructor use some member of xMesh.
          - xPhysics/src/xpPhysicalFormulation.cc  : used xRegion member dim, begin and end instead of asking the same on a region "all" meshes's. (rational : reduce deps on xMesh, clearer code)
          ADDED std:: in front of standard symbol
           By cascading inclusion, using namespace std was visible in some files
           (comming from some AOMD include). After the change in the inclusion hierachy,
           namespace std is not visible any more in some header file. I choose to not add
           using namespace std at global scope of a header file, and add to std::
           in front of standard symbols. Concerned files :
           xCrack/src/JintParks.h, xCrack/src/xcFrontManager.cc,
           xExport/src/xExportAlgorithm.cc, xExport/src/xPostProVTU.h,
           xExt/src/MaterialCommand.h, xExt/src/SpaceLagrangeDualNewBoundary.cc,
           xExt/src/SpaceLagrangeDualNewBoundary.h, xExt/src/ValueOldAndCurrent.h,
           xFEM/src/xAlgorithm.h, xFEM/src/xDistStateOfValue_imp.h, xFEM/src/xElement.cc,
           xFEM/src/xMaterialSensitivity.h, xFEM/src/xSpacePolynomialQH.h,
           xFEM/src/xSubMesh.h, xFEM/src/xValueLinearCombination_imp.h,
           xFEM/src/xVectorLevelSet_imp.h, xFastMarching/src/FMUpdater.h,
           xTLS/src/TLSGeomInterface.h, xTLS/src/TLSVelocityModeEshelby_imp.h,
          ADDED using namespace std :
           Same reason as above, I added using namespace std in .cc files that needed it :
            - xCrack/src/xcFrontDomain.cc, xCrack/src/xcFrontSpaceManager.cc,
              xExport/src/xPostProMSH.cc, xExt/src/SpaceLagrangeDualNewBoundary.h,
          removed using namespace xfem :
          replace some old style cast by static_cast :
            - xExt/src/SpaceLagrangeDualNewBoundary.cc
  24. 08 Apr, 2020 2 commits
    • Nicolas CHEVAUGEON's avatar
      [xFEM] replace xMesh was_created_by_tag by a static DataManager in xMesh. · f2906dd0
      Nicolas CHEVAUGEON authored
          - As usual in this process of removing raw AOMD tag usage, this
            release remove yet another tag :
          was_created_by_tag(), which is use in lots of place in the library
          to refer to the entity that created the current one when it was cut.
          This commit remove the famous was_created_by_tag and replace it with
          a static DATAMANAGER inside xMesh, accessible via get_was_created_by() and
          Not suprisingly, the produced at first  some error in the test case,
          again due to some data still In the manager while the entity is already
          The following point solved this issue.
          -cleaning process of xMesh and an entity of the xmesh is improved.
          In particular we rewrite the override of mMesh::del(AOMD::mEntity *)
          in xMesh, to make sure it actually cleaned all the data related to the
          entity that are owned by xMesh.
          A clear() member function is also defined that empty the mesh
          and all the Data related to it.
         - In xMesh, the DATAMANAGER implementation used can now be easily
           changed.  This is in previsison of what will be needed withe the mesh
           interface ... We need to be able to use something else than
           xAttachedDataManagerAOMD. To try with a new DATAMANAGER implementation,
          just change the definition of template type alias datamanager_t in
          xMesh. It was tested in particular with xUnorderedMapDataManager,
          and it imposed some slight changes in other files updated in this commit.
          In particular some class and function are now template on the
          DATAMANAGER implementation used.
          Testing with other implementation also reveiled some mistake in the
          implementation of .at(key) which are now corrected both in
          xUnorderedMapDataManager and xGeneralUnorderedMapDataManager.
          - changing the name of the preproc guards in xMesh.h that did not
            follow the
            usual format  in Xfiles
          - Racionaliz better the usage of xMesh.get_xxdatamanager() versus
            xMesh.get_xxconstdatamanager(). This make things more clear
            regarding to what function might or might not modify the xMEsh's data.
          - mMesh.createVertex(id, point, ...) is know used almost wherever
            possible in the library, improving
            readability (and may be cleaner compiled programm)
      	modified:   xCrack/src/CrackPostpro.cc
      	modified:   xCrack/src/IntegratorSingularCrack3D.cc
      	modified:   xCrack/src/Jint3D.cc
      	modified:   xCrack/src/Jint3D.h
      	modified:   xCrack/src/lCrack.cc
      	modified:   xCrack/src/xcFront.cc
      	modified:   xCrack/src/xcFrontManager.cc
      	modified:   xCrack/src/xcInteractionIntegralsOnCrack.h
      	modified:   xCut/xDoubleCut/src/xPhysDomain.cc
      	modified:   xCut/xDoubleCut/src/xPhysSurfCut.cc
      	modified:   xCut/xLegacySimpleCut/src/xPhysSurf.cc
      	modified:   xCut/xLegacySimpleCut/src/xRefCutToAOMD.cc
      	modified:   xExt/src/DoubleCutting.cc
      	modified:   xExt/src/SpaceLagrangeDualBoundary.h
      	modified:   xExt/src/SpaceLagrangeDualMinBoundary.cc
      	modified:   xExt/src/SpaceLagrangeDualNewBoundary.cc
      	modified:   xExt/src/SpaceLagrangeDualSimple.cc
      	modified:   xFEM/src/xApproxFunction.cc
      	modified:   xFEM/src/xEntityToEntity.cc
      	modified:   xFEM/src/xEntityToEntity.h
      	modified:   xFEM/src/xGatherMesh.cc
      	modified:   xFEM/src/xGatherMesh.h
      	modified:   xFEM/src/xLevelSet.cc
      	modified:   xFEM/src/xMesh.cc
      	modified:   xFEM/src/xMesh.h
      	modified:   xFEM/src/xMeshCut.cc
      	modified:   xFEM/src/xNonLocalInfoForKeysAndFcts.h
      	modified:   xFEM/src/xNonLocalInfoForKeysAndFcts_imp.h
      	modified:   xFEM/src/xValueCreators.h
      	modified:   xInterface/xOctree/src/AdaptOctreeToAOMD.cc
      	modified:   xInterface/xOctree/src/AdaptOctreeToAOMD.h
      	renamed:    xInterface/xOctree/src/AdaptOctreeToAOMD.cc -> xInterface/xOctree/src/AdaptOctreeToAOMD_imp.h
      	modified:   xInterface/xOctree/src/InterfaceOctreeToAOMD.cc
      	modified:   xInterface/xOctree/src/InterfaceOctreeToAOMD.h
      	renamed:    xInterface/xOctree/src/InterfaceOctreeToAOMD.cc -> xInterface/xOctree/src/InterfaceOctreeToAOMD_imp.h
      	modified:   xInterface/xOctree/src/OctreeUtilities.h
      	modified:   xInterface/xTemplateRefineMesh/src/xSplitAOMD.cc
      	modified:   xTLS/src/TLSVelocity.cc
      	modified:   xTLS/src/reInitLevelSetFromFront.cc
      	modified:   xTLS/src/reInitLevelSetFromFront.h
      	new file:   xTLS/src/reInitLevelSetFromFront_imp.h
      	modified:   xTLS/src/xAcceptNotHanging.cc
      	modified:   xTLS/src/xAcceptNotHanging.h
      	modified:   xTLS/src/xEvalWeightedDirectionalAverage.cc
      	modified:   xTLS/src/xEvalWeightedDirectionalAverageMode.cc
      	modified:   xTool/src/xGeneralUnorderedMapDataManager.h
      	modified:   xTool/src/xUnorderedMapDataManager.h
    • Nicolas CHEVAUGEON's avatar
      [xFEM, xCut, xExt] removing raw tags : partition_tag · 8be52876
      Nicolas CHEVAUGEON authored
      Main Changes :
          in xMesh, the static tag partition_tag used to attach the submeshes
          a cutted entities is replaced by a static xAttachedDataManagerAOMD<xMesh>
          called xMesh::partition.
          as for the other tag replacement in xMesh, it is a private static
          member, one cas access it in const or non const version bien calling
          xMesh::get_const_partition() or
          All the previous use in the library and the test case of
          get_was_created_by_tag() have been corrected. It first leads to some memory problemes
          revealed by the test cases
          at final destructions, and some related changes had to follow to
          solve them.
      Related changes :
         - xMesh * xfem::xData::mesh, usually allocated by xData is now
           properly destroyed by
            calling delete, .mesh is not a nullptr.
            Since it was not the case before, lots of test cases were crashing
            at exit destruction
            since the dataManager where still refering to some destroyed
            In the test cases, for the rare cases where the user was manually
            setting the the .mesh pointer to a stack variable adress or
            to a pointer that he newed on his side, the data.mesh pointer is
            set to nullptr before
            the destruction  of the data variable. This insure that in most
            used cases the mesh in xData is cleanly destroyed in xData destructor.
          - We need to ensure that the static datamanager of xMesh are
            constructed after and   destroyed before the AOMD::Util::instance()
            construction and destruction, that manage the meshdata id.
            They are  now therefore constructed as static inside the get functions,
            instead of relying on default static member variable initialization.
            Only the  get_xxx() and get_const_xxx() are now visible in the
            .h file. The  get_xxx() and get_const_xxx are now the only way to get
            access to the    datamanager, even in a member function of xMesh.
          - Correcting some trouble with some test cases, it appeared that,
            all the  xAttachedDAtaManagerAOMD needs to be initialized at the creation
            of the first xMesh :  Other wise, an other AOMD tag could be created and
            then  destroyed, without having all the data associated to it properly
            cleaned. Then at a xMesh detruction, we could get for the first
            time one of the static xAttachedDAtaManagerAOMD in order to clean
            it up, so that a tag previously used could be reused while some
            data   with the same tag still exist at time of the xMesh destruction.
      Minor Changes
          - xSignedVectorLevelSet_imp.h constructor from iterator and stream
            has been updated, so that we don't have strong dependencies in the order
            of the vertices in the iterators relative to the order of the data in
            the  mesh. This was usefull to solve troubles with test case
            hammerhead for example.
          - using createVertex(id, point, ...)  in xPhysSurfCut.cc
          - some clean up of commented out stuff in xMesh.cc
      	modified:   xCut/xDoubleCut/src/xPhysSurfCut.cc
      	modified:   xCut/xDoubleCut/src/xSignedVectorLevelSet_imp.h
      	modified:   xCut/xLegacySimpleCut/src/xPhysSurf.cc
      	modified:   xCut/xLegacySimpleCut/src/xRefCutToAOMD.cc
      	modified:   xExt/src/DoubleCutting.cc
      	modified:   xFEM/src/xData.cc
      	modified:   xFEM/src/xExtendShapeFcts_imp.h
      	modified:   xFEM/src/xMesh.cc
      	modified:   xFEM/src/xMesh.h
              modified:   xFEM/src/xMeshCut.cc
  25. 28 Mar, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [Trellis/AOMD] added mMesh member functions createVertex that take an mPoint... · 2b76bfca
      Nicolas CHEVAUGEON authored
       [Trellis/AOMD] added mMesh member functions createVertex that take an mPoint as input instead of 3 doubles.
          before this commit, there was 3 different createVertex member functions
          in mMesh:
          createVertex(Id, x,y,z, classif)
          createVertex_noUpdateId(Id, x, y, z, classif)
          this commit add 3 new :
          createVertex(p, classif)
          createVertex(Id, p, classif)
          createVertex_noUpdateId(Id, p, classif)
          this reduce verbosity of client code.
          It is now used in the following files, but more are comming :
  26. 05 Mar, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xFEM xCrack xCut xExt xTLS] unifying (a bit ..) tag usage from xMesh · 5b5841a1
      Nicolas CHEVAUGEON authored
      xMesh gives acces to (a huge number of ) statically defined tag used to attach information on mEntity. before this commit there was to was to access theses tag :  either by directly accessing the static data member xxxx_tag or by calling the static member  function  get_xxxx_tag(). This to way of doing the same thing complicate the cleaning up of the tag usage in the library.
      After this commit, all the static member xxx_tag becomes private. Only the get_xxx_tag() function are public.
  27. 13 Feb, 2020 1 commit
  28. 07 Feb, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xCut] correct bug in xPhysSurfCut update( fix issue #62) · 2614853d
      Alexis SALZMAN authored
      Now cleanAroundEdge is not cleaning close node AttachedEntity with
      iso_creator_tag. It is flagged and edge is also flagged as treated.
      Then at end of the loop on update edge a dedicated loop over flagged
      node do:
      * the cleaning of iso_creator_tag attached data
      * pass in review all adjacent edge to clean element around them so
      that new close node situation if any is treated correctly (i.e. a new
      iso is created and a new iso_creator_tag link is made with close node).
      Successfully tested in 2D with B.L.
  29. 27 Jan, 2020 1 commit
    • Grégory LEGRAIN's avatar
      Let there be template fields ! · 3cc692f4
      Grégory LEGRAIN authored
      This is a first implementation of template fields in eXlibris.
      Thanks a lot to Alexis (@asalzman) and Nicolas (@nchevaugeon) for fruitful discussions !
      Fields can now handle other quantities than double (complex for instance).
      This has led to multiple changes:
      * xDoubleManager disappears
      * xValueDouble disappears
      * Assembly is now templatized
      However, the changes are small with respect to the interface in your applications (see the testcases).
          Notable changes
      Is replaced by  xValueManagerDist<T> ("Dist" stands for "distributed"). This template class handles other values  than double.
      Example : xValueManagerDist<double> value_manager;
      In your end-user code (AND NOWHERE ELSE), you can define a convenient typedef :
      using  xDoubleManager = xValueManagerDist<double>;
      xValueDouble is replaced by xSingleValue<T> where T stands for the type which is stored.
      Move value creators in xValueCreators.h
      is now template (should not influence end-user code)
      xStateDofCreator, xStateFixedCreator are also template.
      now template against the approximated quantity: xField<double> for a double-valued field
      Major internal modifications: "everything" is handled by the specialization of getVal and getGrad. For example:
      template <class iterFct, class iterVal>
      static void getVal (iterFct it, iterFct ite, iterVal first, iterVal last, int size_Fct_Val,
                    const xGeomElem* geo_appro, const xGeomElem* geo_integ, std::complex<double>& v);
      xFormBilinear, xFormLinear:
      A new template is added (double by default):
      template <typename VT = double> class xFormBilinear;
      It corresponds to the type of quantity which is stored in the elementary stiffness matrices (note that xFemMatrix and other are now template). Usually, you can keep it as double, but this is not mandatory (see BUILD_COMPLEX_VALUED_OPERATORS in test case complex2d).
      xAssembler, xAssemblerTraitPolicy, xDispatcher are modified to take into account the other changes.
      An example of complex-valued field is given in Xtest/xfem-para-test/complex2d (however, see issue #58)
      KNOWN limitations/issues (that will be fixed later on):
      * type dependent code in xField is still part of the class. We should try to move this code away from the core of the class (issue #60).
      * float and complex version of mumps are still not available, so you cannot fully run any float or complex testcases for the moment  (see issue #58)
      * the compiler on titan (gcc 4.8) has troubles during template deduction for some template functions (DeclareInterpolation, DeclareState), see issue #59. The syntax had to be modified in order to help the compiler, leading to verbose notations.
  30. 11 Dec, 2019 1 commit
    • Alexis SALZMAN's avatar
      xFEM/xCut: move and make uniform xSupportComponent · bd0f4df7
      Alexis SALZMAN authored
      The xSupportComponent concept is now in xFem so that future
      enrichment may use this class as an uniform link between cutting
      procedures (xPhysSurfCut, xPhysSurfByTagging, ....) and enrichment
      function creation.
      In this commit the xSupportComponentVLS disapear as now replaced by the
  31. 09 Dec, 2019 1 commit
    • Nicolas CHEVAUGEON's avatar
      remove the depencies of xFEM on xExport · 967e0a06
      Nicolas CHEVAUGEON authored
          Before the current commit, we had the problem that the xfem library depends on the export library and vice versa. This cyclic dependencies causes lot of problemes for the build.
          In particular, it was very difficult to make some of our test case build with cmake version 3.13.4
          To make xFEM independant of xExport, the main task was to move the Export algorithms out of the xFEM library. All these algorithm are now implemented in xExportAlgorithm.h/cc int the xExport library, under the xexport name space.
          That done, some dependencies remained in the xVectorLevelset.h/cc. This file previously contain our first version of vectorlevelset (that came before the signed vector distance function) and the first version of the 2d doublecut algorithm, embedded in the class xPhysSurfVLS. The class xPhysSurfVLS itself has been moved where I think it belong, to xCut/xLegacy and the xcut namespace in file xPhysSurfVLS.h/cc. This being done we are one step closer to also have removed the cyclic dependencies between xfem and xcut.
          Most of the other changes in the library reflect the fact that we now have to include xExportAlgorithm.h to have access to the Export algorithm which is now in name space xexport. The same work as been done in the xTest repository and will be commited next.
          A small "bug" in  xUtil/cmakeUtil/FindNoHeaderLibrary.cmake as also been corrected. (it was always printing lapack REQUIRED whatever the library that was missing)
       + small modif in FindTAUCS.cmake. It was freezing when TAUCS_INCLUDE_PATH was not set.
      Squashed commit of the following:
      commit 1f50932ee6a6a4dde8cd35d5793112a6f4b934d4
      Merge: 9e3ba9e db82eb04
      Author: Nicolas CHEVAUGEON <nchevaug@titan.ec-nantes.fr>
      Date:   Mon Dec 9 10:36:16 2019 +0100
          Merge remote-tracking branch 'origin/master' into remove_xexport_dep
      commit 9e3ba9e57013dfa2de1e39163b29faa409a2cb21
      Author: Nicolas CHEVAUGEON <nchevaug@titan.ec-nantes.fr>
      Date:   Mon Dec 9 10:02:36 2019 +0100
          finishing the move of Export algo to xexport.
          + small modif in FindTAUCS.cmake. It was freezing when TAUCS_INCLUDE_PATH was not set.
      commit fa64d29ddc406acd5225774b7aae487072b0666c
      Merge: 8a6a9557 f94d6e0
      Author: Nicolas CHEVAUGEON <nchevaug@titan.ec-nantes.fr>
      Date:   Fri Dec 6 12:05:11 2019 +0100
          Merge branch 'tryingtobuild' of http://git.gem.ec-nantes.fr/nchevaugeon/Xfiles_Save into remove_xexport_dep
      commit f94d6e0b722c7066f526d7e45970a2c02ed27d9d
      Author: chevaugeon <nicolas.chevaugeon@ec-nantes.fr>
      Date:   Fri Dec 6 09:38:34 2019 +0100
      commit b3ac48f0d5d5d29ea8ab8f5798775e607598525b
      Author: chevaugeon <nicolas.chevaugeon@ec-nantes.fr>
      Date:   Wed Dec 4 16:30:33 2019 +0100
          remove the depencies of xFEM on xExport
          Before the current commit, we had the problem that the xfem library depends on the export library and vice versa. This cyclic dependencies causes lot of problemes for the build.
          In particular, it was very difficult to make some of our test case build with cmake version 3.13.4
          To make xFEM independant of xExport, the main task was to move the Export algorithms out of the xFEM library. All these algorithm are now implemented in xExportAlgorithm.h/cc int the xExport library, under the xexport name space.
          That done, some dependencies remained in the xVectorLevelset.h/cc. This file previously contain our first version of vectorlevelset (that came before the signed vector distance function) and the first version of the 2d doublecut algorithm, embedded in the class xPhysSurfVLS. The class xPhysSurfVLS itself has been moved where I think it belong, to xCut/xLegacy and the xcut namespace in file xPhysSurfVLS.h/cc. This being done we are one step closer to also have removed the cyclic dependencies between xfem and xcut.
          Most of the other changes in the library reflect the fact that we now have to include xExportAlgorithm.h to have access to the Export algorithm which is now in name space xexport. The same work as been done in the xTest repository and will be commited next.
          A small "bug" in  xUtil/cmakeUtil/FindNoHeaderLibrary.cmake as also been corrected. (it was always printing lapack REQUIRED whatever the library that was missing)
  32. 27 Sep, 2019 1 commit
    • Grégory LEGRAIN's avatar
      [xTensor] Templatize xTensor · c8b56a21
      Grégory LEGRAIN authored
      xVector, xTensor2* and xTensor4 are now template classes
      xTensor4Isotropic, xTensor4AnisoPlaneStrain and xTensor4AnisoPlaneStress
      remain double-valued objects as they make sense only in this context.
      By default, value type is double, so that you may only have to replace
      xVector by xVector<> and so on in your code.
      Update Tensor operations such that xTranspose, xVonMisesNorm etc...
      Theya are also double-valued by default : xTranspose<> is equivalent to
      Update the rest of the repository accordingly