1. 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()); }
        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
        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);
  2. 04 Nov, 2020 1 commit
    • 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.
  3. 03 Nov, 2020 1 commit
    • 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 :
         modified to reflect xMapping::interiorCheck interface change
  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. 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
  6. 17 Jun, 2020 2 commits
    • Nicolas CHEVAUGEON's avatar
      [xmapping] xmapping now use xtensor::xPoint instead of Trellis_Util::mPoint · a4f93f74
      Nicolas CHEVAUGEON authored
           Reducing again the deps of mapping to Trellis, Trellis_Util::mPoint is replaced by  xtensor::xPoint in xmapping.
           xMapping/src/xMapping.h do not include mPoint.h anymore.
          consequences outside xmapping :
          - xCrack/src/SingularCrackMapping.cc : SingularCrackMapping : member bounding box now take xtensor::xpoint as outpout parameter.
          - xFEM/src/xGeomElem.cc : now include "xPoint.h". xGeomElem Member GetBoundingBox corrected to call xmapping's bounding box using xtensor::xPoint.
          - xInterface/AOMD/general/src/xAOMDEntityUtil.h now include xPoint.h.
             function getPoint signature changed to std::vector<xtensor::xPoint> getPoints(const AOMD::mEntity &e).
    • 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.
  7. 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.