Xfiles issueshttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues2019-12-02T15:39:48Zhttp://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/44Compiler warnings since #436970072019-03-13T08:58:53ZGrégory LEGRAINCompiler warnings since #43697007```
In file included from /glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.cc:7:0:
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h: In instantiation of ‘xfem::xSpacePolynomialQH<SPACETYP...```
In file included from /glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.cc:7:0:
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h: In instantiation of ‘xfem::xSpacePolynomialQH<SPACETYPE>::xSpacePolynomialQH(const string&, const string&, xfem::xSpace::TensorialType_t, int) [with SPACETYPE = xfem::tensorSpaceDefinition; std::string = std::basic_string<char>]’:
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.cc:32:70: required from here
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:133:23: attention : ‘xfem::xSpacePolynomialQH<xfem::tensorSpaceDefinition>::space_name’ will be initialized after [-Wreorder]
const std::string space_name;
^
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:127:15: attention : ‘const int xfem::xSpacePolynomialQH<xfem::tensorSpaceDefinition>::nb_shape_edge’ [-Wreorder]
const int nb_shape_edge;
^
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:158:1: attention : lorsqu'initialisé ici [-Wreorder]
xSpacePolynomialQH<SPACETYPE>::xSpacePolynomialQH( const std::string& _space_name, const std::string& physical_name, TensorialType_t c, const int p)
^
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h: In instantiation of ‘xfem::xSpacePolynomialQH<SPACETYPE>::xSpacePolynomialQH(const string&, const string&, xfem::xSpace::TensorialType_t, int) [with SPACETYPE = xfem::trunkSpaceDefinition; std::string = std::basic_string<char>]’:
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.cc:156:94: required from here
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:133:23: attention : ‘xfem::xSpacePolynomialQH<xfem::trunkSpaceDefinition>::space_name’ will be initialized after [-Wreorder]
const std::string space_name;
^
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:127:15: attention : ‘const int xfem::xSpacePolynomialQH<xfem::trunkSpaceDefinition>::nb_shape_edge’ [-Wreorder]
const int nb_shape_edge;
^
/glouton/struct/asalzman/develop/Xfiles/Xfem/Xfem/src/xSpacePolynomialQH.h:158:1: attention : lorsqu'initialisé ici [-Wreorder]
xSpacePolynomialQH<SPACETYPE>::xSpacePolynomialQH( const std::string& _space_name, const std::string& physical_name, TensorialType_t c, const int p)
```
^Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/42xApproxFunctionScalarEdgeBernstein2018-09-05T08:48:36ZAlexis SALZMANxApproxFunctionScalarEdgeBernsteinclang++ complain with '`xfem::xApproxFunctionScalarEdgeBernstein::getVal`' hides overloaded virtual functions.
'`void getVal(const double & u, double & res) const`' is the one which hides:
`virtual void getVal(const xGeomElem* geo_appr...clang++ complain with '`xfem::xApproxFunctionScalarEdgeBernstein::getVal`' hides overloaded virtual functions.
'`void getVal(const double & u, double & res) const`' is the one which hides:
`virtual void getVal(const xGeomElem* geo_appro, const xGeomElem* geo_integ, xVector& ) const;`
and
`virtual void getVal(const xGeomElem* geo_appro, const xGeomElem* geo_integ, xVector&, const xValKey & )const;`
from `xApproxFunction`. It is not clear to me if this is done on purpose or not.
From my understanding this mean that if we call `xfem::xApproxFunctionScalarEdgeBernstein::getVal` with those argument `const xGeomElem* geo_appro, const xGeomElem* geo_integ, xVector&` the compilation will fails as this signature is hidden.
Use of `using xApproxFunction::getVal;` in public part of this class remove warning and permit to do the above a priori.
A little example to choose the right solution:
```cpp
class base
{
public:
virtual void init(void);
virtual void init(int i, int k); // (1)
virtual void init(int i); // (2)
};
class derived : public base
{
public:
void init(void) override; // (3)
void init(double i); // (4)
//using base::init; // (5)
}
int main(int argc, char *argv[])
{
derived o;
o.init(); // call (3)
o.init(1); // call (4) or (2) if (5) uncommented
//o.init(2,4); // if uncommented do not compile or compile and call (1) if (5) uncommented
o.init(2.3); // call (4)
```
clang++ warning are:
```
In file included from main.cc:2:
./main.h:13:14: warning: 'derived::init' hides overloaded virtual functions [-Woverloaded-virtual]
void init(double i);
^
./main.h:5:22: note: hidden overloaded virtual function 'base::init' declared here: different number of parameters (2 vs 1)
virtual void init(int i, int k);
^
./main.h:6:22: note: hidden overloaded virtual function 'base::init' declared here: type mismatch at 1st parameter ('int' vs 'double')
virtual void init(int i);
^
1 warning generated.
```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/39Potential error in setUVWForVertex method of xGeomElem2020-02-07T12:53:31ZAlexis SALZMANPotential error in setUVWForVertex method of xGeomElemIn setUVWForVertex method of xGeomElem we have:
```cpp
blabla
switch(e->getType()) {
case mEntity::TET:
case mEntity::TRI:
switch(inod){
case 0:
Upos = 0.0;Vpos = 0.0;Wpos = 0.0;break;
case 1:
Upos = 1.0;Vpos = 0.0;...In setUVWForVertex method of xGeomElem we have:
```cpp
blabla
switch(e->getType()) {
case mEntity::TET:
case mEntity::TRI:
switch(inod){
case 0:
Upos = 0.0;Vpos = 0.0;Wpos = 0.0;break;
case 1:
Upos = 1.0;Vpos = 0.0;Wpos = 0.0;break;
case 2:
Upos = 0.0;Vpos = 1.0;Wpos = 0.0;break;
case 3:
Upos = 0.0;Vpos = 0.0;Wpos = 1.0;break;
default: assert(0); throw; break;
}
break;
blabla
```
If by error some one use with a TRI a inod=3 it won't stop but continue. It will be just as if inod was 0 as in 2D "w" is not used. I do not know if there is some trick here but a more secure way to do this could be:
```cpp
blabla
switch(e->getType()) {
case mEntity::TET:
if (inod==3)
{
Upos = 0.0;Vpos = 0.0;Wpos = 1.0;
break;
}
case mEntity::TRI:
switch(inod){
case 0:
Upos = 0.0;Vpos = 0.0;Wpos = 0.0;break;
case 1:
Upos = 1.0;Vpos = 0.0;Wpos = 0.0;break;
case 2:
Upos = 0.0;Vpos = 1.0;Wpos = 0.0;break;
default: assert(0); throw; break;
}
break;
blabla
```
to be done if neededhttp://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/36Remove seq branch2019-12-11T15:54:57ZGrégory LEGRAINRemove seq branchHi,
the sequential branch was removed from DamageBand, if there is no opposition for this (**thumb-up** / **thumb-down**), I plan to remove the branch in Xfiles.Hi,
the sequential branch was removed from DamageBand, if there is no opposition for this (**thumb-up** / **thumb-down**), I plan to remove the branch in Xfiles.Grégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/35xDomainStringManager::getDomainId("zone")2020-05-15T13:19:38ZGilles MARCKMANNxDomainStringManager::getDomainId("zone")Potential Bug:
in xGeomElem, xDomainStringManager::getDomainId("zone") is used to manage and to get a tag (int) corresponding to the string "zone". This tag is used, after, in Trellis through the function getData(tag) which gives a mAtta...Potential Bug:
in xGeomElem, xDomainStringManager::getDomainId("zone") is used to manage and to get a tag (int) corresponding to the string "zone". This tag is used, after, in Trellis through the function getData(tag) which gives a mAttachableData (xDomainAttachableData).
The use of xDomainStringManager to manage the link between tags and strings may be in conflict with attachableDataIds of AOMD_Util::newMeshDataId which does the same thing: two different maps are used to manage tags of mAttachableData.
In fact, the bug never appears because the tag in xDomainStringManager:getDomainId("zone") is currently 0. This tag corresponds to a not-used tag of attachableDataIds. Note that the first tags declared in attachableDataIds of Trellis through AOMD_Util::newMeshDataId are :
* 0 <-> "_parametric"
* 1 <-> "_parent"
* 2 <-> "_fmod"
* 3 <-> "_emod"
* 4 <-> "_id"
* 5 <-> "_dn"
* 6 <-> "_size"
* 7 <-> "_ATT1"
* 8 <-> "_ATT2"
* 9 <-> "_ATT3"
* 10 <-> "_weight"
* 11 <-> "_mirror"
These tags are not used in Xfem, then 12 different domain names might be managed with xDomainStringManager before the bug appears.
This bug should nore affect applications which don't use MaterialManager (typically DamageBand which use xEval to manage materials).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/Xfiles/-/issues/33xDistVector Test2019-12-05T13:16:16ZAlexis SALZMANxDistVector TestSome new method are not tested in the atomic test: to be done
Some new friend functions may be optimizedSome new method are not tested in the atomic test: to be done
Some new friend functions may be optimizedParallel integrationhttp://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/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/30CMakeLists.txt of TTK2018-05-18T07:23:37ZGilles MARCKMANNCMakeLists.txt of TTKThe CMakeLists.txt of TTK must be updated to take into account modifications introduced by new_cmake.The CMakeLists.txt of TTK must be updated to take into account modifications introduced by new_cmake.Gilles MARCKMANNGilles MARCKMANNhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/29FindMETIS2018-05-18T07:23:37ZGilles MARCKMANNFindMETISFindMETIS still have a reference to FindMPI4 which has been removed. MPI should be defined in the main CMakeLists.txt.FindMETIS still have a reference to FindMPI4 which has been removed. MPI should be defined in the main CMakeLists.txt.Gilles MARCKMANNGilles MARCKMANNhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/28Find Blas22018-05-18T07:23:37ZGilles MARCKMANNFind Blas2With the use of function FindNoHeaderLibraries(), the find process give a FATAL ERROR (Blas REQUIED) if no BLAS_VENDOR is given and when default vendors give no results. So, default libblas.so can not be found.
May be the corrective is...With the use of function FindNoHeaderLibraries(), the find process give a FATAL ERROR (Blas REQUIED) if no BLAS_VENDOR is given and when default vendors give no results. So, default libblas.so can not be found.
May be the corrective is useless if we try to use the default findBlas of cmake.Gilles MARCKMANNGilles MARCKMANNhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/27test_ndiff.sh2020-04-01T13:07:31ZGilles MARCKMANNtest_ndiff.shXfiles/Util/cmakeUtil/test_ndiff.sh must be rewritten to be portable. The way to find the tool 'ndiff' is durty and hard coded for titan. It should not work on other platform as it is. The 'find 'command must be improved and a warning me...Xfiles/Util/cmakeUtil/test_ndiff.sh must be rewritten to be portable. The way to find the tool 'ndiff' is durty and hard coded for titan. It should not work on other platform as it is. The 'find 'command must be improved and a warning message should be written if 'ndiff' is not found. This bug may indicate that some ndiff_test passed while the test is not done in fact.Gilles MARCKMANNGilles MARCKMANNhttp://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.