Discussion about strain size for the case of PLANE STRAIN

[RiccardoRossi]

A decision must be taken about the strain size to be used in the case of PLANE strain. Mentioning explicitly @KratosMultiphysics/structural-mechanics but please anyone feel free to contribute to the conversation

The point is that AS OF NOW kratos is assuming that the strain is provided in voigt format and contains

eps_xx  eps_yy   2*eps_xy

This is done this way since by definition eps_zz=0 in the case of plane strain, and this allows the exact same kinematics for 2D structural elements in the case of plane stress and plane strain.

it exists however the option of using a size-4 strain vector of the type

eps_xx  eps_yy eps_zz  2*eps_xy

the interest of the second approach is in the context of quasi-incompressible elasticity. For example in a Q1P0 element, one could assume that eps_zz is not exactly zero on all of the gauss points and only zero in average. In a sense this second approach is completely equivalent to using a 3D law, in which the input strain is explicitly set as eps_yz=0 eps_xz=0 eps_zz=0 (approx).

My proposal is to keep the first definition and modify the B-bar element so that it always works with 3D constitutive laws. I would thus propose to make the first proposal the "official" standard.

Is there agreement on this? (i would appreciate thumbs up comments if you agree, and detailed answers if you don't)

[loumalouomega]

Well, I think that defining properly an enum which identifies the different options as STRESS_3D, PLANE_STRAIN_2D3Comp, PLANE_STRAIN_2D4Comp or somthing like that we can later implement the proper cases

[vryy]

👍 i would advocate to define size-4 strain vector as default in 2D

[frastellini]

I agree with size-3 strain vector for plane-stress and plane-strain cases, but we should use size-4 strain vector for axilsymmetric cases.

[marandra]

I agree too. I think this option is the less invasive. Also, we won't need to write and maintain a plane-strain version of the CL.

[RiccardoRossi]

I strongly think that we need to take a decision. plane strain should be either with size 3 or with size 4 consistently. I personally vouch for size 3, however if someone defends convincingly the size 4 option (which would imply a modified kinematics at the element level) i am open to taking that decision. @vryy what is your detailed reasoning behind your proposal (backward compatibility is not an argument here, since something would have to be broken in both cases)

About having the axysimmetric case of size 4 i completely agree (eps_circunferential is not zero). @loumalouomega i don't like having the two options (for plane strain) since then we will have a lot of incompatibilities (detected at Check time, but still incompatibilities) between elements and CLs

Just to resume, i put here the vote count as i understand it. Please edit my post and change as you need your voting. Also feel free to change it if the comments posted let you change idea. this is just to keep the count centralized (@loumalouomega i am not sure of what you vouch for... please add yourself)

PLANE STRAIN size 3 + AXISYMMETRIC @RiccardoRossi @marandra @frastellini @loumalouomega @AndreasWinterstein @philbucher @KlausBSautter

PLANE STRAIN size 4 @vryy

[loumalouomega]

I vote for 3 + Axi then (I updated your comment @RiccardoRossi )

[AndreasWinterstein]

I also vote for 3 + Axisymetric, since this is standard in literature and the user can clearly understand what the element does. Using the size 4 may be a bit confusing.

[vryy]

@RiccardoRossi my point is that for plane strain you still have have stress_zz and for plane stress you still have strain_zz. For post processing, and to compute the strain energy, error estimator, etc, you need those values. For plane strain, you can compute stress_zz = nu*(stress_xx+stress_yy) for linear elasticity but it's not going to be the case for plasticity. For plane stress plasticity you have to treat the zz component separately by introducing a constraint. In addition, the stiffness matrix is of size 4x4 (see de Souza Neto, Computational Plasticity, chap 9). Taking also into account the axisymmetric, having size-4 strain/stress generalizes all 2D cases and you don't have to make particular case/branching in the code. One of the reference plasticity code that I know (Hyplas) always uses size-4 strain size even for plane strain. Not to say that, you can use 3D code immediately for plane strain by just filtering out the xx, yy, xy, zz components of the vector, matrix, etc

[frastellini]

This is to support @vryy argument >>> 20_D_Array Notation for Computations with Tensors.pdf

[RiccardoRossi]

@vryy, i understand your argument, nevertheless the computation of eps_zz in plane stress or of sigma_zz in plane strain is purely a post process.

It can be obtained by a call to CL->CalculateValue

as needed once convergence is reached.

Also note that in the case of plasticity, eps_z_tot = 0 = eps_zz_elastic + eps_zz_plastic

the elastic and plastic parts are a implementation detail, but the element does not need to know them if not for output.

[KlausBSautter]

I agree with the fact that the out-of-plane entities are purely post-processing results and thus I also favour a size of 3

[RiccardoRossi]

@KlausBSautter i updated the comment

@vryy does my argument make sense to you?

taking the occasion to mention also @KratosMultiphysics/solid-mechanics

[vryy]

@RiccardoRossi that makes sense. But this is not my main argument. For plasticity you need a full size-4 strain. Nevertheless it can be avoided by reducing the 3D code. The question is that we promote generality or have to make enum/switches around to differentiate the cases?

[RiccardoRossi]

@vryy, i don't think you are right, in the sense that you may need to work internally to the CL with a strain vector of size 4 (or with full 3D CL) but this is not needed when interfacing with the element ([edit], i wrote CL where i should have written element). In this sense in my opinion it is better to consider this as an internal detail of the plastic law and not as a feature of the API

[AlejandroCornejo]

I think that the option with 3 components makes more sense... I vote for the · components version!

[AlejandroCornejo]

I have to study the details but in general cases we use 3 components... if we need 4 for special cases then we will make this distinction arent we? :)

