- 13 Jan, 2021 2 commits
-
-
Gilles MARCKMANN authored
- xAttachableString.cc -> xDoubleCut - xAttachableChar -> xInterface/AOMD (still used in TLSImplicit) - xAttachableGP -> xInterface/AOMD (still used in TLSElementBased) - xAttachableEntitiesVector -> xTLS (still used in TLSExplicit) - xAttachableEntitiesSet -> attic
-
Alexis SALZMAN authored
This commit pass from () to [] operator for LOCALVECTOR concept of xAssembler concept. This is opening usage of assemble_vector method to a wider range of container types. LOCALVECTOR may now be a xCSRVector or a std::vector for example. xFemVector having both operator remains functional (maybe () operator should be removed now ?). Some comments are added to try to clarify LOCALVECTOR and LOCALMATRIX concept.
-
- 12 Jan, 2021 1 commit
-
-
Gilles MARCKMANN authored
- Mark xFEM/xAttachableXXX class as deprecated (they shall be moved or removed). xGeom: - change use of xAttachableChar : replace const unsigned int tag_nodes by a const xAttachedDataManagerAOMD<char>& in constructor of xLevelSetToCGALAndTag. xTLS: - change use of xAttachableChar : replace const unsigned int tag_nodes by a xAttachedDataManagerAOMD<char> in: - TLSGeomInterfaceSignedVectorLevelSet, - reInitLevelSetFromFrontCGAL2, - xEvalTLSAdimLSFromLevelSetAndLCFront - xRefCutToIsoCGAL
-
- 18 Dec, 2020 1 commit
-
-
Alexis SALZMAN authored
This is removing the statics and encapsulate things GP data manager is now encapsulated into a class xIntegrationRuleStoredDataManager from which all xIntegrationRuleStoredxxx class derive. This way xIntegrationRule is not anymore impacted and when xIntegrationRuleStoredxxx is deleted every thing is automatically cleaned. xIntegrationRuleStoredxxx is responsible of the management of attached gauss points to entity. xIntegrationRuleStoredDataManager encapsulate the DATAMANAGER thus in future switching to others things will be easy. It retake almost the same API as DATAMANAGER with other names. Now that static are removed xExtendShapeFcts had to be modified to store a reference of xIntegrationRuleStoredxxx so that adding GP to entity is possible through functor call like before but with a new parameter passing xIntegrationRuleStoredxxx viewd as a xIntegrationRuleStoredDataManager. The xIntegrationRuleStoredxxx instance and the xExtendShapeFcts generator are now more tied together. This induce that the xSpaceExtendedShape based on generator is tied to xIntegrationRuleStoredxxx and assemble is now a little more secure as the field (base on xSpaceExtendedShape) is now in coherence with xIntegrationRuleStoredxxx explicitly. Hope I did not break something somewhere. I mean test pass but there is not much of them on those things ....
-
- 17 Dec, 2020 1 commit
-
-
Gilles MARCKMANN authored
Remove use of xAttachableGP in Xfiles. Now a datamanager is added to class to attach Gauss Points data. The type xGaussPoints is defined as std::vector<std::pair<xtensor::xPoint, double>> and the datamanager type is datamanager_gauss_points_t (defined in xIntegrationRule.h). A static function of xIntegrationRule allows to get the datamanger. Example 1: agp = new xfem::xGaussPoints; xfem::xIntegrationRule::get_gauss_points_datamanager().setData(*e) = *agp; Example 2: xfem::datamanager_gauss_points_t& _data_GP_= xfem::xIntegrationRule::get_gauss_points_datamanager(); xfem::xGaussPoints* agp = _data_GP_.getData(*e);
-
- 15 Dec, 2020 1 commit
-
-
Alexis SALZMAN authored
-
- 11 Dec, 2020 2 commits
-
-
Alexis SALZMAN authored
This method pass in revue all the non null terms (topological sens) and run a functor on them. The functor is expected to have 3 arguments: - 2 integer i and j that contains row and column index of term. - one T val corresponding to term's value. The functor can do anything you want. This function offers to user a quick way to deal with all traits. It may be slightly less efficient then calling getMemoryAcces and by hand pass in in revue terms according to traits (to be checked). It depends on what you do. It will be used internally to replace many duplicated piece of code where looping on all terms is required. It is already in use with printMatrixMarket method. Has some test do check matrix market outputs we can already conclude that forEach is validate.
-
Alexis SALZMAN authored
-
- 10 Dec, 2020 1 commit
-
-
Alexis SALZMAN authored
A DeclareInterpolation2 and DeclareState2 is added to xAlgorithm.h in this commit. The idea is not to use them right away but instead to test them in your context by switching names (remove the 2 and add something to old version names). By context here I talk of compiler. For those who use something else then GNU g++, those new versions have to be validated because they use the following assertion not in the norm I think: The clear method of std::vector do not touch memory allocation. Thus the glob and loc vectors use memory management a small number of time (for the first set of key of each space for a priori one element per space at most). Otherwise the insert is relying on already allocated capacity. If this assertion is not verified with other compiler something will have to be added. Besides this memory trick the main modification comes from valgrind study. It shows that xFiniteElement destructor and setKeys count respectively for 6.44% and 35.49% of 595 call to Declarinterpolation with a total of 304 640 elements treated (512 per call). KeysFor interfere in setKeys for 19.08%. As stated already by N.C., clearly those computation are too costly compared to the generality or maintainability that they provides. The adopted solution was to remove xFiniteElement usage in those functions. That may hurt ... Maybe the loop on space, glob and loc ingredient may be encapsulate in something .. or xFiniteElement may be cleaned. For now those new versions are proof concept. Their performance shows up more then 20% gain in some application with many declareXXX. Note that new version pass test successfully.
-
- 09 Dec, 2020 3 commits
-
-
Alexis SALZMAN authored
-
Alexis SALZMAN authored
We had already a begin, end method. Using then with std:distance was a way to know how many values are created in the xValManager instance. But has iterator are not ramdom ones, it cost a lot to have this information that is available privatelly. This comite makes it public by adding this size method.
-
Alexis SALZMAN authored
Some std::swap have been replaced by call to swap class method to avoid infinit recursion. Validate by N.C.
-
- 30 Nov, 2020 1 commit
-
-
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.
-
- 13 Nov, 2020 2 commits
-
-
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
-
Alexis SALZMAN authored
-
- 12 Nov, 2020 1 commit
-
-
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.
-
- 10 Nov, 2020 3 commits
-
-
Nicolas CHEVAUGEON authored
class xBoundary was only used as a parameter to some Mechanics::TreatmentOfNatEnv that was never actually used and which was passed around via a member of xData. It is nothing more than an early implementation of xSubMesh that was passed around via cut and past for a long time ... Therefore, xBoundary is now made obsolete and the files xBoundary.h/cc are moved to xFEM/src/attic. all its' use will be removed from xTest. Note : My first clang-format related bug. The file xDistanceNearestPointGenerator.h need to be included before xDistanceNearestPoint.h, otherwise some test case can't compile !!! indeed, it add some overload to cgal AABBPrimitive that needs to be visible for template instanciation that can take place via xDistanceNearestPoint.h. But clang-format messed around and I had to force the inclusion of xDistanceNearestPointGenerator.h before xDistanceNearestPoint.h, by including it at the beginning of xDistanceNearestPoint.h, and preventing clang-format to reorder the include by inserting some comment.
-
Nicolas CHEVAUGEON authored
Xfiles_dependence.dot that contains the "handmade" dependancies graph between the libraries in xfiles have been updated, based on the CMakeLists.txt.
-
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.
-
- 06 Nov, 2020 1 commit
-
-
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);
-
- 05 Nov, 2020 1 commit
-
-
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.
-
- 04 Nov, 2020 2 commits
-
-
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.
-
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.
-
- 03 Nov, 2020 3 commits
-
-
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
-
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.
-
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
-
- 05 Oct, 2020 5 commits
-
-
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.
-
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 .....
-
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.
-
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.
-
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
-
- 28 Sep, 2020 7 commits
-
-
Benoît LÉ authored
May be useful to debug.
-
Benoît LÉ authored
Use geo_integ instead of geo_appro.
-
Benoît LÉ authored
[xFEM] Forgot to use xtool::xDataType<S>::zero() in xAssemblerLumpedBlockEqu and xAssemblerLumpedBlockEquInVector
-
Benoît LÉ authored
- Use integ instead of appro - Deal with the case r = 0
-
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.
-
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É 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.
-
- 18 Sep, 2020 1 commit
-
-
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.
-
- 17 Sep, 2020 1 commit
-
-
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)
-