eXlibris issueshttp://git.gem.ec-nantes.fr/groups/eXlibris/-/issues2019-12-13T14:32:38Zhttp://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/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/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/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/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/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/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/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.