Xfiles issueshttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues2019-03-20T09:43:17Zhttp://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/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/20bugg migrateEntities (load balance tool)2018-05-18T07:23:37ZAlexis SALZMANbugg migrateEntities (load balance tool)There is a problem with mEntity::equal method:
In delete stage of migrateEntities a call is done to DEL_updateAdj with entity created in One level manner. Maybe DEL_oneLevel would have been more appropriate but it is not the problem....There is a problem with mEntity::equal method:
In delete stage of migrateEntities a call is done to DEL_updateAdj with entity created in One level manner. Maybe DEL_oneLevel would have been more appropriate but it is not the problem. The problem is that both of those methods call the mMesh::del method which remove entity given in argument from allEntities container. Erasing a element from this container (unordered container) imply comparing with mEntity::equal. But this method apparently is not working well in the context of migrateEntities ?? SEGFAULT on some plateform with some files (in 3D context).
It looks to vertex to do its comparison of id and says if both entities are equal or not.
Retriving vertex is done by mEntity:get method.
For full adjancy get will give vertex imadiatelly for any tet, face, edge .
For One level adjancy its more complicate :
For a tet, get will call getTemplate as it does not have theAdjacencies[O]. mTet::getTemplate(ith,0,0) will look if edge adjancy exist and if not to face adjancy which is supose to exist. Then it will try to find vertex comon to 3 faces coresponding to ith corner (mFace::commonVertex). This method itself try to retrive vertex of each face using mEntity::get which calls mFace::getTemplate(kth,0,0) which try to find vertex by finding common vertex of edges !
Sommewhere in this process something went wrong as in mEntity::equal the get(0,i) return a null pointer and v1[i]=get(0,i)->getId(); SEGFAULT ....
In fact by looking to definition of tet compared, one of them have only 2 faces ???
Don't know if prb is in AOMD side or migrate side.
To be more invistigated ...