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/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/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/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/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 ....http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/45xGenericSparseMatrix in distributed context2019-12-02T15:39:48ZAlexis SALZMANxGenericSparseMatrix in distributed contextFor now all distributed problem where using an instance of xGenericSparseMatrix without futher implication. Issue #17 is already tackling one current unfeatured topic (distributed matrix by distributed vector operation).
But there is m...For now all distributed problem where using an instance of xGenericSparseMatrix without futher implication. Issue #17 is already tackling one current unfeatured topic (distributed matrix by distributed vector operation).
But there is more functionality bugged in distributed parallel context:
* normMax (need a AllReduce)
* fillZeroDiag (more complex as it needs to test that distributed contribution of diag term are all null before replacing one of it by value computed with normMax)
Maybe there is other topics (I don't inspect every thing).
Also a strategy may have to be settle to explicitelly deal with distributed format COO -> COODIST ....Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/41xpPhysicalFormulation2018-07-27T09:00:48ZAlexis SALZMANxpPhysicalFormulationclang warns about unused variable 'res_renum' in xpPhysicalFormulation.
```cpp
declareInternalVariables();
if(renumbered) pair<int, int> res_renum = renumber();
updateInternalVariables();
return;
```
Look like a bugg...clang warns about unused variable 'res_renum' in xpPhysicalFormulation.
```cpp
declareInternalVariables();
if(renumbered) pair<int, int> res_renum = renumber();
updateInternalVariables();
return;
```
Look like a bugg but things are working well as renumber do the job (xReverseCutHillMcKeeNumberingBoost in some cases). There is just no need to store this returned value. To checkhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/18DAMAGEDZONELAW2018-09-07T13:41:23ZBenoît LÉDAMAGEDZONELAWIn specific_to_devel_stage.h, the macro DAMAGEDZONELAW is used:
- To switch between some evaluators inside compute_elastic (it was some king of "ancestor" of the class xEnergyModel) (for instance the Anisotropic evaluators ???)
- To swit...In specific_to_devel_stage.h, the macro DAMAGEDZONELAW is used:
- To switch between some evaluators inside compute_elastic (it was some king of "ancestor" of the class xEnergyModel) (for instance the Anisotropic evaluators ???)
- To switch between different behavior inside the fully damaged zone. This is done directly into the implementation of the evaluators of the stress tensors, tangent matrix, etc, in xEnergyModel.cc.
In the future, DAMAGEDZONELAW should be removed:
- xEnergyModel can eventually be used to switch between the evaluators
- If DAMAGEDZONELAW (which is specific to DamageBand) is removed, xEnergyModel could be put in Xfiles (for instance), to be usable in any other Appli than DamageBand
As there is no urgent need for the moment, things are kept as is, but if someday the evaluators of xEnergyModel are needed in another Appli, the cleaning/transfer will have to be done.http://git.gem.ec-nantes.fr/eXlibris/Xtest/-/issues/4functional_xDistanceNearestPoint2018-07-26T10:35:58ZAlexis SALZMANfunctional_xDistanceNearestPointWrong test as it produce computer/compiler reference dependency.
The lines:
```cpp
// (3-2-5)
double radius_factor = 3.;
std::map<AOMD::mVertex*, double> nearest_vertices_distances_ANN_5;
distance_nearest...Wrong test as it produce computer/compiler reference dependency.
The lines:
```cpp
// (3-2-5)
double radius_factor = 3.;
std::map<AOMD::mVertex*, double> nearest_vertices_distances_ANN_5;
distance_nearest_point_ANN.nearestVerticesInsideRadiusDistances(point, radius_factor, nearest_vertices_distances_ANN_5);
.
.
.
filestr << "(3-2-5) " << std::endl;
for (std::map<AOMD::mVertex*, double>::const_iterator it=nearest_vertices_distances_ANN_5.begin(); it!=nearest_vertices_distances_ANN_5.end(); ++it)
{
Trellis_Util::mPoint point_tmp = (it->first)->point();
filestr << " " << it->second << " | " << point_tmp(0) << " , " << point_tmp(1) << " , " << point_tmp(2) << std::endl;
}
```
with clang for example do give the same information as g++ but not in the same order as map order is address dependent. To modify by following increasing distance value order for example.