eXlibris issueshttp://git.gem.ec-nantes.fr/groups/eXlibris/-/issues2017-12-12T09:13:49Zhttp://git.gem.ec-nantes.fr/eXlibris/ExternalLib/-/issues/1populate2017-12-12T09:13:49ZAlexis SALZMANpopulateThis have to be populate at least with following source package:
<ul><li> mumps 4.10
</li><li>pastix 5.2.1
</li><li>taucs 2.2
</li><li>SuperLU 3.0
</li><li>scotch 5.1.8
</li><li>parmetis 3.1.1
</li><li>CGAL 4.2
...This have to be populate at least with following source package:
<ul><li> mumps 4.10
</li><li>pastix 5.2.1
</li><li>taucs 2.2
</li><li>SuperLU 3.0
</li><li>scotch 5.1.8
</li><li>parmetis 3.1.1
</li><li>CGAL 4.2
</li><li>ann 1.1.2
</li><li>autopack 1.3.2
</ul>
As we stay with old software version for now.
Otherwise eXlibris interface should work with following newer version in future:
<ul><li>mumps 5.0.1 (and above normally but API check needed)
</li><li>taucs 2.2 (patched)
</li><li>pastix ?? (with new scotch API which version is needed and compatible with eXlibris interface is an open question)
</li><li>SuperLU ?? (with new metis API which version is needed and compatible with eXlibris interface is an open question)
</li><li> scotch 6.0.0
</li><li>parmetis 4.0.3
</ul>http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/34geom: distance computation in distributed context with ann or brute force2018-04-25T07:45:54ZAlexis SALZMANgeom: distance computation in distributed context with ann or brute forceCommit 3b05590 introduce a way to compute distance to a surface in distributed context with CGAL. The same should be done with ANN at least and maybe for brute force. Test case functional_xDistanceNearestPointDist should be modified in c...Commit 3b05590 introduce a way to compute distance to a surface in distributed context with CGAL. The same should be done with ANN at least and maybe for brute force. Test case functional_xDistanceNearestPointDist should be modified in consequence.Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/15Differences in exports between Lagrangian and Fast Marching computation of no...2018-04-26T08:04:21ZBenoît LÉDifferences in exports between Lagrangian and Fast Marching computation of non local fieldsSome quantities are exported only for one method and not the other (for instance, Y can be exported only with the Lagrangian method). Also, some exports have different names: for instance, Y is exported using the keyword Y_mean with the ...Some quantities are exported only for one method and not the other (for instance, Y can be exported only with the Lagrangian method). Also, some exports have different names: for instance, Y is exported using the keyword Y_mean with the Lagrangian method, and with the keyword Y_bar with the Fast Marching method.http://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/4xIteratorRegion2018-04-26T08:04:22ZAlexis SALZMANxIteratorRegionIf those tools remains, a cleaning of parametis must be done. Use of new parmetis interface must be done.If those tools remains, a cleaning of parametis must be done. Use of new parmetis interface must be done.http://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/3readReferenceLoad in DamageEvals2018-04-26T08:04:22ZBenoît LÉreadReferenceLoad in DamageEvalsBe careful: reference loading Fref is obtained by function readReferenceLoad in DamageEvals.h/cc. Currently the main.dat file is parsed, then the numerical value corresponding to the last occurrence of one the following keyword is taken...Be careful: reference loading Fref is obtained by function readReferenceLoad in DamageEvals.h/cc. Currently the main.dat file is parsed, then the numerical value corresponding to the last occurrence of one the following keyword is taken for the reference load (even if it is commented) : “ TRACTION_X” , “ TRACTION_Y” , “ TRACTION_Z” , “ PRESSURE” and “ STRESS.
Possible solution for readReferenceLoad implementation: read Fref directly from the xData, for instance, by giving to readReferenceLoad physical ID of boundary where Fref is applied, instead of parsing the main.dat.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/31xDoubleManager/xValManger distributed concept2018-05-18T07:23:37ZAlexis SALZMANxDoubleManager/xValManger distributed conceptHas mentioned in commit d1f3ed5561e76ed4c2b318220128f5af68a19cc0 the partition manager introduced in double manager may be generalized to xValManager.
Make a template version of xValKeyDataManager would be certainly a must. But how ...Has mentioned in commit d1f3ed5561e76ed4c2b318220128f5af68a19cc0 the partition manager introduced in double manager may be generalized to xValManager.
Make a template version of xValKeyDataManager would be certainly a must. But how genPartitionManager would be done in xValManager. In a rather specific way as it is in xDoubleManager where xMesh::partman_t is expected. Or will it be generic wit a template type for mesh partition manager. In this case maybe it will be a bit touchy to deal with a generic partman to create xValManager partion manager (for example at no stage we want to introduce AOMD struff) ...
First check that this concept is good and then pass some time on this generalization ...Parallel integrationhttp://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.
http://git.gem.ec-nantes.fr/eXlibris/Xtest/-/issues/3Reference in parrallel2018-05-29T07:28:35ZAlexis SALZMANReference in parrallelIn commit c7446750 the test case reference is based on a partition done by parmetis. Unfortunately this test case do not give always the same partitioning in between runs ... eXlibris_tools communication library which run in an asynchro...In commit c7446750 the test case reference is based on a partition done by parmetis. Unfortunately this test case do not give always the same partitioning in between runs ... eXlibris_tools communication library which run in an asynchronous manner may induce different entities ordering in meshes. This may drive to graph with different node numbering and may impact parmetis in his graph partitioning. And maybe parmetis itself is not deterministic ?
This asynchronous specificity is also involved in other test case.
Reference in parallel should then be something more smarted then just results on partition that may differ from run to run ...
No solution for now .... but a solution must be found ...Parallel integrationhttp://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/19xStringManager2018-07-10T07:56:27ZAlexis SALZMANxStringManagerIn adb708519561c2fdcbb458207f6d1fe63d818050 we had a function which need to communicate keys (xValKey) in between proc. Due to lack of synchronization in xStringManager this have been done with string !!!<br>
If, in xKeyInfo in particu...In adb708519561c2fdcbb458207f6d1fe63d818050 we had a function which need to communicate keys (xValKey) in between proc. Due to lack of synchronization in xStringManager this have been done with string !!!<br>
If, in xKeyInfo in particular, association of string with “int” is not done in the same order in all proc we cannot rely on “int” value to communicate. A way to bypass this problem is to set explicitly this association at the beginning of your application (and by implementation in the same order for all proc). But it is difficult to be sure that we did set all mandatory association and it's hard for beginners to figure out which association must be set...<br>
<br>
The ideal solution from a user point of view is that xStringManager do appropriate communication to insure uniqueness of association string<=> integer.<br>
<br>
From a performance point of view a solution must be find to achieve this goal but with as minimal communication as possible. <br>
<br>
It is a tricky problem despite it's apparent simplicity. We are in asynchronous context and there is no reason that call to xStringManager methods are done at the same time !! Synchronization just for that ... please don't think about it. Windowing ??? Maybe.
---
An alternative is to consider that the id (integer) associated to a string in xStringManager is no more depending on order in which it is created but depends only on the string itself.
The T nb = s_.size(); would be replace by
T nb = static_cast<T>(str_hash(s)); with str_hash being std::hash\<std::string\> str_hash;
The c++11 hash class is expected to give no collision in regard of the set of string used in xfem. Unfortunately, in Xfem, xKeyInfo is using a T of type "int" which is smaller then the size_t type returned by C++11 hash operator. So this first casting, that appears here with static_cast call, is a first concern: does the casting will not increase artificially collision ?
And when we see that xValKey itself is using short, this last casting will or will not increase collision ?
Due to those last interrogation it looks difficult to relies on a collision free hash function at xStringManager level but it would have solve the issue without any communication ....
One can thing of creating a hash function that do return a short:
short hash(std::string & str)
{
unsigned short h = 0;
unsigned short mx=std::numeric_limits<unsigned short>::max();
for (auto c : str)
{
h = ((( h << 5 ) + h ) + c)%mx; /* hash * 33 + c : I added this dirty %mx but in fact I think it is not mandatory */
}
return static_cast<short>(h);
}
This hash function base on djb2 algorithm (k=33) first reported by Dan Bernstein many years ago in comp.lang.c may give no collision in our context. But then the fact that xValkey is using short and xKeyInfo int remain a problem as using this short hash function for T being a int is quite ugly ...
Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/15xExport2018-07-23T12:35:49ZAlexis SALZMANxExportSome PARALEL oldies must be treated in a new way :
<ul><li>xExport must have their comunicator given has argument with MPI_COM_WORD as default</li>
<li>multi file must be refplaced by some MPIO/hdf5 mecanism</li>
</ul>
To start, us...Some PARALEL oldies must be treated in a new way :
<ul><li>xExport must have their comunicator given has argument with MPI_COM_WORD as default</li>
<li>multi file must be refplaced by some MPIO/hdf5 mecanism</li>
</ul>
To start, using one file per proc with right extention will be simple and it will force user to use unique name for their Export calls. Passing to MPIO will then be transparent ( i.e. in implementation).Parallel integrationhttp://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.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 !