Adding field to output total strain #3142

ryar9534 · 2024-05-24T18:09:47Z

This PR adds registers total strain as a field within solid mechanics solvers so that it can be output to vtk. An incremental strain is updated when strain increments are computed within the quadrature point kernel, and these are added to the total stran at the end of the time step. We may want to rethink this once the new packing/data interface is in place.

I believe rebaselining will be needed as there is new output, but none of the results should change.

I also propose we have the TotalEnergies folks propose which constitutive laws they use most frequently and from which they would like elastic/plastic strain output as well, and that can be incrementally added.

An example output from my staircase runs which shows x displacement and the corresponding XX strain:

…umber of iterations

codecov · 2024-05-27T04:16:44Z

Codecov Report

Attention: Patch coverage is 0% with 41 lines in your changes missing coverage. Please review.

Project coverage is 55.68%. Comparing base (3bf12d2) to head (b3e928f).
Report is 97 commits behind head on develop.

Files with missing lines	Patch %	Lines
...icsSolvers/solidMechanics/kernels/StrainHelper.hpp	0.00%	28 Missing ⚠️
...ers/solidMechanics/SolidMechanicsLagrangianFEM.cpp	0.00%	12 Missing ⚠️
...icsSolvers/solidMechanics/SolidMechanicsFields.hpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3142      +/-   ##
===========================================
- Coverage    55.71%   55.68%   -0.03%     
===========================================
  Files         1031     1032       +1     
  Lines        87698    87739      +41     
===========================================
- Hits         48863    48861       -2     
- Misses       38835    38878      +43

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

…env in CI

CusiniM · 2024-06-06T08:17:27Z

...Components/physicsSolvers/multiphysics/poromechanicsKernels/MultiphasePoromechanics_impl.hpp

@@ -642,6 +642,15 @@ quadraturePointKernel( localIndex const k,
  LvArray::tensorOps::fill< 6 >( stack.strainIncrement, 0.0 );
  FE_TYPE::symmetricGradient( dNdX, stack.uhat_local, stack.strainIncrement );

+  for( int is = 0; is < 6; ++is )
+  {
+    if( q == 0 )


CusiniM · 2024-06-06T08:21:30Z

src/coreComponents/physicsSolvers/solidMechanics/SolidMechanicsFields.hpp

+               WRITE_AND_READ,
+               "Average strain in cell" );
+
+DECLARE_FIELD( incrementalStrain,


do we really need both of these fields? Isn't the strain enough?

CusiniM · 2024-06-06T08:24:10Z

src/coreComponents/physicsSolvers/solidMechanics/SolidMechanicsLagrangianFEM.cpp

+
+      solidMechanics::arrayView2dLayoutIncrStrain incStrain = subRegion.getField< solidMechanics::incrementalStrain >();
+      solidMechanics::arrayView2dLayoutStrain strain = subRegion.getField< solidMechanics::strain >();
+      for( localIndex k = 0; k < subRegion.size(); ++k )


This should be a raja loop.

CusiniM · 2024-06-06T08:28:13Z

src/coreComponents/physicsSolvers/solidMechanics/SolidMechanicsLagrangianFEM.cpp

+      solidMechanics::arrayView2dLayoutIncrStrain incStrain = subRegion.getField< solidMechanics::incrementalStrain >();
+      incStrain.zero();


Suggested change

solidMechanics::arrayView2dLayoutIncrStrain incStrain = subRegion.getField< solidMechanics::incrementalStrain >();

incStrain.zero();

subRegion.getField< solidMechanics::incrementalStrain >().zero();

if you are setting it to zero here I am not sure I see the point of that if (q == 0). I also think that this means that the field will always be zero when we plot it so I would only store the strain and not the incremental one.

CusiniM · 2024-06-06T08:32:05Z

...coreComponents/physicsSolvers/solidMechanics/kernels/FixedStressThermoPoromechanics_impl.hpp

@@ -133,6 +135,14 @@ quadraturePointKernel( localIndex const k,

  FE_TYPE::symmetricGradient( dNdX, stack.uhat_local, strainInc );

+  for( int is = 0; is < 6; ++is )
+  {
+    if( q == 0 )


see previous comment.

CusiniM · 2024-06-06T08:32:46Z

...coreComponents/physicsSolvers/solidMechanics/kernels/ImplicitSmallStrainQuasiStatic_impl.hpp

+  for( int is = 0; is < 6; ++is )
+  {
+    if( q == 0 )
+    {
+      m_incStrain[k][is] = 0.0;
+    }
+    m_incStrain[k][is] += strainInc[is]*detJxW/m_elementVolume[k];


same code seems to be repeated a few times.

I agree - Is there a place you would recommend placing a function which does the strain tracking? Its seems like a lot of the quadrature point kernel is kind of repeated in the various places it is used.

ryar9534 · 2024-06-06T16:37:54Z

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

CusiniM · 2024-06-10T22:38:10Z

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

Hmm, if instead of using u_hat, we use u don't we get directly the total strain? At that point there is no need to store the incremental one.

CusiniM · 2024-06-10T22:43:27Z

Thanks for the review @CusiniM . You picked up on the things I was hoping to ask about. In particular, the need for both incremental strain and total strain, and the zeroing I have to do - It seemed to me that the strainInc used in the quadraturePointKernel is an increment from the previous converged time step to the current state, so I don't think you can just sum all of the increments across newton iterations, if that makes sense. I think if you dont do the zeroing in the quadrature point kernel then the results directly depend on the number of newton iterations, or at least thats what I saw during testing. I think a separate variable for the increment is needed for a similar reason, but perhaps we can think of something more clever.

Hmm, if instead of using u_hat, we use u don't we get directly the total strain? At that point there is no need to store the incremental one.

I am also still not entirely convinced that it's not worth it to launch a simpler kernel just for this computation at the end of the timestep instead of trying to combine it with the assembly. I think we would only need to dispatch on the elem type since all we need is to know how to perform the interpolation and the integration and we don't care about the constitutive type (I think).

…S-DEV/GEOS into feature/aronson/strainOutput

ryar9534 · 2024-06-20T20:25:46Z

@CusiniM Should be good to go now if youd like to take a look.

Ryan Aronson added 4 commits May 23, 2024 21:03

initial implementation, need to debug compilation error

d88b619

added template

bdfe7cc

fixed const related compilation bug

4f53873

added implementation for fim poromechanics, need to figure out seq

d0f53c5

ryar9534 self-assigned this May 26, 2024

ryar9534 added type: feature New feature or request flag: ready for review flag: requires rebaseline Requires rebaseline branch in integratedTests ci: run integrated tests Allows to run the integrated tests in GEOS CI labels May 26, 2024

Ryan Aronson added 2 commits May 26, 2024 16:03

added seq poromechanics implementation, seems to be a dependence on n…

2368536

…umber of iterations

hack to zero increment at every new newton step

ec37409

ryar9534 marked this pull request as ready for review May 27, 2024 02:39

ryar9534 requested review from rrsettgast, castelletto1, CusiniM and paveltomin May 27, 2024 02:40

Merge branch 'develop' into feature/aronson/strainOutput

ffa5456

paveltomin approved these changes May 28, 2024

View reviewed changes

ryar9534 added 3 commits May 28, 2024 11:53

remove template which was probably causing compilation error for one …

324f5da

…env in CI

zero strain during poromechanics initialization

3737cb2

uncrustify

1781249

ryar9534 added the ci: run CUDA builds Allows to triggers (costly) CUDA jobs label May 28, 2024

documentation

fd1d17a

CusiniM reviewed Jun 6, 2024

View reviewed changes

Added 2d averaging kernel

5599af2

ryar9534 removed ci: run CUDA builds Allows to triggers (costly) CUDA jobs ci: run integrated tests Allows to run the integrated tests in GEOS CI labels Jun 18, 2024

ryar9534 added 3 commits June 17, 2024 20:21

prototype kernel formulation for linear elasticity

7326339

complete refector

d20260b

fix misc white space changes

8cb4800

ryar9534 added ci: run CUDA builds Allows to triggers (costly) CUDA jobs ci: run integrated tests Allows to run the integrated tests in GEOS CI labels Jun 20, 2024

ryar9534 added 3 commits June 20, 2024 11:59

Merge branch 'develop' into feature/aronson/strainOutput

0255567

uncrustify

b33ab2d

Merge branch 'feature/aronson/strainOutput' of https://github.com/GEO…

0956ef2

…S-DEV/GEOS into feature/aronson/strainOutput

ryar9534 added 6 commits June 20, 2024 14:51

try to fix cuda compile error

4181f6c

try to fix cuda compile error

04319db

try to fix cuda compile error

f10de97

uncrustify

ebdd3cb

Update .integrated_tests.yaml

40e307c

Update BASELINE_NOTES.md

b3e928f

CusiniM merged commit d6b6e0b into develop Jun 21, 2024
24 of 26 checks passed

CusiniM deleted the feature/aronson/strainOutput branch June 21, 2024 03:36

Algiane pushed a commit that referenced this pull request Jun 21, 2024

Adding field to output total strain (#3142)

0ac399c

ryar9534 mentioned this pull request Jul 4, 2024

Elastic/Plastic strain outputs in GEOS #3210

Closed

ryar9534 linked an issue Jul 4, 2024 that may be closed by this pull request

Elastic/Plastic strain outputs in GEOS #3210

Closed

Algiane pushed a commit that referenced this pull request Jul 30, 2024

Adding field to output total strain (#3142)

b1333e2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding field to output total strain #3142

Adding field to output total strain #3142

ryar9534 commented May 24, 2024 •

edited

Loading

codecov bot commented May 27, 2024 •

edited

Loading

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

CusiniM Jun 6, 2024

ryar9534 Jun 6, 2024 •

edited

Loading

ryar9534 commented Jun 6, 2024

CusiniM commented Jun 10, 2024

CusiniM commented Jun 10, 2024 •

edited

Loading

ryar9534 commented Jun 20, 2024

		solidMechanics::arrayView2dLayoutIncrStrain incStrain = subRegion.getField< solidMechanics::incrementalStrain >();
		incStrain.zero();

	solidMechanics::arrayView2dLayoutIncrStrain incStrain = subRegion.getField< solidMechanics::incrementalStrain >();
	incStrain.zero();
	subRegion.getField< solidMechanics::incrementalStrain >().zero();

Adding field to output total strain #3142

Adding field to output total strain #3142

Conversation

ryar9534 commented May 24, 2024 • edited Loading

codecov bot commented May 27, 2024 • edited Loading

Codecov Report

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

CusiniM Jun 6, 2024

Choose a reason for hiding this comment

ryar9534 Jun 6, 2024 • edited Loading

Choose a reason for hiding this comment

ryar9534 commented Jun 6, 2024

CusiniM commented Jun 10, 2024

CusiniM commented Jun 10, 2024 • edited Loading

ryar9534 commented Jun 20, 2024

ryar9534 commented May 24, 2024 •

edited

Loading

codecov bot commented May 27, 2024 •

edited

Loading

ryar9534 Jun 6, 2024 •

edited

Loading

CusiniM commented Jun 10, 2024 •

edited

Loading