[RiccardoRossi]

@AlejandroCornejo the point is to decide something and to stick to the decision... but we should really avoiding having SOME plane-strain cls to use 4 components and others to have 3

@vryy can u live with the solution we are telling here? if so i'll close this issue and consider it settled

[vryy]

@RiccardoRossi i have no problem closing it

[philbucher]

closing since we reached a consensus here

[RiccardoRossi]

coukd someone add it to the wiki? (page describing the CL interface)

[philbucher]

Someone of the Claw guys? @frastellini @AlejandroCornejo @marandra ?

[loumalouomega]

Duplicated with https://github.com/KratosMultiphysics/Kratos/issues/3690, can we close one of them?

[philbucher]

ping @CLaw guys

[loumalouomega]

Huuuuum, I think proposed solution is current one

[philbucher]

coukd someone add it to the wiki? (page describing the CL interface)

this has not been done yet I think?

[RiccardoRossi]

Hello everyone, we have had an intense discussion at the department about this issue (and #3690). As a result i think i am now convinced that we took the wrong design decision about this (i'll happily assume the blame and recognize that both @marandra and @Vahid-Galavi were defending the "correct" option). That is, that we should have decided using 4 components for the 2D plane strain instead of 3.

Let me try to resume the reasons for this change of orientation.

The first and most important is related to the implementation of assumed strain elements. In particular the B-bar element (or its Q1-P0 counterpart) work by _assuming that the strain epszz is 0 in average over the element, but not on each gauss point. This can only be achieved by allowing a nonzero eps_zz to be prescribed on the various gauss points, hence implying the need to allow a 4 components input. The reason such approach is needed of this is that when considering plastic CLs, the eps_zz=eps_zz_plastic + eps_zz_elastic and that the incompressible part of deformation is the plastic one and not the elastic one.

Other reasons for changing my mind is that people working on CLs ( @Vahid-Galavi , @thelfer here i mention you guys, so feel free to correct what i am telling) always use the 4 components approach, which means in the practice that is hard to justify a different approach to somone approaching for the first time Kratos.

[pooyan-dadvand]

@KratosMultiphysics/technical-committee would likes to know the opinion @KratosMultiphysics/implementation-committee about it.

[GuillermoCasas]

I find @RiccardoRossi 's summary of the reasons for going for the 4-variable approach reasonably convincing, especially when it seems this is common practice.

Nonetheless, I wonder why the plain-strain element derives from ElasticIsotropic3D. It seems there is no ElasticIsotropic2D counterpart, which is probably for some intelligent reason (sorry, know little about structural FEM). Nonetheless, it occurred to me that perhaps it would make sense to have that 2D element from which the different versions of the 2D elements could derive. Recently, the need for a zz-component of the stress arose for modelling a slice of a long probe that is being axially compressed (#6437), even if in reality a single extra DOF for the hole domain was necessary due to the symmetry of the problem. Here we see other cases were the need for that extra variable arises.

Thus, could it be that there is a need for a general 2d element from which it may be easy to include all the different varieties being discussed without having to generalise the present ones?

[AlejandroCornejo]

Hi, after reading all the comments I feel that the most general and polivalent option is to use the 4-component version. Another question is how to adapt the elements to take into account this new feature :)

[pooyan-dadvand]

@KratosMultiphysics/technical-committee agrees about using 4 components and would kindly ask @KratosMultiphysics/implementation-committee to follow the implementation of the required changes.