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.

Sign up for GitHub

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

Jump to bottom

[GeoMechanicsApplication] Standard K0 procedure for 3D #12336

Open
rfaasse opened this issue May 1, 2024 · 3 comments · May be fixed by #12850
Open

[GeoMechanicsApplication] Standard K0 procedure for 3D #12336

rfaasse opened this issue May 1, 2024 · 3 comments · May be fixed by #12850
Assignees
@markelov208

Comments

@rfaasse
Copy link
Contributor

rfaasse commented May 1, 2024 •
edited
Loading

As a Kratos user, I would like to be able to use the standard K0 procedure for 3D linear elastic materials, such that I have results that are closely comparable to competitive software.

Required for 3D soil structure interaction

Predecessor: #12396

Acceptance Criteria
Given a user runs a K0 stage in 3D
When the user does not specify anything about the standard procedure
Then the standard procedure (which is already available in 2D) is used

Given a user runs a K0 stage in 3D
When the user specifies the "use_standard_procedure" boolean in the process parameters (via json).
Then depending on the boolean, the standard procedure (which is already available in 2D) is (or is not) used
@rfaasse rfaasse converted this from a draft issue May 1, 2024
@rfaasse
Copy link
Contributor Author

rfaasse commented May 1, 2024

Small investigation to refine this will be taken up by @WPK4FEM @rfaasse

@rfaasse
Copy link
Contributor Author

rfaasse commented May 3, 2024 •
edited
Loading

Refinement investigation start (work in progress)

Functions the GeoLinearElasticPlaneStrain2DLaw overrides:

public:
ConstitutiveLaw::Pointer Clone() const override;
bool RequiresInitializeMaterialResponse() override;
void InitializeMaterialResponseCauchy(ConstitutiveLaw::Parameters& rValues) override;
bool RequiresFinalizeMaterialResponse() override;
void FinalizeMaterialResponseCauchy(ConstitutiveLaw::Parameters& rValues) override;
void FinalizeMaterialResponsePK2(ConstitutiveLaw::Parameters& rValues) override;
void GetLawFeatures(Features& rFeatures) override;
SizeType WorkingSpaceDimension() override;
SizeType GetStrainSize() const override;
bool IsIncremental() override;
bool& GetValue(const Variable<bool>& rThisVariable, bool& rValue) override;

protected:
void CalculateElasticMatrix(Matrix& C, ConstitutiveLaw::Parameters& rValues) override;
void CalculatePK2Stress(const Vector&                rStrainVector,
                        Vector&                      rStressVector,
                        ConstitutiveLaw::Parameters& rValues) override;

Functions its base LinearPlaneStrainK0Law overrides:

public:
ConstitutiveLaw::Pointer Clone() const override;
void GetLawFeatures(Features& rFeatures) override;
SizeType WorkingSpaceDimension() override { return Dimension; };
SizeType GetStrainSize() const override { return VoigtSize; }
bool& GetValue(const Variable<bool>& rThisVariable, bool& rValue) override;

protected:    
void CalculateElasticMatrix(Matrix& C, ConstitutiveLaw::Parameters& rValues) override;
void CalculatePK2Stress(const Vector&                rStrainVector,
                        Vector&                      rStressVector,
                        ConstitutiveLaw::Parameters& rValues) override;
void CalculateCauchyGreenStrain(ConstitutiveLaw::Parameters& rValues, Vector& rStrainVector) override;

The only one the K0 version has, that the 2D version doesn't have is the CalculateCauchyGreenStrain function. If it would have that function, we could move it in the inheritance structure to derive from GeoLinearElasticLaw directly. This should be relatively small effort, so we could look at the possibility of extending this class to have 3D functionality.

My first idea would be to take the following steps to get this done:

  1. Make sure the GeoLinearElasticPlaneStrain2DLaw does not derive from a K0 law anymore
  2. Identify the behavior that's dimension specific (should that be part of the refinement?)
  3. Create a policy we can inject into the GeoLinearElasticPlaneStrain2DLaw (which should then be renamed to something more generic)
  4. Capture the 2D and 3D behaviors in the policy, later on easily extendible to axisymmetric
  5. Register the laws (where both 2D and 3D are the same class, but get a different policy)

@rfaasse rfaasse changed the title [GeoMechanicsApplication] Standard K0 procedure for 3D [GeoMechanicsApplication] Standard K0 procedure for 3D TO SPLIT May 22, 2024
@rfaasse
Copy link
Contributor Author

rfaasse commented May 22, 2024

To be split by @rfaasse

@rfaasse rfaasse changed the title [GeoMechanicsApplication] Standard K0 procedure for 3D TO SPLIT [GeoMechanicsApplication] Standard K0 procedure for 3D May 22, 2024
@rfaasse rfaasse mentioned this issue May 22, 2024
Closed
@avdg81 avdg81 moved this from 📑 Product Backlog to 📋 Sprint Backlog in Kratos Product Backlog Oct 30, 2024
@markelov208 markelov208 self-assigned this Nov 11, 2024
@markelov208 markelov208 linked a pull request Nov 14, 2024 that will close this issue
[GeoMechanicsApplication] Standard K0 procedure for 3D #12850
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@markelov208 markelov208

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[GeoMechanicsApplication] Standard K0 procedure for 3D KratosMultiphysics/Kratos
2 participants
@rfaasse @markelov208