Skip to content

Conversation

@oleburghardt
Copy link
Contributor

@oleburghardt oleburghardt commented Dec 12, 2019

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.

  • I am submitting my contribution to the develop branch.
  • My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
  • My contribution is commented and consistent with SU2 style.
  • I have added a test case that demonstrates my contribution, if necessary.
  • I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp) , if necessary.

Copy link
Member

@pcarruscag pcarruscag left a 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.

@oleburghardt
Copy link
Contributor Author

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 ||'s from the code, even for minor examples like this.

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.

@oleburghardt oleburghardt marked this pull request as ready for review January 6, 2020 10:34
// 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);
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright ;)

Comment on lines 16671 to 16682
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;
}
Copy link
Contributor Author

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

Copy link
Contributor

@TobiKattmann TobiKattmann left a 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)

Comment on lines 16671 to 16678
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 {
Copy link
Contributor

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)

Copy link
Contributor

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)

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor

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 📚

@oleburghardt
Copy link
Contributor Author

oleburghardt commented Jan 22, 2020

the off-PR comments can be integrated in this PR to clear that up a bit. If not that is OK as well

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! :-)

Can you add that option to the config_template.cfg together with that description, the valid inputs and the default

Actually I'm hesitating a bit adding it to the config template right now. I'd prefer to have DIRECT_TEMPERATURE_ROBIN_HEATFLUX as the default and "hide" the rest as developer's options for the moment.
The reason simply is that those different methods need to checked and validated against each other before we make them public.
E.g. I figured that for the incompressible CHT test case from the repo, there is a severe gap between the heatfluxes obtained from the "averaged" approach and the direct one, see below.

heatflux_convergence

That needs to be cleared up first...

@TobiKattmann
Copy link
Contributor

I'd prefer to have DIRECT_TEMPERATURE_ROBIN_HEATFLUX as the default and "hide" the rest as developer's options for the moment.

Ok, makes sense if the results differ and need some more testing to not add it to the config_template.

you're very welcome to have a look over it! :-)

I'll do my very best 👴

@oleburghardt
Copy link
Contributor Author

Also in BC_HeatFlux_Wall I guess the iMarker_HeatFlux loop can be omitted

The loop is just added because the surface areas are not stored per maker but just by the heat flux markers.

i figured that this BC is called for inc+weakly-coupled heat

Not really, it's called when there is no heat solver at all. (Being a no-slip BC then.)

@TobiKattmann
Copy link
Contributor

Hey @oleburghardt , thanks again for the fix and for the clean-up bits. From my side this is good to go 🌬 ⛵️

@talbring talbring merged commit 00f47ab into develop Jan 24, 2020
@talbring talbring deleted the fix_compressible_CHT branch January 24, 2020 12:37
Comment on lines +60 to +64
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()));
Copy link
Member

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.

Copy link
Contributor Author

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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants