eXlibris issueshttp://git.gem.ec-nantes.fr/groups/eXlibris/-/issues2018-05-29T07:28:35Zhttp://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/Xtest/-/issues/2Transfert test from xfem-seq-test to xfem-para-test2018-10-17T01:39:25ZAlexis SALZMANTransfert test from xfem-seq-test to xfem-para-testParallel integrationhttp://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/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/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/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/18xDistVector2019-12-05T13:12:23ZAlexis SALZMANxDistVectorWhen reading from double manager into a xDistVector instance value are globlal (except if you store in your double manager local information only which is highly discouraged). Some new method should then be created to switch to local mod...When reading from double manager into a xDistVector instance value are globlal (except if you store in your double manager local information only which is highly discouraged). Some new method should then be created to switch to local mode keeping the fact that information are in global mode. Otherwise many algebraic operation will be wrong ... If instance is only use as a buffer to write again in a double manager there is not problem thought. Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/17gemv with xDistVector2019-12-02T11:56:07ZAlexis SALZMANgemv with xDistVectorgemv methode of xGenericSparseMatrix must be overloaded to be used with xDistVector:
Product of a local contribution of a sparce matrix by a local contribution of a distributed vector. The local sparce matrix must include at least the...gemv methode of xGenericSparseMatrix must be overloaded to be used with xDistVector:
Product of a local contribution of a sparce matrix by a local contribution of a distributed vector. The local sparce matrix must include at least the local contribution set of the distributed vector.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/Xfiles/-/issues/12xLevelSetOperators2018-05-18T07:23:38ZAlexis SALZMANxLevelSetOperatorsFor xFitToVertices an old version of exchange was done. It realy on AOMD exchanger via xExchangeBool in xParallel.
@nchevaugeon is it worth the try to modify this tool chain and add at the very last end a new exchanger from eXlibristool...For xFitToVertices an old version of exchange was done. It realy on AOMD exchanger via xExchangeBool in xParallel.
@nchevaugeon is it worth the try to modify this tool chain and add at the very last end a new exchanger from eXlibristool or just remove every things and add a new exchanger in xLevelset class ?
Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/9Fast marching2019-03-01T08:16:34ZAlexis SALZMANFast marchingpass in parallelpass in parallelParallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/8Remove PARDIST/PARSEQ/PARALEL2018-09-07T11:43:49ZAlexis SALZMANRemove PARDIST/PARSEQ/PARALELRemove those compiler macro definition.
For AOMD put special guard to avoid usage of this library in parallelRemove those compiler macro definition.
For AOMD put special guard to avoid usage of this library in parallelParallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/7Guard2018-09-07T13:20:35ZAlexis SALZMANGuardSet guard on every point where parallel is an issue.
See commit 282fdb3Set guard on every point where parallel is an issue.
See commit 282fdb3Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/6xSubmesh2018-09-07T11:39:13ZAlexis SALZMANxSubmeshpass it in new parralel environementpass it in new parralel environementParallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/5xLevelset2018-09-07T11:39:13ZAlexis SALZMANxLevelsetIt have to be treated
A first guard have been set for gradiant computationIt have to be treated
A first guard have been set for gradiant computationParallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/4xData2018-09-07T11:39:13ZAlexis SALZMANxDataIn xData when reading mesh things are :
<ul><li>if sequential name corespond to a file, proc O read this files and the others do nothing</li>
<li>if sequential name does not corespond to any files, distributed name is tried. The idear ...In xData when reading mesh things are :
<ul><li>if sequential name corespond to a file, proc O read this files and the others do nothing</li>
<li>if sequential name does not corespond to any files, distributed name is tried. The idear is then that if no file correspond for a proc, an empty mesh is created.
In this way a mesh distributed on 3 files will potentially be read by 3 proc only, the others proc simply creating empty mesh. Loadbalancing planned to equilibrate mesh on all proc aftewards.</li>
</ul>
The problem is that case with no mesh for all proc is not covered. TODO.
A global flag communication is simple (if on all proc flag is null there is problem) but is there somting smarter ?? Parallel integrationhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/3NOTHING in solverinterface cmakefile2018-05-18T07:23:38ZAlexis SALZMANNOTHING in solverinterface cmakefilesee comment in your commit for this filesee comment in your commit for this fileParallel integrationGrégory LEGRAINGrégory LEGRAINhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/2xPhysSurfByTaging2018-09-07T11:39:13ZAlexis SALZMANxPhysSurfByTagingFinish parallel.
Work fine for now with mecanical test case but does not work with functional.
entity tag prb
Finish parallel.
Work fine for now with mecanical test case but does not work with functional.
entity tag prb
Parallel integrationAlexis SALZMANAlexis SALZMANhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/1Choose the right place for xAttachedDataManagerAOMD.h2018-05-18T07:23:38ZAlexis SALZMANChoose the right place for xAttachedDataManagerAOMD.hFor now it is in distmesh which is not its normal place.
In xFem ??? it is used all around and this will add unasacery depencies.
In eXlibris tools ?? no eXlibris tools do not depend on AOMD and we have to preserve this situation.
N....For now it is in distmesh which is not its normal place.
In xFem ??? it is used all around and this will add unasacery depencies.
In eXlibris tools ?? no eXlibris tools do not depend on AOMD and we have to preserve this situation.
N.C. suggest AOMInterface ?
In any case almost all cmake are now forced to used a find DISTMESH for that !!!! Parallel integration