-
Notifications
You must be signed in to change notification settings - Fork 918
Compressible CHT fixes #839
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
Conversation
pcarruscag
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I think what is proposed in #770 could help prevent this kind of bugs.
Probably it could help as one could painlessly add special entries to such a bit field that will remove the I'll leave this as draft for a while because I'd like to test some more compressible stuff in terms of reference values, non-dimensionalization and so on. It's a good opportunity. |
SU2_CFD/src/solver_direct_mean.cpp
Outdated
| // feasible alternative to compute (conjugate) wall termperature | ||
| // HF_FactorHere = thermal_conductivity*config->GetViscosity_Ref()/dist_ij; | ||
| // HF_FactorConjugate = GetConjugateHeatVariable(val_marker, iVertex, 2); | ||
| // Twall = (There*HF_FactorHere + Tconjugate*HF_FactorConjugate)/(HF_FactorHere + HF_FactorConjugate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that's feasible consider adding it as an option, otherwise remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright ;)
…into fix_compressible_CHT
SU2_CFD/src/solver_direct_mean.cpp
Outdated
| if ((config->GetKind_CHT_Coupling() == AVERAGED_TEMPERATURE_NEUMANN_HEATFLUX) | ||
| || (config->GetKind_CHT_Coupling() == AVERAGED_TEMPERATURE_ROBIN_HEATFLUX)) { | ||
|
|
||
| // this will be changed soon... | ||
| Twall = GetConjugateHeatVariable(val_marker, iVertex, 0); | ||
| HF_FactorHere = thermal_conductivity*config->GetViscosity_Ref()/dist_ij; | ||
| HF_FactorConjugate = GetConjugateHeatVariable(val_marker, iVertex, 2); | ||
| Twall = (There*HF_FactorHere + Tconjugate*HF_FactorConjugate)/(HF_FactorHere + HF_FactorConjugate); | ||
| } | ||
| else { | ||
|
|
||
| dTdn = -(There - Twall)/dist_ij; | ||
| Twall = Tconjugate; | ||
| dTdn = -(There - Twall)/dist_ij; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@talbring Please check :) Let me know before you merge this in, I'm still checking for some performance differences between those methods for the coupled_cht test case. (To determine which one should be initialised as default.)
TobiKattmann
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @oleburghardt ,
Thanks for the fix and the Testcase. I have some questions below and I would like to understand the implications for my work 😉
I don't want to go beyond the scope of this PR, but if you like, the off-PR comments can be integrated in this PR to clear that up a bit. If not that is OK as well
A bit off-PR: in solver_direct_heat:cppBC_ConjugateHeat_Interface the input value val_marker is not really used... there are loops over iMarker which seem unnecessary.
(Also in BC_HeatFlux_Wall I guess the iMarker_HeatFlux loop can be omitted -> from what is in integration_structure.cpp at case CHT_WALL_INTERFACE i figured that this BC is called for inc+weakly-coupled heat. Here I would prefer as well integrating it in BC_ConjugateHeat_Interface, or writing a short hint in both BCs)
SU2_CFD/src/solver_direct_mean.cpp
Outdated
| if ((config->GetKind_CHT_Coupling() == AVERAGED_TEMPERATURE_NEUMANN_HEATFLUX) | ||
| || (config->GetKind_CHT_Coupling() == AVERAGED_TEMPERATURE_ROBIN_HEATFLUX)) { | ||
|
|
||
| // this will be changed soon... | ||
| Twall = GetConjugateHeatVariable(val_marker, iVertex, 0); | ||
| HF_FactorHere = thermal_conductivity*config->GetViscosity_Ref()/dist_ij; | ||
| HF_FactorConjugate = GetConjugateHeatVariable(val_marker, iVertex, 2); | ||
| Twall = (There*HF_FactorHere + Tconjugate*HF_FactorConjugate)/(HF_FactorHere + HF_FactorConjugate); | ||
| } | ||
| else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer here (i.e. instead of the else) to check config->GetKind_CHT_Coupling() explicitly against the options that are reasonable here and add if you like an } else { SU2_MPI::Error("Unknown Kind_CHT_Coupling..."). (Same goes for solver_direct_heat.cpp)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To give a reason why: I tend to grep through the repository quite often for keywords to get an overview and if an option is implicitly taken in an else one cannot find it directly. (One can always grep the Getter function of course)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Complicated "if ... Else if... Else if..." statements are harder for the compiler to optimize.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm alright, I'll add the error message, it's a bit more safe..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pcarruscag is a switch statement better, or what is the best way to resolve that? In this case it is only if..else if..else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mind you that most times this is not a super important optimization, I do show a case in 789 where it is.
But anyway, ideally error conditions will have been handled upstream and one does not need to include error handling code in hot regions (i.e. loops) where it would pollute the instruction cache. In which case if the purpose is to document just add what the "else" implies as a comment. Switches are for "out of many options choose one kind of deal".
The reason why simple if/else code might work better is not (just) the reduction of logical checks, as within a loop the cpu will start predicting the right branch to take. The real advantage is if instead of branching the compiler manages to use conditional move instructions instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There goes another day me figuring and trying out what conditional move instructions are 🙈
I actually wanted to argue with branch prediction that it shouldn't matter that much.... but now I can learn sth new 📚
It's more than OK, the CHT implementation suffers a bit from being a single person's project.. you're very welcome to have a look over it! :-)
Actually I'm hesitating a bit adding it to the config template right now. I'd prefer to have That needs to be cleared up first... |
Ok, makes sense if the results differ and need some more testing to not add it to the config_template.
I'll do my very best 👴 |
The loop is just added because the surface areas are not stored per maker but just by the heat flux markers.
Not really, it's called when there is no heat solver at all. (Being a no-slip BC then.) |
|
Hey @oleburghardt , thanks again for the fix and for the clean-up bits. From my side this is good to go 🌬 ⛵️ |
| bool incompressible_flow = ((donor_config->GetKind_Solver() == INC_NAVIER_STOKES) | ||
| || (donor_config->GetKind_Solver() == INC_RANS) | ||
| || (donor_config->GetKind_Solver() == DISC_ADJ_INC_NAVIER_STOKES) | ||
| || (donor_config->GetKind_Solver() == DISC_ADJ_INC_RANS)); | ||
|
|
||
| bool compressible_flow = (donor_config->GetKind_Regime() == COMPRESSIBLE) && flow; | ||
| bool incompressible_flow = (donor_config->GetEnergy_Equation()) && flow; | ||
| bool heat_equation = (donor_config->GetKind_Solver() == HEAT_EQUATION_FVM | ||
| || donor_config->GetKind_Solver() == DISC_ADJ_HEAT); | ||
| || (donor_config->GetKind_Solver() == DISC_ADJ_INC_RANS) | ||
| && (donor_config->GetEnergy_Equation())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oleburghardt you ticked the "no new compiler warnings" box, but there is a warning for this logic and it does look a bit suspicious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Pedro, I'll check 👍

Proposed Changes
This PR includes a fix that will reenable CHT for compressible flow (unintentionally out of service in v7 so far). A regression test was added to protect this functionality together with some general CHT-related cleanups.
Related Work
Fixes issue #838
PR Checklist
Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.