Material status and default implementations for Lattice1D and 2D

[Micket]

@githubgrasp Another issue where I would like your input:

Disclaimer: I'm not familiar with the theory behind lattice materials at all.

1. Can one make default implementations of the 1D and 2D methods in LatticeStructuralMaterial by calling the 3D methods? Just like how PlaneStrain does it.

2. The meaning of the "strain" and "stress" for these materials doesn't seems like they aren't actually stresses of strains, but rather some generalized measures of similar. As I'm working towards having fixed size arrays for everything, I would really like to keep the meaning behind these variables clear. Should we not just create a new LatticeStructuralMaterialStatus class where we can store these components (perhaps with more meaningful variable names than stress/strain)? It would also save it from storing some unnecessary fields related to large strains, so that's another saving.

This ties in to the first question; because with a default implementation, we get the full 3D state stored in the material status without hassle. It's also much less code to keep around. Especially with the fixed size math, just about everything gets inlined, so performance with fixed size arrays in the material status is actually typically much better in my experience.

[Micket]

Correction: It turns out that there is a LatticeMaterialStatus already that I somehow missed. But, I'm doubtful if it should inherit from StructuralMaterialStatus. I see only advantages if it directly inherited from MaterialStatus. I still suspect that it probably should rename some variables names (and be converted to fixed size arrays). Just so that it doesn't tie itself to structural materials to much; since it's really is it's own thing.

[githubgrasp]

In the literature people call it often stress and strain vectors. Maybe one could call it latticestress and latticestrain.

I have created a LatticeMaterialStatus and LatticeStructuralMaterial. Maybe the status should have been called LatticeStructuralMaterialStatus to be consistent. Anyway, the idea was to separate the lattice parts as much as possible from the rest to avoid confusion.

I have an open pull request from a few days ago and are waiting to get it accepted before I can make further changes.

Peter

On Mon, 25 Nov 2019 22:38 +00:00, Mikael Öhman notifications@github.com wrote:

@githubgrasp https://github.com/githubgrasp Another issue where I would like your input:

Disclaimer: I'm not familiar with the theory behind lattice materials at all.

1. Can one make default implementations of the 1D and 2D methods in LatticeStructuralMaterial by calling the 3D methods? Just like how PlaneStrain does it.

The meaning of the "strain" and "stress" for these materials doesn't seems like they aren't actually stresses of strains, but rather some generalized measures of similar. As I'm working towards having fixed size arrays for everything, I would really like to keep the meaning behind these variables clear. Should we not just create a new LatticeStructuralMaterialStatus class where we can store these components (perhaps with more meaningful variable names than stress/strain)? It would also save it from storing some unnecessary fields related to large strains, so that's another saving.

This ties in to the first question; because with a default implementation, we get the full 3D state stored in the material status without hassle. It's also much less code to keep around. Especially with the fixed size math, just about everything gets inlined, so performance with fixed size arrays in the material status is actually typically much better in my experience.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oofem/oofem/issues/64?email_source=notifications&email_token=AH35S3UJPEQBWPMPJI22SWLQVRHWVA5CNFSM4JRPXHV2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H36NLRQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH35S3TYJKBCEPQA7LYJWIDQVRHWVANCNFSM4JRPXHVQ.

[githubgrasp]

I agree that it should inherit directly from MaterialStatus.

On Mon, 25 Nov 2019 22:58 +00:00, Mikael Öhman notifications@github.com wrote:

Correction: It turns out that there is a LatticeMaterialStatus already that I somehow missed. But, I'm doubtful if it should inherit from StructuralMaterialStatus. I see only advantages if it directly inherited from MaterialStatus. I still suspect that it probably should rename some variables names (and be converted to fixed size arrays). Just so that it doesn't tie itself to structural materials to much; since it's really is it's own thing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oofem/oofem/issues/64?email_source=notifications&email_token=AH35S3SQYLXHSCOUO3OXOTDQVRKARA5CNFSM4JRPXHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFEC5JA#issuecomment-558378660, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH35S3TCM34VFI7IIO6HHE3QVRKARANCNFSM4JRPXHVQ.

[githubgrasp]

Thanks for merging the request. I will work on the mentioned improvements for the lattice models over the next days:

