Xfiles issueshttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues2019-09-30T19:44:18Zhttp://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/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/Xfiles/-/issues/40Compiling with clang++2018-07-27T13:38:51ZAlexis SALZMANCompiling with clang++Now that clang++ 3.9.0 is installed on titan (/opt/llvm-3.9.0/bin/clang++) it is possible to do some compilation test with this compiler.
Modify your LocalConfig.cmake to use clang++ and rebuild everything.
A full Ctest on Xtest have ...Now that clang++ 3.9.0 is installed on titan (/opt/llvm-3.9.0/bin/clang++) it is possible to do some compilation test with this compiler.
Modify your LocalConfig.cmake to use clang++ and rebuild everything.
A full Ctest on Xtest have been done and give almost same results as g++.
First remark regarding CMAKEFILE, clang give the following message:
```
clang-3.9: warning: optimization flag '-frounding-math' is not supported
```
This mean that we have put this flag every-where or almost but it is compiler dependent !!! If we pass to modern cmake we will be able to use `$<COMPILER_ID:GNU>,$<COMPILER_ID:Clang>` stuff to appropriately use -frounding-math or not
When using MUMPS or PASTIX clang need to have an explicit -lpthread. Those libraries where compiled with g++. Maybe with this compiler the -lpthread is automatically set. Like above if we pass to modern cmake we may encapsulate MUMPS or PASTIX target dependencies and fix cleanly those dependencies with `$<COMPILER_ID:GNU>,$<COMPILER_ID:Clang>` stuff.
What is more interesting is that clang have note exactly the same behavior as g++ regarding errors and warnings. For example with -Wconversion clang check implicit conversion miss formed (this is not possible with g++):
```cpp
#include <iostream>
#include <vector>
using namespace std;
int main ()
{
size_t h=1234567891123456Lu;
int hi;
short hs;
hi=h;
hs=h;
cout<<"h "<<h<<endl;
cout<<"hi "<<hi<<endl;
cout<<"hs "<<hs<<endl;
hi=-1;
h=hi;
cout<<"h "<<h<<endl;
cout<<"hi "<<hi<<endl;
vector<int> v(3,1);
int l=v.size();
v[l-1]=4;
for (auto val : v)
cout<<val<<endl;
return 0;
}
```
With this code clang produce following messages:
```
clang++ -std=c++11 -Wconversion main.cc
main.cc:13:8: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'short' [-Wconversion]
hs=h;
~^
main.cc:20:7: warning: implicit conversion changes signedness: 'int' to 'size_t' (aka 'unsigned long') [-Wsign-conversion]
h=hi;
~^~
main.cc:27:8: warning: implicit conversion changes signedness: 'int' to 'size_type' (aka 'unsigned long') [-Wsign-conversion]
v[l-1]=4;
~ ~^~
main.cc:12:8: warning: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
hi=h;
~^
main.cc:26:13: warning: implicit conversion loses integer precision: 'size_type' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
int l=v.size();
~ ~~^~~~~~
5 warnings generated.
```
With eXlibris many messages of those types are issued ... For many it is only a matter of using `int` instead of `size_t` when dealing with STL container. But unfortunately this is masking more interesting ones that may be mistakes or error !http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/38Drop xTable ?2018-07-09T12:59:15ZGrégory LEGRAINDrop xTable ?xTable class (xTable.h) does not seem to be used in practical applications although it is used in xTensors.h.
Maybe we should drop it ?xTable class (xTable.h) does not seem to be used in practical applications although it is used in xTensors.h.
Maybe we should drop it ?http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/37Cleanup xPhysSurf, Export ensight2018-09-07T11:45:02ZGrégory LEGRAINCleanup xPhysSurf, Export ensightxPhysSurf is now deprecated for a while, as in practice, everybody (?) use xPhysSurfByTagging. I would make sense to move it to attic.
Maybe we could also clean some tags from xMesh that were only used by xPhysSurf
xExportEnsight has n...xPhysSurf is now deprecated for a while, as in practice, everybody (?) use xPhysSurfByTagging. I would make sense to move it to attic.
Maybe we could also clean some tags from xMesh that were only used by xPhysSurf
xExportEnsight has not been used for ages... we should move it to atticGrégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/32kill xPhysSurf ?2018-09-07T11:44:16ZGrégory LEGRAINkill xPhysSurf ?the (old) xPhysSurf is (in practice) deprecated in favor of xPhysSurfByTagging.
We should move it to attic.
Though, it necessitates some fixes in some testcases and classes...the (old) xPhysSurf is (in practice) deprecated in favor of xPhysSurfByTagging.
We should move it to attic.
Though, it necessitates some fixes in some testcases and classes...Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/26CGAL interface not compatible with CGAL 4.112018-05-18T07:23:37ZGrégory LEGRAINCGAL interface not compatible with CGAL 4.11AABBPrimitiveExtension.h seems incompatible with new CGAL implementation
`pas de concordance pour l'appel à « (CGAL::Cartesian_base_no_ref_count<double, CGAL::Simple_cartesian<double> >::Construct_projected_point_3 {aka CGAL::CartesianK...AABBPrimitiveExtension.h seems incompatible with new CGAL implementation
`pas de concordance pour l'appel à « (CGAL::Cartesian_base_no_ref_count<double, CGAL::Simple_cartesian<double> >::Construct_projected_point_3 {aka CGAL::CartesianKernelFunctors::Construct_projected_point_3<CGAL::Simple_cartesian<double> >}) (CGAL::internal::Primitive_helper<CGAL::AABB_traits<CGAL::Simple_cartesian<double>, CGAL::AABB_point_primitive<CGAL::Simple_cartesian<double>, __gnu_cxx::__normal_iterator<CGAL::Point_3<CGAL::Simple_cartesian<double> >*, std::vector<CGAL::Point_3<CGAL::Simple_cartesian<double> > > > > >, false>::Datum_type, const Point&) »
Point closest_point = geom_traits.construct_projected_point_3_object()(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
internal::Primitive_helper<AT>::get_datum(pr,m_traits), p);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`
It complains that the point to point case (whici is de fined in AABBPrimitiveExtension. if I am correct) is missing.
Good to know when we will update the version which is available on the platformGrégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/25Keeping boost iostream isolated2018-05-18T07:23:37ZAlexis SALZMANKeeping boost iostream isolatedDiscussion around cmake point out that with some effort (little ?) we may hide boost iostram (used for gzip output) from Xfem interface.
That may also be treated as an extra interface in xInterface.
In one hand treating it in Xfem corr...Discussion around cmake point out that with some effort (little ?) we may hide boost iostram (used for gzip output) from Xfem interface.
That may also be treated as an extra interface in xInterface.
In one hand treating it in Xfem correspond to where it is used for now, in the other adding it as an Xinterface gives a way to use it everywhere.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/24treillis with _DEBUG_ macro enable2018-05-18T07:23:37ZAlexis SALZMANtreillis with _DEBUG_ macro enableIn Treillis, in mVector and mPoint (at least) if _DEBUG_ macro is enable code does not compile.
Bug correction needed.
For now don't turn on USE_DEBUG_FLAG option in cmake (which is not only a printing stuff as message suggest)In Treillis, in mVector and mPoint (at least) if _DEBUG_ macro is enable code does not compile.
Bug correction needed.
For now don't turn on USE_DEBUG_FLAG option in cmake (which is not only a printing stuff as message suggest)http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/21Removing xFitToVertexKeyManager in xFitToVertices class2018-05-18T07:23:38ZAlexis SALZMANRemoving xFitToVertexKeyManager in xFitToVertices classFollowing commit 5d34c604 the key manager xFitToVertexKeyManager should be remove and usage replace by new keyManagerSendOrReceiveFollowing commit 5d34c604 the key manager xFitToVertexKeyManager should be remove and usage replace by new keyManagerSendOrReceivehttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/16xCFL getDt2018-05-18T07:23:38ZAlexis SALZMANxCFL getDtFrom Kevin Moreau this is weird to divide by 1 and by 2 ! missing parenthesis (i.e. divinding by 0.5) or volonteer (i.e. divinding by 2.)
<br>
double xCFL::getDt(xRegion s) {<br>
return ((xCFL::getLength(s))/1./2.);<br>
}From Kevin Moreau this is weird to divide by 1 and by 2 ! missing parenthesis (i.e. divinding by 0.5) or volonteer (i.e. divinding by 2.)
<br>
double xCFL::getDt(xRegion s) {<br>
return ((xCFL::getLength(s))/1./2.);<br>
}http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/14newMeshDataId vs lookupMeshDataId2018-05-18T07:23:38ZAlexis SALZMANnewMeshDataId vs lookupMeshDataIdIt looks like lookupMeshDataId have been used in many place in xfem. But it is not so clear to me that newMeshDataId would have not been the right choice in some cases.
To checkIt looks like lookupMeshDataId have been used in many place in xfem. But it is not so clear to me that newMeshDataId would have not been the right choice in some cases.
To checkhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/11Boost2018-05-18T07:23:38ZAlexis SALZMANBoostCommit 297718b and GemUtil commit 12aa2c6 introduce new BOOST_SPECIAL_INCLUDE_PATH variable.
It have been used sucessfully with Xfem and SplitMesh/test. But it had to be done on all CMAKE of eXlibris where it have to.
It replace prope...Commit 297718b and GemUtil commit 12aa2c6 introduce new BOOST_SPECIAL_INCLUDE_PATH variable.
It have been used sucessfully with Xfem and SplitMesh/test. But it had to be done on all CMAKE of eXlibris where it have to.
It replace properly what was done in eXlibrisType.
Boost version checking mechanism may have to be adapted.