eXlibris issueshttp://git.gem.ec-nantes.fr/groups/eXlibris/-/issues2020-02-10T16:12:44Zhttp://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/62bugg in update methode of xPhysSurfCut2020-02-10T16:12:44ZAlexis SALZMANbugg in update methode of xPhysSurfCutWhen close node treatment involve several element all null iso-edge points to the close node for upper "creator". Then close node points to one of those elements.
When updating an iso that rotate around this close node treatment the cl...When close node treatment involve several element all null iso-edge points to the close node for upper "creator". Then close node points to one of those elements.
When updating an iso that rotate around this close node treatment the cleanAroundEdge if called with one edge not anymore cut, will destroy this last link. And if among the remaining element one is not topologicaly new there will be a problem as this link from close node points to one of those elements is broken and not re-created. It is a bug.
It has been discovered by B.L. with iso that move slowly.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/59Upgrade compiler on titan2020-02-04T10:22:15ZGrégory LEGRAINUpgrade compiler on titanWe should investigate to upgrade the compiler on titan. gcc 4.8 is quite old.
This leads to some limitations during template deduction. The code is thus less compact as we have to help the compiler to figure out what is going on (see `De...We should investigate to upgrade the compiler on titan. gcc 4.8 is quite old.
This leads to some limitations during template deduction. The code is thus less compact as we have to help the compiler to figure out what is going on (see `DeclareInterpolation<xField<valtype> >` and `DeclareState<xField<valtype> >` where the template parameter could be removed with more recent versions of gcc).http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/57dependencies of xfem on xcut2019-12-20T16:57:04ZNicolas CHEVAUGEONdependencies of xfem on xcutActually xfem depends on xcut and vice versa. I propose to change that.
I checked, it's possible with a few changes.
Most of the dependencies are through constructor of enriched shape function that take an xPhysSurf as an input.
In fact,...Actually xfem depends on xcut and vice versa. I propose to change that.
I checked, it's possible with a few changes.
Most of the dependencies are through constructor of enriched shape function that take an xPhysSurf as an input.
In fact, thoses constructor only use the xPhysSurf to call the member getLevelSet(). The exaxt same object can already be constructed by passing directly the level-set to them.
I propose to remove this constructor.
The above done, there is one other dependencies in xValue.h/cc the xValueCreatorRampedHeaviside family of class have constructor that rely heavily on the xPhysSurbyTagging interface.
After discussion with Alexis, This functionality is only use for tls, so this class can be moved to xTLS.
I propose do do it. I already started, It works. It's not pushed yet because of some problem on titan at the time I'm writing this.http://git.gem.ec-nantes.fr/eXlibris/Xfiles/-/issues/51xPhysSurfVLS2019-12-12T08:20:48ZGilles MARCKMANNxPhysSurfVLSThe class definition/implementation of xPhysSurfVLS are in xFEM/src/xVectorLevelSet.h/cc:
- It should be in xCut but where exactly ??
- It should also be attic but some xTLS functions still depend on this class.The class definition/implementation of xPhysSurfVLS are in xFEM/src/xVectorLevelSet.h/cc:
- It should be in xCut but where exactly ??
- It should also be attic but some xTLS functions still depend on this class.http://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/20Code factorisation for mesh adaptation strategies2018-09-11T14:40:53ZGrégory LEGRAINCode factorisation for mesh adaptation strategiesWe could try to think about factorizing the code for the strategies
involving mesh adaptation (DamageGrowthOctree / DamageGrowthAniso), as
they share quite strong similarities.We could try to think about factorizing the code for the strategies
involving mesh adaptation (DamageGrowthOctree / DamageGrowthAniso), as
they share quite strong similarities.Benoît LÉBenoît LÉhttp://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/43Présentation d'une proposition de nouvelle interface maillage dans XfeM2019-03-07T16:38:29ZNicolas MOËSPrésentation d'une proposition de nouvelle interface maillage dans XfeMGilles MARCKMANNGilles MARCKMANN2018-09-18http://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/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/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/XTLS/TLSImplicit/-/issues/17Remove sequential branch ?2018-05-18T07:12:52ZGrégory LEGRAINRemove sequential branch ?Hi guys (and girls !),
I was wondering whether we should keep the sequential branches in Xfiles and TTK.
Indeed, I think that nobody used them for ages. At the beginning, they were created so that Cenaero can run the code while we where ...Hi guys (and girls !),
I was wondering whether we should keep the sequential branches in Xfiles and TTK.
Indeed, I think that nobody used them for ages. At the beginning, they were created so that Cenaero can run the code while we where working on the parallel version. It seems that now everybody uses master.
**So the question is** : should I delete this branch ?
* If you **agree**: log into git.gem, open the issue and **thumb-up**
* If you **disagree**: log into git.gem, open the issue and **thumb-down**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/XTLS/TLSImplicit/-/issues/16test2018-04-23T13:25:51ZGrégory LEGRAINtesttesttesthttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/14Numerical diffusion when computing non local fields with Fast Marching modes2018-12-21T09:41:59ZBenoît LÉNumerical diffusion when computing non local fields with Fast Marching modesFor now, numerical diffusion is available only with the Lagrangian method, to be comitted with Fast Marching modesFor now, numerical diffusion is available only with the Lagrangian method, to be comitted with Fast Marching modesBenoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/11For the couple(use_enriched, tls_geom_interface), have 3 predefined model and...2018-05-22T16:17:03ZNicolas MOËSFor the couple(use_enriched, tls_geom_interface), have 3 predefined model and one customHow it is currently done:
For now, some verifications are done.
How it should be done:
TODO:
• Removed old historical versions ?
• Automatized some choices (for instance, from what was presented above, the choice of tls_geom_interface se...How it is currently done:
For now, some verifications are done.
How it should be done:
TODO:
• Removed old historical versions ?
• Automatized some choices (for instance, from what was presented above, the choice of tls_geom_interface seems to impose the choice of use_enrichment)Benoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/10Search for initiation must use the Yc defined by the softening function.2018-07-19T06:35:08ZNicolas MOËSSearch for initiation must use the Yc defined by the softening function.How it is currently done:
For now Yc is computed automatically in the evaluator used to compute Yc, so the Yc given in the damageinfo.dat file, which is used for the search for initiations, is not consistent with the one used to compute ...How it is currently done:
For now Yc is computed automatically in the evaluator used to compute Yc, so the Yc given in the damageinfo.dat file, which is used for the search for initiations, is not consistent with the one used to compute Yc.
How it should be done:
• Modify searchForInitiations() to automatically get the appropriate value
• In xEvalHardeningYcCZM: check consistency between Yc and the one computed from CZM equivalenceBenoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/9Retrait de compute_elastic des choix matériaux et création de MaterialEval2018-07-19T06:35:07ZNicolas MOËSRetrait de compute_elastic des choix matériaux et création de MaterialEvalMaterialEval will give evaluators and their types for stress, pre-stress, tangent matrix, elastic matrix, Softening function, ...
Compute_elastic will now have only one template parameter : EvalMaterial
Template arguments will nom be in...MaterialEval will give evaluators and their types for stress, pre-stress, tangent matrix, elastic matrix, Softening function, ...
Compute_elastic will now have only one template parameter : EvalMaterial
Template arguments will nom be in MaterialEval and no longer in compute_elastic
How it is currently done for the softening function
For now, only constant softening and CZM equivalent softening functions are available.
How it should be done:
Add user defined softening function. Two possibilities:
• The durable way: if the new softening function is supposed to be kept and reuse by other users, add it into the sources as it was done for the CZM equivalence
• To do some tests: define a softening function in the main.cc/h , give it to the code, implement a xEval which uses this functionBenoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/8The Young modulus for the H_CZM must be given by the user and check value lambda2018-04-26T08:04:21ZNicolas MOËSThe Young modulus for the H_CZM must be given by the user and check value lambdaHow it is currently done:
For now, some verification are done (for the CZM equivalence, the choice of the CZM profile is checked, as well as for the choice of the propagation algorithm).
How it should be done:
• Could be improved to c...How it is currently done:
For now, some verification are done (for the CZM equivalence, the choice of the CZM profile is checked, as well as for the choice of the propagation algorithm).
How it should be done:
• Could be improved to check the parameters ranges (not only for CZM, but maybe at some other places in the code).
• In xEvalHardeningYcCZM: E has to be evaluated at each call, very annoying/time consuming ???Benoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/7Allow the user to choose the policy for initiations2018-09-11T14:18:50ZNicolas MOËSAllow the user to choose the policy for initiationsHow it is currently done:
For now, whenever a search for initiations is performed, only one damaged zone is introduced where max(Y ) > Yc, even if there may be several points for which Y > Yc
How it should be done:
Add small damaged zone...How it is currently done:
For now, whenever a search for initiations is performed, only one damaged zone is introduced where max(Y ) > Yc, even if there may be several points for which Y > Yc
How it should be done:
Add small damaged zone at each point where Y > Yc ? May not necessarily be a good idea, to be discussed ...Benoît LÉBenoît LÉhttp://git.gem.ec-nantes.fr/eXlibris/XTLS/TLSImplicit/-/issues/6Possibility for the user to choose the Force displacement export file name2018-05-04T08:55:28ZNicolas MOËSPossibility for the user to choose the Force displacement export file nameHow it is currently done:
For now, the load, displacement, etc exported by the curve writer are written in a file named forceouverture.txt . This name is imposed.
How it should be done:
Add an optional parameter to eventually export thes...How it is currently done:
For now, the load, displacement, etc exported by the curve writer are written in a file named forceouverture.txt . This name is imposed.
How it should be done:
Add an optional parameter to eventually export these quantities in a file with a user defined name (but keep the forceouverture.txt name by default if the user does not mind about this file name).Benoît LÉBenoît LÉ