Skip to content

[GeoMechanicsApplication] Add a class that represents a principal stress vector#14173

Merged
rfaasse merged 14 commits intomasterfrom
geo/14170-add-a-class-that-represents-a-principal-stress-vector
Feb 4, 2026
Merged

[GeoMechanicsApplication] Add a class that represents a principal stress vector#14173
rfaasse merged 14 commits intomasterfrom
geo/14170-add-a-class-that-represents-a-principal-stress-vector

Conversation

@rfaasse
Copy link
Contributor

@rfaasse rfaasse commented Feb 3, 2026

📝 Description
Very minimal class that wraps around a ublas vector to represent principal stresses

@rfaasse rfaasse requested review from WPK4FEM and avdg81 February 3, 2026 12:36
@rfaasse rfaasse self-assigned this Feb 3, 2026
@rfaasse rfaasse requested a review from a team as a code owner February 3, 2026 12:36
KRATOS_DEBUG_ERROR_IF_NOT(rStressVector.size() == msVectorSize)
<< "PrincipalStresses can only be initialized with a vector of size " << msVectorSize
<< ", got " << rStressVector.size() << std::endl;
std::ranges::copy(rStressVector, mValues.begin());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

An open question is if we would always like to sort the values in the vector when creating a 'principal stresses object'. What are your opinions @WPK4FEM, @avdg81, @mnabideltares?

Copy link
Contributor

Choose a reason for hiding this comment

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

In principle my answer is yes. The desired ordering be found in the implementation of the MC with tension cut off material model.
However that would perhaps complicate the coping operations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a good idea to move the logic of the ordering/reordering of the stresses to this class (it seems it belongs there). However, since I have the impression it's quite tightly related to the way the Mohr Coulomb law works, I would like to do that in a separate PR and keep this one simple.

Copy link
Contributor

Choose a reason for hiding this comment

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

An open question is if we would always like to sort the values in the vector when creating a 'principal stresses object'. What are your opinions @WPK4FEM, @avdg81, @mnabideltares?

I also agree that the sorting should be there, because there is code that relies on the fact that the components of the principal stress vector are sorted from largest to smallest. But indeed, such an extension can be done in a separate PR.

WPK4FEM
WPK4FEM previously approved these changes Feb 3, 2026
Copy link
Contributor

@WPK4FEM WPK4FEM left a comment

Choose a reason for hiding this comment

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

Hi Richard,
Indeed nice and short. The sorting thing will cause a lot of constraints on setting components. I don't know if it is wise to enforce that now.
Regards, Wijtze Pieter

KRATOS_DEBUG_ERROR_IF_NOT(rStressVector.size() == msVectorSize)
<< "PrincipalStresses can only be initialized with a vector of size " << msVectorSize
<< ", got " << rStressVector.size() << std::endl;
std::ranges::copy(rStressVector, mValues.begin());
Copy link
Contributor

Choose a reason for hiding this comment

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

In principle my answer is yes. The desired ordering be found in the implementation of the MC with tension cut off material model.
However that would perhaps complicate the coping operations.

Copy link
Contributor Author

@rfaasse rfaasse left a comment

Choose a reason for hiding this comment

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

Thanks for the review, let me know whether you agree with the answers on the question/discussion!

KRATOS_DEBUG_ERROR_IF_NOT(rStressVector.size() == msVectorSize)
<< "PrincipalStresses can only be initialized with a vector of size " << msVectorSize
<< ", got " << rStressVector.size() << std::endl;
std::ranges::copy(rStressVector, mValues.begin());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a good idea to move the logic of the ordering/reordering of the stresses to this class (it seems it belongs there). However, since I have the impression it's quite tightly related to the way the Mohr Coulomb law works, I would like to do that in a separate PR and keep this one simple.

Copy link
Contributor

@avdg81 avdg81 left a comment

Choose a reason for hiding this comment

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

Hi Richard,
Thanks for preparing this class and making it similar to the SigmaTau class. I only have one very minor suggestion, which you can skip if no other changes are needed. 👍

Copy link
Contributor

@avdg81 avdg81 left a comment

Choose a reason for hiding this comment

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

Thanks for processing the review suggestions and resolving the one issue that was found by SonarQube. I feel this PR is good to go.

@rfaasse rfaasse enabled auto-merge (squash) February 4, 2026 12:52
@rfaasse rfaasse merged commit d6bd686 into master Feb 4, 2026
10 checks passed
@rfaasse rfaasse deleted the geo/14170-add-a-class-that-represents-a-principal-stress-vector branch February 4, 2026 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[GeoMechanicsApplication] Add a class that represents a principal stress vector

3 participants