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

[GeoMechanicsApplication] Clean up / simplify the calculation of the permeability update factor #12372

Merged
merged 9 commits into from
May 13, 2024

Conversation

avdg81
Copy link
Contributor

@avdg81 avdg81 commented May 13, 2024

📝 Description
Simplified and cleaned up the implementation of the members that compute the permeability update factor.

🆕 Changelog

  • Made the member functions const.
  • Use the return type to return the functions' result.
  • Removed redundant usages of else keywords.
  • Use std::pow rather than C-style pow.
  • No need to instantiate a class to call its static members.
  • Only pass what is needed to compute the permeability update factor.
  • Reduced the scope of a local variable.
  • Renamed local variables to comply with the Kratos Style Guide.

@avdg81 avdg81 added Cleanup GeoMechanics Issues related to the GeoMechanicsApplication labels May 13, 2024
@avdg81 avdg81 requested review from rfaasse, WPK4FEM and markelov208 May 13, 2024 09:45
@avdg81 avdg81 self-assigned this May 13, 2024
Copy link
Contributor

@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.

Small and clear PR which once more reduces our use of ElementVariables. Also, good catch with the std::pow!

rVariables.PermeabilityUpdateFactor = pow(10.0, permLog10);
} else {
rVariables.PermeabilityUpdateFactor = 1.0;
return std::pow(10.0, permLog10);
Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch, it seems that before it found a boost version (in corecrt_math.h) and now just uses cmath. It's good to keep this in mind indeed.

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 Anne,
This touches on the same lines as Richards pull request for strain computation.
Please be careful when merging.
Regards, Wijtze Pieter

rVariables.PermeabilityUpdateFactor = 1.0;
if (const auto& r_prop = this->GetProperties(); r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR] > 0.0) {
const double InverseCK = r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR];
const double epsV = StressStrainUtilities::CalculateTrace(rStrainVector);
Copy link
Contributor

Choose a reason for hiding this comment

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

This resolves a lot of created confusion about the meaning of the volumetric strain. There was no need to mingle it with names indicating stress.

Comment on lines +1593 to 1609
double SmallStrainUPwDiffOrderElement::CalculatePermeabilityUpdateFactor(const Vector& rStrainVector) const
{
KRATOS_TRY

const PropertiesType& rProp = this->GetProperties();

if (rProp[PERMEABILITY_CHANGE_INVERSE_FACTOR] > 0.0) {
const double InverseCK = rProp[PERMEABILITY_CHANGE_INVERSE_FACTOR];
const double epsV = StressStrainUtilities::CalculateTrace(rVariables.StrainVector);
const double ePrevious = rProp[POROSITY] / (1.0 - rProp[POROSITY]);
if (const auto& r_prop = this->GetProperties(); r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR] > 0.0) {
const double InverseCK = r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR];
const double epsV = StressStrainUtilities::CalculateTrace(rStrainVector);
const double ePrevious = r_prop[POROSITY] / (1.0 - r_prop[POROSITY]);
const double eCurrent = (1.0 + ePrevious) * std::exp(epsV) - 1.0;
const double permLog10 = (eCurrent - ePrevious) * InverseCK;
rVariables.PermeabilityUpdateFactor = pow(10.0, permLog10);
} else {
rVariables.PermeabilityUpdateFactor = 1.0;
return std::pow(10.0, permLog10);
}

return 1.0;

KRATOS_CATCH("")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Repeated in several elements. I do not see element specific code, should this be a utility function. The strain dependency points towards equation of motion or stress_strain utilities. Its use points to the transport equation utilities.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I agree that we can move this to a separate utility function. I would suggest to do that in a separate PR, just to keep the history clear.

Copy link
Contributor

@markelov208 markelov208 left a comment

Choose a reason for hiding this comment

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

Anne, nice work in getting rid of Variables and code smells. After the changes made, it looks that both elements use almost the same function. Is it useful to put it in a common place? Thank you.

Comment on lines +1174 to +1180
if (const auto& r_prop = this->GetProperties(); r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR] > 0.0) {
const double InverseCK = r_prop[PERMEABILITY_CHANGE_INVERSE_FACTOR];
const double epsV = StressStrainUtilities::CalculateTrace(rStrainVector);
const double ePrevious = r_prop[POROSITY] / (1.0 - r_prop[POROSITY]);
const double eCurrent = (1.0 + ePrevious) * std::exp(epsV) - 1.0;
const double permLog10 = (eCurrent - ePrevious) * InverseCK;
return std::pow(10.0, permLog10);
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks that both elements use the same function and a difference is only in this->GetProperties. Is it useful to move the function to utilities with r_Prop as input?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I agree that we can move this to a separate utility function. I would suggest to do that in a separate PR, just to keep the history clear. As you indicated, we'd better provide the element properties as an input parameter to that new utility function.

@avdg81 avdg81 merged commit 271b400 into master May 13, 2024
11 checks passed
@avdg81 avdg81 deleted the geo/simplify-permeability-update-factor branch May 13, 2024 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cleanup GeoMechanics Issues related to the GeoMechanicsApplication
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants