eXlibris issueshttp://git.gem.ec-nantes.fr/groups/eXlibris/-/issues2020-07-21T15:00:40Zhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/66ExportSensors2020-07-21T15:00:40ZAlexis SALZMANExportSensorsthis stuff should be migrate to xExport lib to generalize its usage without depending on xCrack for just data collection.this stuff should be migrate to xExport lib to generalize its usage without depending on xCrack for just data collection.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/64dot export in xExport2020-04-02T10:56:32ZAlexis SALZMANdot export in xExportThe creation of dot file is for now in xGraph. Maybe it would make sens ... or not to put exportDot in xExport. To think about.The creation of dot file is for now in xGraph. Maybe it would make sens ... or not to put exportDot in xExport. To think about.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/63Possible bug in TreatmentOfEssentialEnv ?2020-04-20T15:43:05ZGrégory LEGRAINPossible bug in TreatmentOfEssentialEnv ?`TreatmentOfEssentialEnv` in `xAlgorithm.h` contains the following statement:
`xFilteredRegion<xIter, xAcceptUnion> dir_reg(all.begin(1), all.end(1), filter_dirichlet);`
Meaning that the filter is applied only on edges, which is fine ...`TreatmentOfEssentialEnv` in `xAlgorithm.h` contains the following statement:
`xFilteredRegion<xIter, xAcceptUnion> dir_reg(all.begin(1), all.end(1), filter_dirichlet);`
Meaning that the filter is applied only on edges, which is fine in 2D, but not in 3D. I would rather use:
`xFilteredRegion<xIter, xAcceptUnion> dir_reg(all.begin(mesh->getDim()-1), all.end(mesh->getDim()-1), filter_dirichlet);`
What do you think ?Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/62bugg in update methode of xPhysSurfCut2020-02-10T16:12:44ZAlexis SALZMANbugg in update methode of xPhysSurfCutWhen close node treatment involve several element all null iso-edge points to the close node for upper "creator". Then close node points to one of those elements.
When updating an iso that rotate around this close node treatment the cl...When close node treatment involve several element all null iso-edge points to the close node for upper "creator". Then close node points to one of those elements.
When updating an iso that rotate around this close node treatment the cleanAroundEdge if called with one edge not anymore cut, will destroy this last link. And if among the remaining element one is not topologicaly new there will be a problem as this link from close node points to one of those elements is broken and not re-created. It is a bug.
It has been discovered by B.L. with iso that move slowly.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/61Change SolVisitors default template ?2020-01-27T17:10:24ZGrégory LEGRAINChange SolVisitors default template ?`xWriteSolutionVisitor` and co use `xCSRVector` as default template parameter. Now, the preferred version of the code is the parallel one which used `xDistVector`. Should we change the default ?
If you agree :thumbsup: `xWriteSolutionVisitor` and co use `xCSRVector` as default template parameter. Now, the preferred version of the code is the parallel one which used `xDistVector`. Should we change the default ?
If you agree :thumbsup: Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/60Move type-dependent code in xField out of the core of the class2020-01-27T17:51:56ZGrégory LEGRAINMove type-dependent code in xField out of the core of the classType-dependent code in xField:
`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);`
and getGrad ar...Type-dependent code in xField:
`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);`
and getGrad are located in the core of the class, making it cumbersome to extend to new user-types. We should try to see if we can implement this logic in the user's code.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/59Upgrade compiler on titan2020-02-04T10:22:15ZGrégory LEGRAINUpgrade compiler on titanWe should investigate to upgrade the compiler on titan. gcc 4.8 is quite old.
This leads to some limitations during template deduction. The code is thus less compact as we have to help the compiler to figure out what is going on (see `De...We should investigate to upgrade the compiler on titan. gcc 4.8 is quite old.
This leads to some limitations during template deduction. The code is thus less compact as we have to help the compiler to figure out what is going on (see `DeclareInterpolation<xField<valtype> >` and `DeclareState<xField<valtype> >` where the template parameter could be removed with more recent versions of gcc).http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/58Build the float and complex versions of mumps2020-01-27T17:51:56ZGrégory LEGRAINBuild the float and complex versions of mumpsFloat and complex versions of mumps are not available for the moment. This prevents to run some testcases.Float and complex versions of mumps are not available for the moment. This prevents to run some testcases.Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/22Bug when using single cut with update_displacement_field = 12020-01-08T15:23:02ZBenoît LÉBug when using single cut with update_displacement_field = 1When running a computation with the single cut and with the option update_displacement_field = 1 (use of previous displacement field at the begining of a Newton Raphson loop), the computation may abort in the xtls::TLSEnrichment_3::updat...When running a computation with the single cut and with the option update_displacement_field = 1 (use of previous displacement field at the begining of a Newton Raphson loop), the computation may abort in the xtls::TLSEnrichment_3::updateValues.
A "quick" fix is to use update_displacement_field = 0, in order not to use the updateValues function. Note that this problem has not been observed with the double cut (tested on the Lshaped test case, with 8 different computations for the single cut and 8 different computations for the double cut).http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/57dependencies of xfem on xcut2019-12-20T16:57:04ZNicolas CHEVAUGEONdependencies of xfem on xcutActually xfem depends on xcut and vice versa. I propose to change that.
I checked, it's possible with a few changes.
Most of the dependencies are through constructor of enriched shape function that take an xPhysSurf as an input.
In fact,...Actually xfem depends on xcut and vice versa. I propose to change that.
I checked, it's possible with a few changes.
Most of the dependencies are through constructor of enriched shape function that take an xPhysSurf as an input.
In fact, thoses constructor only use the xPhysSurf to call the member getLevelSet(). The exaxt same object can already be constructed by passing directly the level-set to them.
I propose to remove this constructor.
The above done, there is one other dependencies in xValue.h/cc the xValueCreatorRampedHeaviside family of class have constructor that rely heavily on the xPhysSurbyTagging interface.
After discussion with Alexis, This functionality is only use for tls, so this class can be moved to xTLS.
I propose do do it. I already started, It works. It's not pushed yet because of some problem on titan at the time I'm writing this.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/56build xInterfaceSuperLU with differents version of super LU2019-12-13T14:32:38ZNicolas CHEVAUGEONbuild xInterfaceSuperLU with differents version of super LUxInterfaceSuperLU actually work with different versions of SUPERLU (3,4 and 5), provided that one manually change the xInterfaceSuperLU.cc/h so that the macro SUPERLU_VERSION is set to the desired value, the default official one being 3....xInterfaceSuperLU actually work with different versions of SUPERLU (3,4 and 5), provided that one manually change the xInterfaceSuperLU.cc/h so that the macro SUPERLU_VERSION is set to the desired value, the default official one being 3.
I propose to modify the build system so that :
- FindSUPERLU.cmake automagically find the version of superlu used
- the xInterfaceSuperLU/CMakeLists.txt set the compiler definition flag -DSUPERLU_VERSION to the correct value.
this way, one could compile xInterfaceSuperLU with any version of superlu without having to manually change the SUPERLU_VERSION MACRO in the input file.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/55xSupportComponent handeling2019-12-12T08:26:23ZAlexis SALZMANxSupportComponent handelingWith new tools that we have instead of deriving from AOMD::mAttachableData use of DATAMANAGER concept would be more handy.
It would simplify issue #54 by having xcut::xPhysdomain (and others xcut class) providing directly a DATAMANAGER ...With new tools that we have instead of deriving from AOMD::mAttachableData use of DATAMANAGER concept would be more handy.
It would simplify issue #54 by having xcut::xPhysdomain (and others xcut class) providing directly a DATAMANAGER instance.
The getSupportComponnet may remains.
It may remove AOMD specific attachable mechanism in xFEM
To think abouthttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/53xcFrontSpaces warning that looks as a bugg2019-09-30T19:44:18ZAlexis SALZMANxcFrontSpaces warning that looks as a buggxxxx/Xfiles/xCrack/src/xcFrontSpaces.cc:557:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (!((s>x0)&&(s<x1)))
^~
xxxx/Xfiles/xCrack/src/xcFrontSpaces.cc:558:36: note: ...this statement, but the l...xxxx/Xfiles/xCrack/src/xcFrontSpaces.cc:557:4: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (!((s>x0)&&(s<x1)))
^~
xxxx/Xfiles/xCrack/src/xcFrontSpaces.cc:558:36: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
res = xtensor::xVector<>(0.); return;
^~~~~~http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/52xElementInfoManager2019-09-26T08:45:17ZAlexis SALZMANxElementInfoManagerxElementInfoManager is apparnetelly mainely used in xCFL with a singleton.
Map and singleton are note threadsafe concept ....
May be replace in the future by some thread safe mechanism.xElementInfoManager is apparnetelly mainely used in xCFL with a singleton.
Map and singleton are note threadsafe concept ....
May be replace in the future by some thread safe mechanism.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/51xPhysSurfVLS2019-12-12T08:20:48ZGilles MARCKMANNxPhysSurfVLSThe class definition/implementation of xPhysSurfVLS are in xFEM/src/xVectorLevelSet.h/cc:
- It should be in xCut but where exactly ??
- It should also be attic but some xTLS functions still depend on this class.The class definition/implementation of xPhysSurfVLS are in xFEM/src/xVectorLevelSet.h/cc:
- It should be in xCut but where exactly ??
- It should also be attic but some xTLS functions still depend on this class.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/50getAttachedSVLSHeavisideData/getAttachedVLSHeavisideData functions2019-05-28T09:35:21ZAlexis SALZMANgetAttachedSVLSHeavisideData/getAttachedVLSHeavisideData functionsBoth functions are using dynamic_cast and it cost a lot (65% under callgrind, instead of seeing getData). Apparently it could be replaced by a static cast if we are confident with the used tag. Because type checking is only here to prev...Both functions are using dynamic_cast and it cost a lot (65% under callgrind, instead of seeing getData). Apparently it could be replaced by a static cast if we are confident with the used tag. Because type checking is only here to prevents miss usage of tag not used to attach HeavisideData ... From a design point of view creating a class that store tag and ways to access data related to this tag is safer. This is what xAttachedDataManagerAOMD provides and it may be used instead of those functions.
But anyway getData return a void pointer wich is null if no data found and a static_cast may work as a charm in most cases (no one use those functions directly ... no ?? ). By removing getAttachedSVLSHeavisideData declaration in header it would finish to isolated this function ... and avoid her mis usage ...http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/49xIntegrateFormCommand usage2019-05-28T08:43:14ZAlexis SALZMANxIntegrateFormCommand usagexIntegrateFormCommand (in xCommandOnGeomElem.h/cc) has an ambiguous usage. If you use it with a form that use an geo_appro xGeomElem object it do not work. The xCommandOnGeomElem base class provides openApproxElem method. But this method...xIntegrateFormCommand (in xCommandOnGeomElem.h/cc) has an ambiguous usage. If you use it with a form that use an geo_appro xGeomElem object it do not work. The xCommandOnGeomElem base class provides openApproxElem method. But this methode do not change form instance according to the given geo_appro argument. So xIntegrateFormCommand::execute that run accumulate form method bugg because form geo_appro is not set. For over form kind this have presumelly no impact.
In xFied.h/cc xFillFieldFromZeroForm derive form xIntegrateFormCommand and overload openApproxElem to call form init with geo_appro.
Something have to be done to make xIntegrateFormCommand more secure (i.e. prohibite its direct usage with form needing a call to init to set geo_appro): make it abstract ? Add doc to expose limitation ? make it template on form and do template specialization ? ... ?http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/48Exception in parrallel2019-03-20T09:43:17ZAlexis SALZMANException in parrallelIn some plateform (liger at least) throwing an exception in a parallel application lead to bad behavior. Say some process terminate due to the launched exception but other process do continue .... and the job run till MaxTime limite is r...In some plateform (liger at least) throwing an exception in a parallel application lead to bad behavior. Say some process terminate due to the launched exception but other process do continue .... and the job run till MaxTime limite is reachead (not to good).
Suprisingly if exception is catched and a MPI_Abort is called the same problem hold ?!?!
To be investigate ....http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/47xElement2019-03-13T11:32:46ZAlexis SALZMANxElementThis class have a strange method:
* xyz2uvw is only treating HEX,QUAD and EDGE. What about TET,TRI ?
* xyz2uvw use mapping : why not doing implementation like TET,TRIThis class have a strange method:
* xyz2uvw is only treating HEX,QUAD and EDGE. What about TET,TRI ?
* xyz2uvw use mapping : why not doing implementation like TET,TRIhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/46xGeneralUnorderedMapDataManager integration2018-11-16T10:00:34ZAlexis SALZMANxGeneralUnorderedMapDataManager integrationcommit 8710e3541e6eb47d68d88ec6234eb83d40b604ee introduce xGeneralUnorderedMapDataManager
It have to be integrated in xfem xDoublemanager.
It's just a question of replacing comment, removing xValKeyDataManager and pass Xtest test.
Norma...commit 8710e3541e6eb47d68d88ec6234eb83d40b604ee introduce xGeneralUnorderedMapDataManager
It have to be integrated in xfem xDoublemanager.
It's just a question of replacing comment, removing xValKeyDataManager and pass Xtest test.
Normally nothing more ....