feat: plastic strain output

[ryar9534]

Introducing a plasticStrain output field in addition to the current total strain. This is done by subtracting the elastic strain (obtained via the getElasticStrain method of the constitutive laws) from the total strain and averaging over quadrature points.

Rebaselining will be required because of the new field.

Ideally, plastic strain would only be output when a plasticity model is being used, but Im not sure how exactly we will do that...

I will run the Drucker-Prager and Modified Cam Clay wellbore problem to test

[ryar9534]

We must consider the behavior when the following are present:

• [ ] Nonzero initial stress (either prescribed or solved for)
• [ ] Nonzero initial displacements
• [ ] Boundary condition effects

[rrsettgast]

@ryar9534 Can you elaborate? Why do each of these things change the plastic strain calc?

We must consider the behavior when the following are present:

• [ ] Nonzero initial stress (either prescribed or solved for)

Is this concern because you have an initial stress in the plastic zone and you don't want to have that plastic strain as part of the reported value? I would think it still needs to be reported as it is the proper current state?

• [ ] Nonzero initial displacements

Is this concern that the initial state/strain and the displacement field are incompatible?

• [ ] Boundary condition effects

Could we just interpret this as "your BC's are a problem, please use better BC's or move the boundary."?

[ryar9534]

@ryar9534 Can you elaborate? Why do each of these things change the plastic strain calc?

We must consider the behavior when the following are present:

• [ ] Nonzero initial stress (either prescribed or solved for)

Is this concern because you have an initial stress in the plastic zone and you don't want to have that plastic strain as part of the reported value? I would think it still needs to be reported as it is the proper current state?

• [ ] Nonzero initial displacements

Is this concern that the initial state/strain and the displacement field are incompatible?

• [ ] Boundary condition effects

Could we just interpret this as "your BC's are a problem, please use better BC's or move the boundary."?

These were mostly notes to myself to make sure various cases worked as I am figuring things out. Basically the complexity is that the total strain we are outputting is referenced from the initial displacement, but the functions I am using to compute the elastic strain only know the stress. So I was seeing weird results where the two strains are sort of not compatible with one another, and thus you cant subtract them to get the plastic strain.

[rrsettgast]

These were mostly notes to myself to make sure various cases worked as I am figuring things out. Basically the complexity is that the total strain we are outputting is referenced from the initial displacement, but the functions I am using to compute the elastic strain only know the stress. So I was seeing weird results where the two strains are sort of not compatible with one another, and thus you cant subtract them to get the plastic strain.

Oh. Duh. Clearly that is a problem. So you would have to save the initial total strain/initial elastic strain or the initial stress. Nice thing is you could do this one quantity per element rather than per quadrature point.

[ryar9534]

I think this is ready to re-discuss. I think this would work, the only weird case is when the initial state has a plastic strain component., but Im not sure how often that occurs.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 10.65574% with 109 lines in your changes missing coverage. Please review.

Project coverage is 56.78%. Comparing base (adfefc3) to head (0ce3b32). Report is 74 commits behind head on develop.

Files with missing lines	Patch %	Lines
...mponents/constitutive/solid/ElasticOrthotropic.hpp	0.00%	22 Missing :warning:
.../constitutive/solid/ElasticTransverseIsotropic.hpp	0.00%	22 Missing :warning:
...tutive/solid/ElasticIsotropicPressureDependent.hpp	0.00%	21 Missing :warning:
...ers/solidMechanics/SolidMechanicsLagrangianFEM.cpp	0.00%	13 Missing :warning:
...icsSolvers/solidMechanics/kernels/StrainHelper.hpp	0.00%	13 Missing :warning:
...rc/coreComponents/constitutive/solid/SolidBase.hpp	0.00%	6 Missing :warning:
...olvers/solidMechanics/SolidMechanicsStateReset.cpp	0.00%	6 Missing :warning:
...Components/constitutive/solid/ElasticIsotropic.hpp	72.22%	5 Missing :warning:
...icsSolvers/solidMechanics/SolidMechanicsFields.hpp	0.00%	1 Missing :warning:

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3384      +/-   ##
===========================================
- Coverage    56.83%   56.78%   -0.06%     
===========================================
  Files         1154     1154              
  Lines        99954   100057     +103     
===========================================
+ Hits         56810    56817       +7     
- Misses       43144    43240      +96     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[FredericgB]

Hello, I cannot login to my github account , the two authentication steps failed every time. Can we set up a meeting for Friday late afternoon to discuss? Thanks Frederic

@.*** Frederic Bourgeois OneTech OT/R&D/SU/CCS/STO Geomechanics Manager TotalEnergies CSTJF Avenue Larribau, 64 018 - Pau cedex - France

