1. 09 Dec, 2020 3 commits
  2. 30 Nov, 2020 1 commit
    • Alexis SALZMAN's avatar
      [xExport] add to GmshMPIIO a file splitting mechanism · bc928091
      Alexis SALZMAN authored
      A new default parameter is added to xExportGmshMPIIO constructor. This
      parameter fix the numbers of files to be generated (see comments in
      sources for precise policy).
      
      This addition give a way to split huge results in smaller part more
      easily handled with GMSH. It might give also extra performance
      for large number of process by enlarging the number of file treated
      simultaneously by the file system.
      bc928091
  3. 13 Nov, 2020 2 commits
    • Alexis SALZMAN's avatar
      [xTool] add xDeltaMemory a basic memory profiler · 0628714a
      Alexis SALZMAN authored
      xDeltaMemory class is built in the same spirit as xDeltaTime.
      A "start" method capture a state and a "end" method do a comparison with
      previous captured state. This comparison give a measure of memory
      consumption between those two events.
      To be as precise as possible the usual string used to flag measure are
      now forcedly used by initAccu method and user must use startAccu,
      endAccu with the integer returned by initAccu.
      
      It give result like xDeltaTime as table with parallel statistic and Peak
      memory usage. This last information comes from getrusage (like
      xMemoryMonitor) and correspond to maximum resident set size. All other
      information are related to user request and do not represent the
      application true current memory consumption: malloc may have already
      reserve 2GB and user vector may use only 1.5GB. This is this last
      information that is given by xDeltaMemory.
      
      Only Heap is analyzed.
      
      Behind the curtain:
      ===================
      xDeltaMemory used deprecated GNU extension called hooks. malloc,realloc
      and free hooks give a way to set your own feature related to those
      function. In our case we want to count what user did ask for allocation.
      A ideal solution would be to use the size argument to count. But when
      freeing memory we just have a pointer in hand so its not easy to decrease
      our counter. Instead xDeltaMemory use malloc_usable_size which demangle the
      malloc information related to the accessible memory associated to
      pointer given by malloc.  xDeltaMemory over estimate then the real size
      asked by the user as  malloc_usable_size return the asked size plus the
      padding eventually added by malloc. But this is already a pretty
      accurate measure. Compare to xMemoryMonitor or the use of mallinfo here
      we place the measure in client application side. The others approaches
      can be qualified as system measuring snapshot. And thus they are harder
      to use for precise measure of user allocation.
      
      The deprecated aspect seem to last from a long time ... With gcc 8 on
      liger it is still available ....
      
      The GNU extension aspect is clearly a limitation. This is not portable !
      But all GNU specific aspect has been guarded by __GNUC__ macro so on
      other compiler xDeltaMemory will return 0 for all measure.
      
      To measure third party library calls, it will be possible only if
      the library is also compiled with a GNU compiler and malloc is in use.
      Somme test on liger with mumps show that xDeltaMemory provided almost
      the same information as MUMPS itself.
      
      Note that interleaving measure is possible. A specific counter track the
      start/end to deactivate hooks outside measuring sequence to avoid any
      extra computational cost.
      
      The implementation use static variable ! It is then not currently thread safe.
      
      New atomic test case:
      =====================
      A small test show how  to use xDeltaMemory and is for now the only
      documentation.
      
      TODO
      ====
      doc+xNoDeltaMemory class
      0628714a
    • Alexis SALZMAN's avatar
  4. 12 Nov, 2020 1 commit
    • Alexis SALZMAN's avatar
      [CMAKE] Add option to xTensor and xMapping creation · 8ce1bff4
      Alexis SALZMAN authored
      xTensor and xMapping library were not managed by any options. For sure
      both may/are (I don't know) needed by almost all other libraries. But it
      is not the question of "need" but the question of "when" that those new
      option answer to.
      
      In many free project the moto to get them in use is
      "configure/cmake, make, make install"
      
      Here if we consider that all ours repositories works like that, xFiles
      and xTest and ...(Applis) may be compiled separately with steps:
      "make install"
      Introducing those options gives a way to avoid xMapping and xTensor
      compilation all the time. They are compiled and installed when dealing
      with xFiles. Then there is no need to compile then for  XTest ....
      Actual vision is to use the same GEMUtil CMakelist.txt and switch option.
      That introduce this constraint but maybe in future we will split that
      file in some peaces : option block, Xfiles, xTest, APPLI.
      8ce1bff4
  5. 10 Nov, 2020 3 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.
      5c4579b3
    • Nicolas CHEVAUGEON's avatar
      [Xfiles_dependence.dot] dependencies graph updated · d4aca3b7
      Nicolas CHEVAUGEON authored
      Xfiles_dependence.dot that contains the "handmade" dependancies graph
      between the libraries in xfiles have been updated, based on the
      CMakeLists.txt.
      d4aca3b7
    • 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.
        *Global build option BUILD_XGEOMTOOLS, BUILD_XDISTANCENEAREST,
          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
        xMesh::locateElement)
      
      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.
      bc14d18b
  6. 06 Nov, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xFEM, xMapping] xGeomElem code is simplifyed mostlty by using improved xMapping interface. · b71ddff8
      Nicolas CHEVAUGEON authored
      xGeomElem code is simplifyed (and improved ?) in the following way :
      
      - All the members now have version with the correct camelCase style. The old version are kept (for example GetDetJac is "cloned" to getDetJac), but are marked as "deprecated" in the their doxygen documentation. I tryed to use the [[deprecated]] attribute on them but unfortunatly, it's c++14 and we still can't use this version of the standard. I kept all the old version there since xGeomElem is used all over the places, but I would like to remove them in a near future ...
      
      - xBoundingBox xGeomElem::getBoundingBox() const take the place of void xGeomElem::GetBoundingBox(xtensor::xPoint& min, xtensor::xPoint& max) const.
      
      - The implementation take advantages of improved interface to xMapping.h
        for example :
        xtensor::xPoint xGeomElem ::getCDGxyz() const
        {
         double u, v, w, x, y, z;
         mapping->COG(u, v, w);
         mapping->eval(u, v, w, x, y, z);
         return xtensor::xPoint(x, y, z);
        }
        is replaced by
        xtensor::xPoint xGeomElem::getCDGxyz() const { return mapping->eval(mapping->COG()); }
        and
        void xGeomElem::setUVWForVertex(int inod) which was almost 200 lines
        is replaced by
        void xGeomElem ::setUVWForVertex(int inod) { uvw = mapping->getMappingVertex(inod); }
        where mapping->getMappingVertex(inod); just return data that where already in xMapping.
      
      - setting/clearing  the mapping or integrator members of the class was complicated because we have to keep track of differents life  time for  these pointers depending if they where defaulty allocated or pass by the user and eventulaly shared by differents
        xGeomElem. This is now simplifyed using a unique_ptr and classic ptr, allowing to use the implicitly declared destructor for
        xGEomElem.
        This pave the way for better mapping management in the  futur (I'm thinking of high order mapping that would be expensive
        to construct, that we might wan't to store in the builder ...)
      
      - we now have move constructor, move assignment and swap for xGeomElem, making them more usable in standard containers.
      
      Note on xGeomElem :
       - I think set/getOrientation are not very usefull, probably bug prone, and I think they should be removed.
       - I'm not sure we still need the integrator to be included in the xGeomElem, Integration behing performed in most cases using an
         xIntegrationRule  and xCommandOnGeomElem that could set directly the current point instead of setting it using both xGeomElem::setIntegrationPointNumberForDegree and xGeomElem::setUVW(int ipt)
      
      4 access functions have been added in class xMapping to access data that where already there, but not accessible outside xMapping.cc :
         -size_t getNbMappingVertices() const;
         -xtensor::xPoint getMappingVertex(size_t i) const;
         -static size_t getNbMappingVertices(xReferenceElementType type);
         -static xtensor::xPoint getMappingVertex(xReferenceElementType type, size_t i);
      b71ddff8
  7. 05 Nov, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [xFEM/test] added 2 atomic test for 3d search structure · a7cd5a68
      Nicolas CHEVAUGEON authored
      First, I added a test directory inside xFEM for xFEM Atomic test that was missing. (As usual Atomic test means that the test do not need other library that the current tested library dependencies)
      A new Build option is added, corresponding to the xFEM Atomic test  : BUILD_XFEM_TEST. It must be set to ON in your parent CMakeFiles.txt for this test to be builded, thanks to the Xfiles/CMakeLists.txt that will add the subdirectory xFEM/test to the build if BUILD_XFEM_TEST is set to ON
      
      In xFEM/test I added two tests cases :
      testxOctreeGrid and testxRegularGrid, along with there references.
      
      Some other tests from in Xtest/xfem-seq-test for example could also be moved here.
      a7cd5a68
  8. 04 Nov, 2020 2 commits
    • Alexis SALZMAN's avatar
      [xMapping] rm warning about potential non initialized variable usage · 6bb4eac4
      Alexis SALZMAN authored
      In both files some variable were potentially not initialized and
      nevertheless used for some computation.
      After checking with N.C. for xLagrangeMapping.cc the case were
      knots.size() is null is impossible => assert. Then a simple init with
      first point remove the warning and set without ambiguity x1,y1,z1.
      For xMapping.cc the switch was not defaulted and thus DetJac may remain
      unset. Setting it to 1 and put a default case in switch solve the prb.
      6bb4eac4
    • Nicolas CHEVAUGEON's avatar
      [XFEM, xExport, xInterface/xOctree] dependences to AOMD's octree is removed and related changes. · 22fa74d5
      Nicolas CHEVAUGEON authored
      xFEM/src/xOctreeGrid.h is a new file. It introduce a octree grid search
        structure to use in place of the AOMD::octree that was used in xMesh
        for the locateOctree members functions. It permits to construct an octree
        search structure on top of a collection of mesh entity.
      
      xFEM/src/xRegularGrid.h/cc has been modifyed so that :
       - it uses the xBoundingBox class.
       - The member function name have been changed to reflect the camel case
         convention, common to the rest of the xFEM library.
       - getElementsForPoint now return a vector of {element, localcoordinate} pair,
         so that the local coordinate of the target point in each element that
         contains it is now accessible.
       - The code have been clarifyed and simplifyed.
      
      xBoundingBox.h :
        - added 2 member function in xBoundingBox :
         /// return the center of the bounding box
         xPoint center() const { return (min + max) * 0.5; }
         /// return a vector from min to max
         xVector<double> diag() const { return xVector<double>{min, max}; }
        - Note that following a discussion with A. Salzmann, xBoundingBox could
          be moved in a near futur to namespace xgeom and the file might be part
          of a new library (xGeomTools maybe)
      
      xFEM/src/xMesh.h/cc has been modifyed so that :
        - It uses the xBoundingBox class were usefull, implying some interface
          change :
           * std::pair<xPoint, xPoint> compute_bounding_box(mEntity* e)
             is changed to :
             xBoundingBox compute_bounding_box(const mEntity& e);
           * void compute_bounding_box(xPoint& min,xPoint& max) const;
             is "deprecated", but is still there during the transition.
             it is replaced by :
             xtensor::xBoundingBox compute_bounding_box() const;
        - locateElementOctree and locateElement have changed interface,
          reflecting the changes in xRegularGrid and the use of xOctreeGrid instead of
          AOMD's octree.
        - Better control of the search structure in xMesh, since now the octree or
          the regular grid can both be cleared, updated or accessed by calling
          respectively xMesh Members   createOctree(), clearOctree(), getOctreeGrid(),
          createGrid(), clearGrid(), getRegularGrid.
        - The search structure pointers are now managed in a unique_ptr.
        - xMesh::copyMeshInternal now copy the search structures if needed instead
          of throwing.
        - AOMD_SharedInfo.h, autopack.h, OctreeCreate2.h (from AOMD) are not
          included anymore.
      
      xCrack/src/CrackPostpro.cc,  xCrack/src/ExportSensors.cc/h, modified so that it
        reflect the change in xMesh::locateElement
      
       xExport/src/xSensors.cc/h :
        -modified so that it reflect the change in xMesh::locateElement,
        -Trellis_Util::mPoint replaced by xtensor::xPoint
        -small changes to simplify the implementation
        -clang-format first the first time I think.
      
      xInterface/xOctree/src/surf2LevelSet.cc/h
        -modifyed to use xBoundingBox
        -surface2LevelSet::getBB(xPoint&, xPoint&) is replaced by
         const xBoundingBox &getBB() const { return BB; }
        -surface2LevelSet members xPoint BBmin, BBmax are replaced xBoundingBox BB;
        -a bug was found in the process :
         In surface2LevelSet::createMeshBBox that create an xMesh out of grid,
         the grid point coordinate were computed as :
          double xyz[3] = {BB.min(0) + i * elemSizeX, BB.min(1) +
                                       j * elemSizeY, BB.min(2) + k * elemSizeY};
         instead of :
           double xyz[3] = {BB.min(0) + i * elemSizeX, BB.min(1) +
                                        j * elemSizeY, BB.min(2) + k * elemSizeZ};
         The bug is corrected, but reference of test case
         xinterface-xoctree-test/surface2LevelSet had to be changed.
      
      All modifyed files have been clang-fomated.
      22fa74d5
  9. 03 Nov, 2020 3 commits
    • Nicolas CHEVAUGEON's avatar
      [xMapping] adding some virtual member to xMapping. · 661796b4
      Nicolas CHEVAUGEON authored
      xMapping now include xTensor/src/xBoundingBox.
      
      The following virtual member function of xMapping have been added.
      They all have default implementation in terms of the one existing before.
      They mostly simplify code when using them, and do not need to be implemented i
      in derived class (but could for optimization purpose)
      
       virtual xtensor::xPoint eval(const xtensor::xPoint &uvw) const;
       virtual tensor deval(const xtensor::xPoint &uvw) const;
       virtual bool invert(const xtensor::xPoint &xyz, xtensor::xPoint &uvw) const;
       virtual double jacInverse(const xtensor::xPoint &uvw, tensor &invjac) const;
       virtual double detJac(const xtensor::xPoint &uvw) const;
       virtual bool inReferenceElement(const xtensor::xPoint &uvw) const;
       virtual xtensor::xPoint COG() const;
       virtual double pushBack(const xtensor::xPoint &uvw, size_t vsize, vector3d *vec) const;
       virtual double pushBack(const xtensor::xPoint &uvw, std::vector<vector3d> &vec) const;
       virtual double pushBack(const xtensor::xPoint &uvw, size_t vsize, tensor *tens) const;
       virtual xtensor::xBoundingBox boundingBox() const;
      
      interface change in xMapping :
          virtual bool interiorCheck(const xtensor::xPoint &p, double u, double v, double w) const; changed to virtual bool interiorCheck(const xtensor::xPoint &p, xtensor::xPoint &uvw) const;
      
       Modified files :
         xMapping/src/xMapping.cc
         xMapping/src/xMapping.h
      
       and
         xFEM/src/xRegularGrid.cc
         modified to reflect xMapping::interiorCheck interface change
      661796b4
    • Nicolas CHEVAUGEON's avatar
      [xtensor] added file xboundingBox.h · 6371e2c6
      Nicolas CHEVAUGEON authored
       in file xTensor/src/xBoundingBox.h
       added class xBoundingBox in xTensor.
       it helps to manipulate bounding box thanks to the member functions,
       and will permit to remove some code duplication regarding bounding box
       intersection or checking if a point is inside a bounding box,
       compared to a model were we just pass around two xPoint.
      6371e2c6
    • Nicolas CHEVAUGEON's avatar
      [xtensor] added member function in class xPoint · e6740a5b
      Nicolas CHEVAUGEON authored
       added member function in class xtensor::xPoint :
        double & operator [] (int i);
        double operator [] (int i) const;
        xPoint operator / (double other) const;
        xPoint& operator /= (double other)
        xPoint& operator -= (const xPoint &other)
        bool operator == (const xPoint & other) const
      
       xTensor/src/xPoint.h   clang-formated
      e6740a5b
  10. 05 Oct, 2020 5 commits
    • Alexis SALZMAN's avatar
      [xFEM] a priori performance enhancement of xfieldStorageFull · d26022a1
      Alexis SALZMAN authored
      This commit remove usage of AOMD EntityHashKey and EntityEqualKey for unordered_map
      container. Using default hash and equalkey based on address (the key is a
      pointer) is a priori more efficient.
      d26022a1
    • Alexis SALZMAN's avatar
      [xMeshTool] add a new Parmetis partition function with weight · bc7d89a7
      Alexis SALZMAN authored
      This commit is adding template function setParmetisPartitionWithWeight that
      use a set of weights per element to optimize ParMetis partitioning based on
      multi criteria (the weights).  The template parameter (an int) is fixing the
      number of weights per element. The interface is kept simple. Only an extra
      xAttachedDataManagerAOMD is used to passe weights set per element.
      
      No test case for now but it have been heavily tested in some apps.
      
      This function is using almost the same algo as the one used for
      setParmetisPartition in the cc file. It is rather dirty (code
      duplication) but efficient.
      
      It add also a new dependency in terms of cmake. xInterfaceParMetis must
      now be added in cmake to use xLoadBalanceTools. But anyway from my point
      of view it should already be the case. Normally xInterfaceParMetis should
      embedded ParMetis and in cmake finding metis/parmetis lib should not be
      done.... Modern cmake would do even more by setting all this dependency
      setting for you .....
      bc7d89a7
    • Alexis SALZMAN's avatar
      [xInterface][AOMD] add func to xMeshToolAOMD and xAOMDEntityUtil+misc · 3af9ff86
      Alexis SALZMAN authored
       * Add a getPoint function to simplify xPoint creation from mVertex (no
         need of vector like getPoints which is more general).
      
       * make alive commented (in xMesh) printMesh and printEntity functions.
         They will certainly move to AOMD interface one day. But for now
         please let them stay active has I use then for debugging in my
         application. No time to do a test case on the subject.
      
       * To avoid warning on unused variable clean creation of object returned
         by many function that are not used afterward.
      3af9ff86
    • Alexis SALZMAN's avatar
      [xFEM] hopefully simplifying xMesh source · 62dcf4fb
      Alexis SALZMAN authored
      Has we are in the middle of a big change the modify state stuff were
      appearing in xMesh despite their AOMD nature. To simplify, comments are
      removed and  xinterface::aomd::modifyAllState function is use in replacement
      of the ugly set of  12 calls to modifyState method. This will certainly
      disappear in the future
      
      Remove comment regarding printMesh/printEntity. A future commit will
      bring them back alive.
      62dcf4fb
    • Alexis SALZMAN's avatar
      Xfiles] miscellaneous change related to warnings · 953b8f8d
      Alexis SALZMAN authored
      Changes are:
        * unused variable
        * wrong order for explicit member creation
        * wrong sign comparison
        * change int to size_t
        * virtual destructor addition to avoid in future a possible memory leek
      953b8f8d
  11. 28 Sep, 2020 7 commits
    • Benoît LÉ's avatar
      [xTLS] Added printMatrixMarket function to coefWarperSparse · c04103bc
      Benoît LÉ authored
      May be useful to debug.
      c04103bc
    • Benoît LÉ's avatar
      [xFEM] Corrected bug in xGradOperatorAxisym and xGradLocalOperatorAxisym · 4e1d4427
      Benoît LÉ authored
      Use geo_integ instead of geo_appro.
      4e1d4427
    • Benoît LÉ's avatar
      [xFEM] Forgot to use xtool::xDataType<S>::zero() in xAssemblerLumpedBlockEqu... · 0c0aaefa
      Benoît LÉ authored
      [xFEM] Forgot to use xtool::xDataType<S>::zero() in xAssemblerLumpedBlockEqu and xAssemblerLumpedBlockEquInVector
      0c0aaefa
    • Benoît LÉ's avatar
      [xFEM] Corrected a few bugs in xEvalGradFieldAxisym · cfe6ecb8
      Benoît LÉ authored
      - Use integ instead of appro
      - Deal with the case r = 0
      cfe6ecb8
    • Benoît LÉ's avatar
      [xFEM] Added xAssemblerLumpedBlockEqu and xAssemblerLumpedBlockEquInVector. · d5c4a868
      Benoît LÉ authored
      These assemblers can be used to assemble lumped matrix. They will both do the same thing, aside from
      the fact that xAssemblerLumpedBlockEquInVector will assemble in a vector containing the diagonal coeffcients
      of the lumped matrix (so it will be used with a bilinear form to assemble in a vector).
      
      These assemblers take each block of the assembled matrix, compute the average and assemble it on the corresponding diagonal coefficients.
      
      For instance, the lumped version of the following matrix
      
          [a b 0 0]
          [c d 0 0]
          [0 0 e f]
          [0 0 g h]
      
      would be
      
          [m1 0  0  0]
          [0  m1 0  0]
          [0  0  m2 0]
          [0  0  0 m2]
      
      where m1 = (a+b+c+d)/4 and  m2 = (e+f+g+h)/4
      
      They are not supposed to be used with vectors, so (for now) the assemble_vector gives a throw.
      d5c4a868
    • 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.
      b1fc814e
    • 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.
      4ba05f8e
  12. 18 Sep, 2020 1 commit
    • Nicolas CHEVAUGEON's avatar
      [DataManager] added functionalities to the DataManager famillies. · 0685530e
      Nicolas CHEVAUGEON authored
      class concerned :
      xAttachedDataManagerAOMDGeneric
      xGeneralUnorderedMapDataManager
      xUnorderedMapDataManager
      
      - added public type alias :
        using value_type = DATATYPE;
        using key_type = KEYTYPE;
        Rational : usefull for generic programming with datamanagers.
      
      - added member function contains :
      bool contains(const KEYTYPE &key) const;
      return true if the key is in the datamanager.
      rational : when need to know if a key exist in the data manager, calling contains is easier and faster than call getData(key) and check if null.
      The name contains is  standard in stl associative container starting at c++20. It complement the old count.
      
      - added member function rangeKey :
      xtool::xRange<c_iterKey_t> rangeKey() const;
      return the range of key in the container.
      rational : avoid calling beginKey() and endKey() in some contexts. Make Datamanagers in sync with other containers of Xfiles.
      0685530e
  13. 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
      xAttachedDataManagerAOMDGeneric.
      Note also that update with change of definition is now dealing
      correctly with support (see dom5 in disk example which is now cleanly
      updated)
      5f4ffd7b
  14. 16 Sep, 2020 2 commits
    • Alexis SALZMAN's avatar
      [xFEM] add security to avoid potential memory leek in xData · 5d11f62f
      Alexis SALZMAN authored
      One recent commit change 'mesh' data member access of class xData. It is now
      a private member. Two get/set methods were added to access to this pointer.
      But if we read with xData a mesh from a file and choose afterword to  use setMesh
      method to reassign the 'mesh' pointer to a new mesh instance user had to
      pay attention to the way he treat memory allocated done during first read from file.
      If he did want to avoid potential memory leak he had to call the getMesh
      method and with the return pointer free memory, all this before calling setMesh ...
      
      This commit choose to add a state to xData to say if the 'mesh' data
      member point to a memory maintained by xData or not. A new delMesh
      method is then in charge of freeing memory pointed by 'mesh' pointer only if
      this memory was allocated by xData. This function is called in setMesh
      to avoid memory leek. It is also called in destructor to avoid to free memory
      allocated by user (double free error). And it is made public to offer a
      simple way to free memory allocated by xData if any.
      
      Hop this make things more clear to user. For sure it is not ideal for
      thread safety ...
      5d11f62f
    • Gilles MARCKMANN's avatar
      Remove last reference to Trellis_Util::LagrangeMapping in xFEM and change it... · bd464931
      Gilles MARCKMANN authored
      Remove last reference to Trellis_Util::LagrangeMapping in xFEM and change it in xmapping::xLagrangeMapping.
      bd464931
  15. 15 Sep, 2020 1 commit
  16. 09 Sep, 2020 1 commit
  17. 07 Sep, 2020 1 commit
  18. 03 Sep, 2020 3 commits
    • Alexis SALZMAN's avatar
      [xLinAlg] release constrains in xDistIndex regarding index creation/link · ef5b2684
      Alexis SALZMAN authored
      xDistIndex:
      ===========
      A test in finalize was checking sizes of packed_id and to_from
      containers. Sizes are normally equal. Since now, and in dedicated
      test case it was true as insertToFrom method last call was always done
      after the last call to insertIndex method. The test that check size was
      then logical as insertToFrom resize to_from with the size of packed_id.
      If sizes were different this was a problem.
      
      Now this implicit calling order in between  insertToFrom and insertIndex
      is to constraining and complex to understand for user. This commit with
      a quick dirty fix release this test. Now a message (in debug mode)
      appears and to_from is resized to packed_id size if not of same sizes.
      This let user interleave insertToFrom and insertIndex the way he wants
      (but still with the restriction that insertToFrom only deals with index
       already present in instance).
       A comment in the header was added about that => cf
      
      For now this size coherence checking is no more done but in future we
      may thing about doing things differently so that some checking is added
      in finalize method.
      ef5b2684
    • Alexis SALZMAN's avatar
      [xMapping] Change CMakeList file to cope with ARCHOS change · ce31be61
      Alexis SALZMAN authored
      In xMapping attempt by N.C. to use modern cmake mechanism that
      associate dependency to target work successfully in the reference
      context (tnode 10).
      In my context lack of dependency make compilation stop. From a brief
      analysis I do related this problem to the fact that in my context I use
      ARCHOS variable. When touching to ARCHOS variable target dependency
      recognition seems to be in default. Hypothesis to confirm.
      
      For now I switch back to old way of treating dependency.
      ce31be61
    • Alexis SALZMAN's avatar
      [xTool] make xNoDeltaTime works + test case · 487ba92c
      Alexis SALZMAN authored
      xNoDeltaTime class was bugged. Now this class is ok and rigorously having the
      same API as xDeltaTime class.
      
      With this class that cost nothing (all call to instance method
      are optimized out by compiler) we can now consider to let monitoring
      instruction to stay in the middle of the code. No more dirty macros are
      needed around those instructions. Only at creation time the instance
      created is either a xNoDeltaTime or a xDeltaTime object (and macro if
      necessary appears only at this level)
      
      A small atomic test case check that xNoDeltaTime do not cost anything.
      
      Be careful to not encapsulated  a xNoDeltaTime or a xDeltaTime object
      into a std::function. You would alleviate all the effort to make
      xNoDeltaTime to cost nothing. Because std::function itself do cost and
      keeping monitoring instructions in the code would then degrade
      performances.
      487ba92c
  19. 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.
      af6f2b76