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] Add normal heat flux boundary condition #11783

Merged
merged 59 commits into from
Nov 24, 2023

Conversation

markelov208
Copy link
Contributor

@markelov208 markelov208 commented Nov 9, 2023

📝 Description
A brief description of the PR.

Please mark the PR with appropriate tags:

  • Normal heat flux condition is added (TNormalFluxCondition).
  • A thermal condition class is added which include the basic functions of thermal conditions (TCondition).

🆕 Changelog
Please summarize the changes in one list to generate the changelog:
E.g.

@markelov208 markelov208 self-assigned this Nov 9, 2023
Gennady Markelov added 4 commits November 9, 2023 22:36
@markelov208 markelov208 changed the title [GeoMechanicsApplication] Add normal heat flux boundary condition #11781 [GeoMechanicsApplication] Add normal heat flux boundary condition Nov 10, 2023
Gennady Markelov added 2 commits November 20, 2023 11:26
# Conflicts:
#	applications/GeoMechanicsApplication/geo_mechanics_application.cpp
#	applications/GeoMechanicsApplication/geo_mechanics_application.h
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.

Thank you for adding this code, it looks clean and readable!

I have some comments, mostly related to style and minor improvements. A proposition with some more work related to it would be adding more validations in the unit tests, instead of checking just one of the functions (I think it should be doable, but we can have a look!).

Comment on lines 75 to 78
if (rLeftHandSideMatrix.size1() != TNumNodes || rLeftHandSideMatrix.size2() != TNumNodes) {
rLeftHandSideMatrix.resize(TNumNodes, TNumNodes, false);
}
noalias(rLeftHandSideMatrix) = ZeroMatrix(TNumNodes, TNumNodes);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it necessary to first resize the matrix before assigning a ZeroMatrix with a certain size? Same holds for the rRightHandSideMatrix

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 have checked with the debugger. Yes, we have to resize before noalias because the latter does not change the matrix size. Without noalias we do not need this resize. Shall we avoid noalias?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know enough about the advantages of noalias. It might be more efficient, but I don't know if that's the case here as well. Do you have a suggestion @avdg81?

Copy link
Contributor

Choose a reason for hiding this comment

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

My understanding is that the primary aim of the noalias syntax is to eliminate temporaries where the programmer sees this can be done safely. From the ublas documentation (see the Section named "Aliases"):

Abstract formulas on vectors and matrices normally compose a couple of unary and binary operations. The conventional way of evaluating such a formula is first to evaluate every leaf operation of a composition into a temporary and next to evaluate the composite resulting in another temporary. This method is expensive in terms of time especially for small and space especially for large vectors and matrices. [...]

One may get serious side effects using element wise evaluation on vectors or matrices. [...]

Our solution for this problem (i.e. where during the evaluation elements are overwritten that affect other evaluations) is to evaluate the right hand side of an assignment into a temporary and then to assign this temporary to the left hand side. [...] By using this syntax (i.e. noalias) a programmer can confirm, that the left and right hand sides of an assignment are independent, so that element wise evaluation and direct assignment to the target is safe.

The documentation doesn't mention that using noalias prevents resizing of vectors and matrices, as observed by @markelov208. I need to investigate that behavior in more detail first before making any statements about that. However, for this particular case, where we assign a zero matrix, I don't directly see any benefit in using noalias. Therefore, I would suggest to remove the noalias here, as well as the preceding resizing operation, since it is confusing and not strictly necessary. Do you agree @markelov208 and @rfaasse?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with removing noalias in that case

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 removed resize and noalias

Copy link
Contributor Author

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

Thank you Richard for the valuable comments. Hope all your comments are resolved now.

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.

Thanks a lot for adding the extra unit tests, these are quite some work to figure out how to do it and how to test for the values, but this creates a nice safety net!

I have a few minor comments left, but nothing blocking

Copy link
Contributor Author

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

Richard, once again thank you for the thorough review.

rfaasse
rfaasse previously approved these changes Nov 23, 2023
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.

Thanks for all the hard work, it looks good to me now (but let's wait for the approval of @WPK4FEM as well)!

Copy link
Contributor Author

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

Richard and Wijtze Pieter, almost last changes. There are still two comments I would like to talk tomorrow. Thank you.

@markelov208 markelov208 requested a review from a team as a code owner November 24, 2023 12:40
@markelov208 markelov208 removed the request for review from a team November 24, 2023 13:16
@WPK4FEM WPK4FEM linked an issue Nov 24, 2023 that may be closed by this pull request
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.

Nicely done! Ready for merge!

@markelov208 markelov208 merged commit 3048ca6 into master Nov 24, 2023
15 of 16 checks passed
@markelov208 markelov208 deleted the geo/11781-add-T-normal-flux-condition branch November 24, 2023 15:28
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 normal heat flux boundary condition
5 participants