• From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Topic: Problem with partest_barnl (known cause)

I had missed that partest_barnl broke when i made some changes a while ago.
The offending change was that of material status being stored by material number instead of material classtype.
This change is still something I consider an actual bugfix; Two different materials should never share a material status.
However, this seems to have been the case in partest_barnl, which uses idm1 (IsotropicDamageMaterial1).

I'm not convinced that anything is actaully wrong, especially since the difference is small (and considering the CALM used the load levels happens to be a bit higher, it is very hard to tell by looking at the results).

This is just a heads up, I will continue digging around, but if anyone happens to know more specifics about how these nonlocal materials (which i think is the problem) work, then please let me know.

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Problem with partest_barnl (known cause)

I managed to find the problem, and it comes from the nonlocal model.
In the barnl test case, only a small numerical imperfection was added to the second model (to offset symmetry), so in this case it is acceptable for the smoothing to use material statuses from different materials.
However, In general, I don't think this is a good idea.
NonlocalMaterialExtensionInterface :: buildNonlocalPointTable(GaussPoint *gp)
should probably not list neighboring gausspoints which have a different material.

  • milan
  • OOFEM developer
  • Offline
  • Registered: 02-02-2010
  • Posts: 14

Re: Problem with partest_barnl (known cause)

The question of nonlocal interaction between different materials is a tricky one. The cleanest solution would be to specify (in the input file) for each nonlocal material from which other materials it should receive information when computing nonlocal averages. In some cases, it makes sense to use nonlocal interaction even between two materials of a different kind. For instance, if I expect a large region in a concrete block to remain elastic, I can use the IsoLE material for those elements but the nonlocal material in other elements (say the idmnl1 material) can take into account the strains in the elastic material because physically it is the same concrete. So this additional option could be implemented, if somebody has time. But the additional parameters should be optional, to make sure that our existing input files will lead to the same results as before.

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Problem with partest_barnl (known cause)

As far as I can see, idmnl1 requires all the neighboring points to be of the same material type (as it averages an internal variable which is only available in idmnl1).

    for ( pos = list->begin(); pos != list->end(); ++pos ) {
        GaussPoint *gp = pos->nearGp;
        nonlocStatus = static_cast< IDNLMaterialStatus * >( gp->giveMaterialStatus( gp->giveMaterial()->giveNumber() ) );
        nonlocalContribution = nonlocStatus->giveLocalEquivalentStrainForAverage();
...

If the code above is used for any case where the neighboring point isn't of the same type (say some elastic material), it will simple crash.

If this function

    virtual double IDNLMaterialStatus :: giveLocalEquivalentStrainForAverage()

could be generalized and placed in the base material status class, e.g.

    virtual double StructuralMaterialStatus :: giveLocalEquivalentStrainForAverage();

then one wouldn't have to do an unsafe "static_cast< IDNLMaterialStatus *>" to average the strain, and the averaging could use all surrounding gausspoints.
It this possible? I.e. is the equivalent strain well defined for an elastic material? Does it make sense to have a giveLocalEquivalentStrainForAverage() in the base class?

I'm trying to piece this together out of context, but I barely know anything about the theory. Looking throgh "IsotropicDamageMaterial1 :: computeEquivalentStrain" it seems that should be possible to move this into StructuralMaterialStatus, which would solve all these issues.

5 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: Problem with partest_barnl (known cause)

the quantity to be averaged depends in general on material model. It could be a scalar or tensor value to be averaged, and also the physical type can vary. So moving computeEquivalentStrain to base class does not solve any problem.
In general, some models may average quantity, that should be defined by all (at least structural) models, like a strain vector, or its measure. However, some may average quantity that is defined only by specific class of models (like a plastic strain, etc).

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Problem with partest_barnl (known cause)

So there are a few different scenarios;
1. Neighboring GP is of the exact same material - No problems.
2. Neighboring GP is of a different material (like an elastic region) - No choice but to ignore those points.
3. Neighboring GP is of the same material type, but with different parameters

It was specifically case 3 that caused problems here. I'm not sure that it makes sense to average values over different material models, even if they are of the same type.

(the exception to this are quantaties like the strain vector, which can be averaged over any model).