From: Sy-Tuan Nguyen @.> Sent: Thursday, December 12, 2024 3:28 AM To: GEOS-DEV/GEOS @.> Cc: Frederic BOURGEOIS @.>; Review requested @.> Subject: Re: [GEOS-DEV/GEOS] feat: plastic strain output (PR #3384)

@sytuannguyen approved this pull request.

Reply to this email directly, view it on GitHubhttps://github.com/GEOS-DEV/GEOS/pull/3384#pullrequestreview-2497459023, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVFX4VREYPX4EC7742P5UPL2FDYB3AVCNFSM6AAAAABPJNBBH2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOJXGQ2TSMBSGM. You are receiving this because your review was requested.Message ID: @.@.>>

[ryar9534]

was this question resolved? ChatGPT says paraview expects tensorial strain...but I think it came to that conclusion because it calculates tensorial strain.

To me, it seems like it would be weird if paraview did operations to a tensor field, as IDK how it would know to do it for strain and not everything else. Thoughts @CusiniM ? I thought we were just gonna merge it

[paveltomin]

can someone check if new baselines are ok? i see things like that:

Error: /Problem/domain/MeshBodies/mesh1/meshLevels/Level0/ElementRegions/elementRegionsGroup/Domain/elementSubRegions/cb1/strain
	Arrays of types float64 and float64 have 378 values of which 63 fail both the relative and absolute tests.
		Max absolute difference is at index (np.int64(30), np.int64(5)): value = 7.644588483567542e-05, base_value = 0.00015289176967135085
		Max relative difference is at index (np.int64(30), np.int64(5)): value = 7.644588483567542e-05, base_value = 0.00015289176967135085
	Statistics of the q values greater than 1.0 defined by absolute tolerance: N = 63
		max = 7644.588483567542, mean = 124.862153686749, std = 711.8661761259043
		max is at index (np.int64(30), np.int64(5)), value = 7.644588483567542e-05, base_value = 0.00015289176967135085
	Statistics of the q values greater than 1.0 defined by relative tolerance: N = 0

is it because plastic part is separate now?

[jhuang2601]

can someone check if new baselines are ok? i see things like that:

Error: /Problem/domain/MeshBodies/mesh1/meshLevels/Level0/ElementRegions/elementRegionsGroup/Domain/elementSubRegions/cb1/strain
	Arrays of types float64 and float64 have 378 values of which 63 fail both the relative and absolute tests.
		Max absolute difference is at index (np.int64(30), np.int64(5)): value = 7.644588483567542e-05, base_value = 0.00015289176967135085
		Max relative difference is at index (np.int64(30), np.int64(5)): value = 7.644588483567542e-05, base_value = 0.00015289176967135085
	Statistics of the q values greater than 1.0 defined by absolute tolerance: N = 63
		max = 7644.588483567542, mean = 124.862153686749, std = 711.8661761259043
		max is at index (np.int64(30), np.int64(5)), value = 7.644588483567542e-05, base_value = 0.00015289176967135085
	Statistics of the q values greater than 1.0 defined by relative tolerance: N = 0

is it because plastic part is separate now?

Which case are you referring to? Plastic strain is registered as a new field (root cause for the failure) and the total strain is not touched in this PR.

[paveltomin]

is it because plastic part is separate now?

Which case are you referring to? Plastic strain is registered as a new field (root cause for the failure) and the total strain is not touched in this PR.

for example this

[ryar9534]

I did touch the total strain in this pr. We decided to divide the shear by 2 following discussions about engineering vs tensor strain. Hence the new baselines.

[joshua-white]

I did touch the total strain in this pr. We decided to divide the shear by 2 following discussions about engineering vs tensor strain. Hence the new baselines.

A large number of functions in the plasticity routine were written assuming engineering strains. I would definitely double check none of the physical results have changed before rebaselining anything. Would be very easy to make a mistake here. The error posted above has a factor of 2x in it, though, so that's encouraging.

[ryar9534]

Yes, all the computations seem to be done in engineering strain. @CusiniM and I decided to convert to tensor strain just for output.

[jhuang2601]

Yes, all the computations seem to be done in engineering strain. @CusiniM and I decided to convert to tensor strain just for output.

That sounds good. Let me rerun the tutorial plastic example with strain hardening to confirm it.

[jhuang2601]

I did touch the total strain in this pr. We decided to divide the shear by 2 following discussions about engineering vs tensor strain. Hence the new baselines.

A large number of functions in the plasticity routine were written assuming engineering strains. I would definitely double check none of the physical results have changed before rebaselining anything. Would be very easy to make a mistake here. The error posted above has a factor of 2x in it, though, so that's encouraging.

I can reproduce this tutorial example with the PR, which confirms that correct engineering strains are utilized by the Extended Drucker-Prager Model.