1. 10 Nov, 2020 1 commit
    • 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. 28 Sep, 2020 3 commits
    • Benoît LÉ's avatar
      [xTLS] Added printMatrixMarket function to coefWarperSparse · c04103bc
      Benoît LÉ authored
      May be useful to debug.
    • Benoît LÉ's avatar
      [xTLS] Added frontExist function to TLSGeomInterface · b1fc814e
      Benoît LÉ authored
      This function tells if front (iso-zero mesh) exists or not. The implementation
      is exactly the same as the crackExist function, using iso-zero mesh instead of
      iso-lc mesh.
    • Benoît LÉ's avatar
      Bug correction following removing of xMesh::del + bug correction · 4ba05f8e
      Benoît LÉ authored
      In TLSGeomInterfaceSignedVectorDistanceFunction, the link-on-front-based modes
      merging uses an xAttachedDataManagerAOMD (called mode_cut_edge in the code) to store, for each iso-zero node of the
      Fast Marching mesh, the parent edge (or node) of the computing mesh. This xAttachedDataManagerAOMD
      is created at the begining of the FM mesh creation, when the iso-zero nodes are
      copied into the FM mesh. Then the FM mesh is created, and after that the modes
      are merged.
      The problem is that during the FM mesh creation, some nodes are merged, which
      may in some cases delete some mEntity*, which are keys in mode_cut_edge. Before
      the commit on xMesh::del, it was not a problem, probably because in the previous
      version, the pointer to mEntity was not deleted after calling xMesh::del.
      However after this commit the computation abort in mode_cut_edge destructor (probably because we try to call
      a delete on an mEntity which does not exists anymore).
      This has been fixed by properly deleting data from mode_cut_edge before deleting
      the associated key.
      Also, minor fix when dealing with warped nodes.
  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 1 commit
  7. 21 Jul, 2020 1 commit
    • 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. 14 Jul, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xfem] xExtendShapeFcts : some aomd tagging removed · 13337f62
      Nicolas CHEVAUGEON authored
          xExtendShapeGeneratorBase now use a DATAMAMANAGER to store the
          xExtendShapeFcts instead of AOMD tag mechanism.
          since there is no tag to associated to xExtendShapeFcts, getTag() member is removed and replaced by : getExtendedShapeFcts
          xExtendShapeGeneratorBase is not template any more on typename ITERFRONT since
          this type was only used by the constructor. Only the constructor is
          template ont ITERFRONT.
          consequence of the above implyied slight changes in xSpaceExtendedShape.cc/h
          and TLSVelocity.h/_imp.h xApproxFunctionExtendedShape.h
          xFEM/src/xAttachableExtendShapeFcts.h is not used any more and moved to attic.
  9. 13 Jul, 2020 1 commit
  10. 02 Jul, 2020 1 commit
  11. 01 Jul, 2020 1 commit
  12. 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.
  13. 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
  14. 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.
  15. 16 Jun, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xmapping] xMapping now a full class, independant of Trellis_Util::Mapping. · 0c02f81b
      Nicolas CHEVAUGEON authored
          This is a continuation of the work of previous commit. The goal behing
          to reduce the dependancies to AOMD. This intermediate commit do that
          with minimal interface change and minimal other change to Xfiles
          new files  in xMapping/src :
          xLagrangeMapping.cc, xLagrangeMapping.h, xLagrangeMappingBuilder.cc,
          xLagrangeMappingBuilder.h, xMapping.cc, xMappingBuilderHolder.cc, xMappingBuilderHolder.h
          class xMapping, xLagrangeMapping, xConstantLagrangeMapping ...
          are now fully implemented in xmapping instead of behing typedef of some Trellis_Util::Mapping.
          This come with some minor interface change to minimize remaining deps to Trellis in xmapping :
          xMapping do not store any more the associated AOMD::mEntity, instead it just store the entityType (mType defined in AOMD_Internals.h) This type will probably
          change in a next commit, it's still needed for now in the present form, so that the the type returned by member getType() remain compatible with Trellis_Util::Integrator.
          interface change in xMapping :
          - member getEntity is removed.
          - member getType is added.
          - member interiorCheck was taking a useless AOMD::mEntity *loc as input, it is removed.
          - members PushBack are replaced by pushBack to conform to general xfile convention.
          - unused member simplexation is removed
          - There are now 3 normalVector members and they are not pure virtual any more :
            virtual void normalVector(double u, double v, double w, vector3d &n) const :
            compute the "natural" normal to a face mapping. it also work with line, making the assumption that the normal is orthogonal
            to the third axis. direction of the normal of course depends on the order of the nodes in the face up to a sign.
            virtual vector3d normalVector(const unsigned short *face_vertices, double s, double t) const:
            compute the normal to the face (resp line) given by face_vertices in term of the nodes number of the
            reference solid (resp face) upon with the mapping is constructed. s,t are the local parameter in the reference space of face
            (resp s in the reference space of the line). It proceed by finding out if the face is really a valid face of the solid,
            if so which one and how it is rotated compared to the corresponding reference face on the solid.
            Then it compute the coordinate u,v,w in the solid reference face corresponding to point s,t on the face,
            taking into account face number and rotations. It then select the normal in reference space according to the face number,
            and push it back to geometric space.
            For this to work,  data are defined in xMapping.cc for each type of mapping supported.
            vector3d normalVector(const unsigned short iface, double u, double v, double w) const:
            compute the exterior normal to the  numbered iface face relative to the underlying solid at point u,v,w  of the solid.
            iface is the relative face number to the solid we want to take the normal of.
            From this value, the normal in ref space is retrived.  it is then push to geometric space using the jacobian at u,v,w.
            This is the simplest candidate to use to replace previous usage of normalVector in the library.
          Consequences elsewhere :
          -  xMapping/src/xLagrangeMappingBuilder.cc/.h
             xRegularCubeLagrangeMappingBuilder and  xCylindricalCoordinatesLagrangeMappingBuilder are moved to this file
            (previously they were in xMappingBuilderHolder.h/cc).
            xLagrangeMappingBuilder Familly now call new version of constructors for xLagrangeMapping.
          - Trellis/Util/Util/calculus/Integrator.h/cc
            GaussIntegrator do not store any more the entity, just the entityType. Constructor modifyed accordingly
          - xCrack/src/IntegratorSingularCrack2D.cc
            call to Trellis_Util::GaussIntegrator constructor modifyed accordingly
          - xCrack/src/SingularCrackMapping.h_cc xExt/src/InfiniteMapping.h_cc
            constructor of SingularCrackMapping and InfiniteMapping now call new version of xMapping and xLagrangeMapping Constructor and
            do not overload normalVector any more.
          - xExt/src/InfiniteOrLagrangeMappingBuilder.cc now call new version of xLagrangeMAppingConstructor.
          - xForm.h/.cc :
            bool integ_is_appro(xGeomElem* geo_integ, xGeomElem* geo_appro) is now implemented in the .cc file (otherwise xMapping need to be fully defined in xForm.h )
          - xGeomElem.h/.cc
           now xGeomElem store a AOMD::mEntity* ent as a direct member, since xMapping do not any more. Constructors and members are modifyed accordingly.
           xGeomElem member normalVector is implemented according to the new implementation of xMapping.
          - xRegularGrid.cc : implemented using the new version of interiorCheck.
          - xMapping/test/testxLagrangeMapping/main.cc has been modifyed to test the normal implementation and conform to the change in xMapping interface.
          - TLSVelocity.h :  Small changes to conform to the new xMapping interface.
          - Element.h now include "AOMD_Internals.h" because it needs AOMD::mEntity::mType
             which is not included throught xMapping.h any more.
  16. 15 Jun, 2020 1 commit
  17. 04 Jun, 2020 1 commit
  18. 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.
  19. 08 May, 2020 1 commit
    • Benoit Le's avatar
      [xTLS] Added modes merging based on link on front. · d42135e7
      Benoit Le authored
      Added modes merging based on link on front, resulting from the definition of a stable Lagrange multiplier space on finite elements cut by a surface. It uses the xLinkOnFrontLinkGenerator class introduced in a previous commit.
      As it will probably more properly implemented in a future TLSGeomInterface class, it was decided to put it inside a "NEW_MERGNING" macro, defined at the begining of the TLSGeomInterfaceSignedVectorDistanceFunction.cc. To use it, just replace "#define NEWMERGING 1" by "#define NEWMERGING 3".
      TLSGeomInterfaceSignedVectorDistanceFunction.cc has been clang formated.
      The idea of using this mergning resulted from a discussion with N. Moes and N. Chevaugeon, and the introduction in eXlibris with A. Salzman.
  20. 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
  21. 08 Apr, 2020 1 commit
    • 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
  22. 16 Mar, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xGraph] turn exportDot into a parallel MPIIO export function + API change · e44f8de7
      Alexis SALZMAN authored
      exportDot is now working with MPIIO io library. If called with
      MPI-com_self or a mono process communicator it output a full undirected
      graph without parallel information. If called with many process each
      containing part of undirected graph it encapsulate each part in a
      subgraph named with the process id. If node ID is unique across process
      common nodes are unique among the representation obtain with dot but
      connection do exist in between subgraph(process).
      Function API is now reacher. User must at least give something to
      associate KEYTYPE object to a unique id. It represents the node
      id in the graph associated to the key. Optionally user may set a
      specific label to each node and a weight label to each edges.
      Some new methods have been added to nodeTo class (one avoid exportDot
      to becomes a friend function of the class).
  23. 11 Mar, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xFEM xInterface/xOctree xTLS] cleaning some more free tags · e2e0d821
      Nicolas CHEVAUGEON authored
          In the process of cleaning the use of some aomd attachable data using
          tags. All the tags related to octree->aomd (and/or hanging entities) in
          the static part of xMesh  are removed and replaced by corresponding
          container (xAttachedDataManagerAOMD ).
          Now all the functions that use them say so clearly in there interface,
          and tell clearly if it modify the attached data or Not.
          For now, correponding to each previous static tag (related to
          octree-AOMD) in xMesh, there is a
          corresponding xAttachedDataManagerAOMD :
          octree_level_tag     -> octreeLevel
          is_hanging_on_tag    -> isHangingOn
          is_hanging_by_tag    -> isHangingBy
          bnd_group_tag        -> bndGroup
          down_group_tag       -> downGroup
          So that function that use them can use default argument defined by
          calling the corresponding static function in xMesh.
          Note that this as a cost :  upon deletion of xMesh, we need to clean the
          data related to each of these container and the xMesh behing destroyed.
          I keep it like this for now, but These static containers should be ready
          to be removed, and they will be in the future ... To me they should be
          hold  be a class that handle the mesh with hanging nodes. (For example
          we could have a class that does the interface from ooctree to AOMD that
          would have the container has member function, instead of doing the
          interface by calling a free function )
  24. 09 Mar, 2020 3 commits
    • Benoît LÉ's avatar
      [xTLS] Modification of previous bug correction in evaluation of adimensioned level set · 7d348908
      Benoît LÉ authored
      When tagging the iso-lc nodes, a test on affiliation to the computation mesh was introduced, instead of a test on the presence/absence of creator.
      After discussion with A. Salzman, this may be costly, depending on the mesh data based used to perform this "find" operation (note that with AOMD it does not seem too costly, but this may not be the case with other data bases).
      Thefore, the nodes of the computation mesh cut by the iso-lc are tagged before trying to attach iso-lc tags to the nodes of the integration elements. This allows to have and algorithm which is "mesh interface free", although it requires a first tag loop.
      Also, another way to do it would be to tag the iso-lc nodes instead of the nodes of the computation mesh cut by the iso-lc (which would be a little more cost effective) : however, this approach does not work in 3D because of the warped nodes. Indeed, these warped nodes exists in both the iso-lc and the partition elements.
      Until a new version of TLSGeomInterface solves this issue, we keep this implementation.
    • Nicolas CHEVAUGEON's avatar
    • Nicolas CHEVAUGEON's avatar
      [xFEM XTLS] in the process of cleaning up the tag. · fe0b97c4
      Nicolas CHEVAUGEON authored
           In xMesh, there use to be a series of 3 statics tags : RH_enrichment_nb_func_tag, RH_enrichment_side_tag, RH_enrichment_status_tag
           related to the RampHeavisdeEnrichment and were used in particular for
          function related with TLSEnrichment_4
           Theses tags are now removed from xMesh.
           They are replaced by 3 xAttachedDataManagerAOMD <T>, which are member
           of the TLSEnrichment_4 class.
           This commit is not tested, since we have today nothing that use TLSEnrichment_4 . After discussing with both A. Salzmann and B. Le, all code related to TLSEnrichment_4 we be moved to attic any way in a next commit.
  25. 06 Mar, 2020 1 commit
    • Benoît LÉ's avatar
      [xTLS,xFEM] Corrected evaluation of adimensioned level set in 3D when using FM modes · 8ba5634c
      Benoît LÉ authored
      In the constructor of xEvalTLSAdimLSFromFrontsAndLS, the nodes around the iso-zero and iso-lc of ls are tagged to properply get a value of 0 on
      the iso-zero and 1 on the iso-lc.
      For a given edge/face of the iso-lc :
      - The upper creator is retrieved
      - Loop on the elements of the partition of the upper creator
      - Loop on the nodes of the partition elements
      Then each node is tested :
      1) If it has a creator, it means that it is a node of the computation mesh, so the regular evalutor of ls can be used
      2) Otherwise, it is on the iso-lc, it is tagged so that its value is 1
      The problem in 3D comes from the case where the cut of a tetrahedron is a "rectangle" (not necessarily flat). In this case, the barycenter of this
      rectangle is also a node of the iso-lc, but does not have a creator, so is is not considered as an iso-lc node (case 1) giving wrong values of the iso-lc.
      This test has been replaced by a direct checking of the existence or absence of the node in the computation mesh.
      For that an xAcceptInMesh test has been added in xEntityFilter.
  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. 04 Mar, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xTLS] change TLSFastMarchingTools to use flux graph · 5a35a73d
      Alexis SALZMAN authored
      Under control of HAVE_XGRAPH a new version of TLSFastMarchingValGradMode
      is proposed that use fmeik with flux. Graph is used with breath for
      search function of nodeAndConnectedEdge.h to transport modes.and only
      one fmeik call is done. Note that proposed algo is versatile in the sens
      that if mode is connecting many source flux the same kind of step should
      be applied (3 BFS : one to set matrix structure and 2 related to count
      number of visit per node and to compute then matrix term under
      This commit abandon entityStorage usage in this function.
      Change in xTest are required now to take into account this modification
      (mainly dependence to xGraph in cmake).
  28. 27 Feb, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xFM,xTLS] change entitystorage API + ls removal in internal fmeik · 0701ea0f
      Alexis SALZMAN authored
      Work with N.C.
      This commit change entitystorage API so that it stick to eXlibris
      DATAMANAGER concept (use of setData getData).
      This class is now with an API partially common to DATAMANAGER except
      that it does not have a default constructor. This imply that if we want to
      use exlibriss DATAMANAGER concept with FM family, as distributed updater
      use a data manager to hold internal information for communication, we need to
      have the same constructor. The adopted solution is to consider that
      entitystorage is no longer available for FMDist family. Only FM family
      works with it. And all DATAMANAGER concept container will work with
      both family.
      In this commit ls is no longer transmitted to internal fmeik. Those
      functions are using now updater instance to access to it via getLs/setLs
      methods. To minimize changes these methods retake partially old
      entitystorage API. This modification hopefully clarify situation.
      The updater is in charge of ls,gls and transported information.
      updatefxx methods are now no longer const method as they change ls,
      The communication part of Transport concept is now in FMUpdater.h.
      This is doing a neat separation:
      including FM.h
      no dependency to any other library
      include FMDist.h
      added dependency to xtool library
      Assertion above depend also on what you include/tune to complete usage of
      fmeik function (mesh interface, vector, time monitoring, .....)
  29. 24 Feb, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xFastMarching] File dispatching and API change · 362685b2
      Alexis SALZMAN authored
      The parallel and sequential version have been merged in one single
      folder. The old xDistFM folder is not present anymore and the trick
      in FindxFastMarching.cmake had disappear.
      To hold both version and avoid code duplication sources have been
      dispatched in several files. The use of a new namespace call internal
      give a way to clarify what user should include and what he should not
      include (TODO to protect from inclusion by macro).
      FM.h  and FMDist.h correspond to the API available for users (i.e. fmeik
      and fmeikDist functions declaration). Note that fmeik and fmeikDist run
      over one process do not behave the same way (the // version work by
      stride even with one process). This is why both exist for now. Maybe in
      future this may be merged.
      FMinternal.h and FMDistInternal.h store the internal counterpart of
      fmeik and fmeikDist where fast marching is proceed.
      FMUpdater.h and FMUpdaterDist.h store internal helping class that help
      updating vertex values.
      FMUtil.h store internal computation tool available for all versions (//
      or seq). It gives also a definition of transport concept.
      FMDataExchanger.h is dedicated to // version. It give exchanging tool
      for in between processes communication.
      In this commit the fmeik and fmeikDist API has been modified to make
      those functions entitystorage independent. Now a template parameter call
      DATAMANAGER is given by user to store information at node. It force now
      user to call fmeik/Dist with appropriate type  for first template
      parameter (no argument deduction available anymore). This done, in future
      commit, it will be possible to use something else then entitystorage to
      work with FM. entitystorage class is now in the FMEntityStorage.h
      file and user has to include this file to use like before the FM algo.
      Due to API change and namspace addition the old FM.h has been copied
      in Skeleton with a new name (FM_seq.h). It is now this file which is
      included by FMSK_fastmarching.h. Originally this Skeleton folder was
      independent. Unfortunately it looks to be dependent of src folder
      content now. I am not sure that copying  FM.h  will be sufficient. I
      let this integration (or return to original separate context) works
      to others ...
      TLSFastMarchingTools file are using new API with entitystorage as
      template parameter type (via a using)
      Checked by N.C.
  30. 19 Feb, 2020 1 commit
  31. 18 Feb, 2020 1 commit
    • Benoît LÉ's avatar
      Bug correction when merging modes in TLSGeomInterfaceSignedVectorDistanceFunction · ba887788
      Benoît LÉ authored
      In some cases, when using the old merging method (by commenting the line #define NEWMERGING - new merging is much more time consumming when the size of the damaged zone increases), an infinite loop could appear. It was due to some
      bunches of modes which should be merged according to the merging criterion. These bunches do not contain any mode to merge to (ie a mode which does not satisfy the merging criterion). This may happen when two tangent cracks start to coalesce for instance
      The solution is to:
      - Add a criterion to exit for the merging loop (ie when the variable merge_row stops to increase)
      - Then, apply the same merging loop, but removing the merging criterion
      The merging loop has been factorized inside a lambda function.
      Bug correction done by working with A. Salzman.
      Also, moved a variable declaration inside the appropriate "#ifdef NEWMERGING" scope.
  32. 10 Feb, 2020 1 commit
    • Alexis SALZMAN's avatar
      [XFiles] Introduce xvalues_t typdef and reset several names · 63a68f9f
      Alexis SALZMAN authored
      This typedef represents a xValue<VT> type with VT the template parameter
      corresponding to the type of value stored in xValue.
      It is introduced to hopefully avoid misunderstanding with previously
      introduces value_t corresponding in most case to the type of value
      computed (for now we play mostly with arithmetic with those).
      Especially in xValueLinearCombinationXXX hierarchy we are dealing
      with xvalues_t, not value_t.
      It has been also introduced in xValueManagerDist to clearly separate the
      type of the values, value_t, from the type of the xValue<value_t> that
      store in the xValManager instance these information.
      This as been used as suggested by N.C. to set the type of the value_container_t
      and be more strict regarding the implementation
      In xField value_manager_t replace ValueManager to try to clarify
      getValueManager and getDoubleManager are now rigorously the same. So this
      commit removes this last method that do have a name far to specific.
      This implies lost of changes everywhere ... but re-naming of instance have
      not been done accordingly to this new method name (to much work). Names
      such as double_manager or dm should be changed ... little by little
      Test will be updated soon.
  33. 04 Feb, 2020 1 commit
  34. 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.
  35. 20 Dec, 2019 1 commit
    • Nicolas CHEVAUGEON's avatar
      removing dependencies of xfem on xcut. · f000b185
      Nicolas CHEVAUGEON authored
          Some constructor of enriched shape function that rely directly on an xPhysSurfxxxx are removed from xfem. They were only using the reference of the xLevelSet embeded inside xPhysSurf. directly call the constructors that take a level_set from no on.
          xValueCreatorRampedHeavyside from xValue.h/cc have been moved to xtls,
          since that's the only place were they are used. And that seems to be the
          last dep of xfem on xcut.
      Squashed commit of the following:
      commit 9fbec7ad8c294660691818027195f6e5dabac599
      Merge: f92e0ca 1714a22b
      Author: Nicolas CHEVAUGEON <nchevaug@titan.ec-nantes.fr>
      Date:   Fri Dec 20 17:32:58 2019 +0100
          Merge branch 'master' into removexfemtoxcutdependencies
      commit f92e0caceb0e245a27aaf2a26fe048a805600557
      Author: chevaugeon <nicolas.chevaugeon@ec-nantes.fr>
      Date:   Fri Dec 20 17:06:13 2019 +0100
          finishing clean up after removing dep on xLegacySingleCut in xFEM
      commit a727fa5d45ac07cf81f7d2f4c220995a6dbd55c7
      Author: chevaugeon <nicolas.chevaugeon@ec-nantes.fr>
      Date:   Fri Dec 20 15:34:41 2019 +0100
  36. 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)