• I will let LatticeMaterialStatus directly inherit from Material status.
• I will also change the names of stresses and strains to be make clear that they different entities.
• All of this will be related to files in directories LatticeMaterials and LatticeElements.

[Micket]

I have worked over some of the code, making use of return channels, fixed size arrays.

I have 2 more concerns on the lattice materials:

1. LatticePlasticityDamageViscoelastic still overloads giveRealStressVector? This can't possibly work.

2. The materials are asking for additional element data; water pressure and element length. I'm trying to minimize (and, eventually actually eliminate) the gp->element callback from elements. It makes unit testing basically completely impossible, it requires gp to store additional pointers, wasting space 99% of the time.

We are not beholden to the interface "giveRealStressVector", but we can do whatever is the right thing. My policy is to "tell" dont "ask" when it comes to this. Why not include the water pressure + element length?

FloatArrayF<6> LatticeStructuralMaterial::giveLatticeStress3d(
        const FloatArrayF<6> &strain,
        double water_pressure,
        double element_length,
        GaussPoint *gp,
        TimeStep *tStep)

Alternatively, if possible, extract this part of the code, and handle this at the element level rather than inside the material. Either way, gp->giveElement() is a big code-smell for me.

[githubgrasp]

concerning 1), the viscoelastic extensions don't work anymore, but will be hopefully fixed by Petr Havlasek in the coming week. Petr had written those extensions in the older oofem version some years ago. I was not able to get them working anymore when I put the code into the current version. If possible, wait a few days concerning the viso lattice models. Much of it will then be most likely resolved.

Concerning 2), I will change this as you have suggested.

I am planning to introduce also all my tm lattice models. I can introduce again LatticeElements and LatticeMaterials directories in tm and try to mirror what we have in sm. Anything special to look out for?

On Sun, 01 Dec 2019 21:05 +00:00, Mikael Öhman notifications@github.com wrote:

I have worked over some of the code, making use of return channels, fixed size arrays.

I have 2 more concerns on the lattice materials:

1. LatticePlasticityDamageViscoelastic still overloads giveRealStressVector? This can't possibly work.

The materials are asking for additional element data; water pressure and element length. I'm trying to minimize (and, eventually actually eliminate) the gp->element callback from elements. It makes unit testing basically completely impossible, it requires gp to store additional pointers, wasting space 99% of the time.

We are not beholden to the interface "giveRealStressVector", but we can do whatever is the right thing. My policy is to "tell" dont "ask" when it comes to this. Why not include the water pressure + element length?

FloatArrayF<6> LatticeStructuralMaterial::giveLatticeStress3d( const FloatArrayF<6> &strain, double water_pressure, double element_length, GaussPoint *gp, TimeStep *tStep) Alternatively, if possible, extract this part of the code, and handle this at the element level rather than inside the material. Either way, gp->giveElement() is a big code-smell for me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oofem/oofem/issues/64?email_source=notifications&email_token=AH35S3QFAIGL6LRACFNQ2XDQWQRLHA5CNFSM4JRPXHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFRVSGY#issuecomment-560159003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH35S3WWYVUJY3HCMGZNVNDQWQRLHANCNFSM4JRPXHVQ.

[Micket]

Having basically gone through all the new code quite carefully now, I think I have a pretty firm grasp of the code (though, I'm not at all familiar with the lattice theory) I'm assuming the situation with lattice TM models are somewhatanalogous to the SM case.

There are two major things, which actually applies to the SM case as well:

1. I think your base class LatticeTransportMaterial should inherit directly from Material. Same for LatticeStructuralMaterial, as it shares no infrastructure at all with the rest of the SM/TM materials (zero interoperability). Shoehorning them into a shared class hierarchy just makes things awkward and brings little to no benefits. Better to just let lattice materials do exactly what they need naturally.

2. All methods with exception for the initialization, should be marked const. This is vital to ensure openmp parallelism, else we have a race-condition. Material class itself should not contain any state that changes when evaluating any material response. There are a few methods in SM lattice models that stored "returnResult" type variables. I think this is just to have a second return value, so it was stored in a (global) material variable? I think almost any other alternative is much more preferable.

Other than that, the usual stuff applies: Store full 3D state, use (iterative) default implementations for your 2d case, make use of fixed sized arrays. Also, you don't need to create additional subclasses for your material statuses unless you need to add more state.