Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: plastic strain output #3384

Merged
merged 61 commits into from
Jan 7, 2025
Merged

Conversation

ryar9534
Copy link
Contributor

@ryar9534 ryar9534 commented Oct 3, 2024

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 ryar9534 self-assigned this Oct 3, 2024
@ryar9534 ryar9534 marked this pull request as ready for review October 3, 2024 11:46
@ryar9534 ryar9534 linked an issue Oct 3, 2024 that may be closed by this pull request
@ryar9534 ryar9534 added the ci: run CUDA builds Allows to triggers (costly) CUDA jobs label Oct 3, 2024
Copy link
Member

@rrsettgast rrsettgast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want full tensorial plastic strain, or eps?

Copy link
Member

@rrsettgast rrsettgast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just thinking that the total and incremental calculations are the same except for the stress inputs. These could be put into a private function so that the calculation is only done in one place.

@@ -135,6 +135,11 @@ class ElasticIsotropicUpdates : public SolidBaseUpdates
localIndex const q,
real64 ( &elasticStrain )[6] ) const override final;

GEOS_HOST_DEVICE
virtual void getElasticStrainInc( localIndex const k,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
virtual void getElasticStrainInc( localIndex const k,
virtual void calculateElasticStrainInc( localIndex const k,

Since this isn't really a "getter"

@@ -228,6 +233,23 @@ void ElasticIsotropicUpdates::getElasticStrain( localIndex const k,
elasticStrain[5] = m_newStress[k][q][5] / m_shearModulus[k];
}

GEOS_HOST_DEVICE
inline
void ElasticIsotropicUpdates::getElasticStrainInc( localIndex const k,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
void ElasticIsotropicUpdates::getElasticStrainInc( localIndex const k,
void ElasticIsotropicUpdates::calculateElasticStrainInc( localIndex const k,

elasticStrainInc[1] = (-nu*(m_newStress[k][q][0] - m_oldStress[k][q][0]) + (m_newStress[k][q][1] - m_oldStress[k][q][1]) - nu*(m_newStress[k][q][2] - m_oldStress[k][q][2]))/E;
elasticStrainInc[2] = (-nu*(m_newStress[k][q][0] - m_oldStress[k][q][0]) - nu*(m_newStress[k][q][1] - m_oldStress[k][q][1]) + (m_newStress[k][q][2] - m_oldStress[k][q][2]))/E;

elasticStrainInc[3] = (m_newStress[k][q][3] - m_oldStress[k][q][3]) / m_shearModulus[k];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ryar9534
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
image

@ryar9534
Copy link
Contributor Author

ryar9534 commented Jan 7, 2025

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
Copy link
Contributor

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
Copy link
Contributor Author

ryar9534 commented Jan 7, 2025

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

@jhuang2601
Copy link
Contributor

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
Copy link
Contributor

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.

@paveltomin paveltomin merged commit a8a57c7 into develop Jan 7, 2025
23 of 25 checks passed
@paveltomin paveltomin deleted the feature/aronson/plasticStrainOutput branch January 7, 2025 22:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci: run code coverage enables running of the code coverage CI jobs ci: run CUDA builds Allows to triggers (costly) CUDA jobs ci: run integrated tests Allows to run the integrated tests in GEOS CI flag: ready for review flag: requires rebaseline Requires rebaseline branch in integratedTests type: feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Elastic/Plastic strain outputs in GEOS
8 participants