-
Notifications
You must be signed in to change notification settings - Fork 842
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
Fix HeatFlux non-dimensionalization #2109
Conversation
…alization. We re-dimensionalize aggregated surface outputs for SCREEN_OUTPUT, but we do not for volume output. So by appliying the re-dim one step later we keep the nondim HeatFlux container which is used for volume output as well.
I also found out the hard way that |
@j-signorelli afai see this PR would indeed cause As I do not know much about the structural solver in SU2, I cannot say with confidence -> but from what I saw from skimming over CFEA(Base)Solver, config_template, and a handful of Elasticity cfg's there is no nondimensionalization for the structural solver (but somebody with better knowledge of that should educate me here). Edit: The HeatSolver's HeatFlux written dimensional as well -> so I guess that should be changed as well ... or at least the whole thing should be consistent across solvers |
Let's keep the dimensional outputs, we are already trying to have dimensional inputs to keep things simple. |
Including volume outputs, which right now are a pain for restarting with different types of non-dim |
Hello Tobi, by the way, is there a good explanation as to why even for an
adiabatic wall, and REF_DIMENSIONALIZATION= DIMENSIONAL, I get an abs
(heat flux) > 200 at the conclusion of the flow solver, when
log10(Residual) ~ -9?
…On Wed, Sep 6, 2023 at 6:08 PM TobiKattmann ***@***.***> wrote:
Closed #2109 <#2109>.
—
Reply to this email directly, view it on GitHub
<#2109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGXZUR75MBIGQTN2VJJVZTXZDQ5BANCNFSM6AAAAAA3QKLVDU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hi jaspe55, I would have to check -> a possible explanation I can think of rn (without having checkde) is that we compute the heatflux on the wall based on the temperature gradient of wall temperature with an interior Temperature and that can lead to a non-zero heatflux while there is non at the boundary. Of course that should tend to zero upon refinement and for an adiabatic case. Maybe I am on the wrong track here but I'll try to check soon |
you are correct, there is a discussion on CFD-online about it. we impose 0 heat flux, but report an "apparent heat flux" most codes will simply give you back the imposed heat flux value you specify, nevertheless there will probably be a temperature gradient close to the wall |
Thank you so much, Tobi and Pedro. Yes, there is a temperature gradient
close to the wall. So SU2 gives me, in this case, a 'virtual heat flux'!
Kind regards.
…On Thu, Sep 28, 2023 at 8:25 PM Pedro Gomes ***@***.***> wrote:
you are correct, there is a discussion on CFD-online about it. we impose 0
heat flux, but report an "apparent heat flux" most codes will simply give
you back the imposed heat flux value you specify, nevertheless there will
probably be a temperature gradient close to the wall
—
Reply to this email directly, view it on GitHub
<#2109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGXZUUZNE6B63SH7XJLY2DX4YBMZANCNFSM6AAAAAA3QKLVDU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yet another doubt on the same subject: I just realized that SU2V7.31 (I
have not tested it on later SU2 releases) accepts imposing both adiabatic
walls plus isothermal boundary condition on some walls (when running Menter
model), but when I simply impose only isothermal conditions (leaving
commented out the adiabatic markers), I get the message: SU2 process
returned error '1'. Is there a workaround for this? Kind regards.
…On Thu, Sep 28, 2023 at 8:25 PM Pedro Gomes ***@***.***> wrote:
you are correct, there is a discussion on CFD-online about it. we impose 0
heat flux, but report an "apparent heat flux" most codes will simply give
you back the imposed heat flux value you specify, nevertheless there will
probably be a temperature gradient close to the wall
—
Reply to this email directly, view it on GitHub
<#2109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGXZUUZNE6B63SH7XJLY2DX4YBMZANCNFSM6AAAAAA3QKLVDU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Is there a simple example to reproduce the issue? |
Unfortunately, my example involves a swirler and nozzle for the
Navier-Stokes solver with Menter model, so the dataset is relatively large.
Let me check whether some older small Euler mesh exhibits the same message!
I will let you know! Thank you very much.
…On Mon, Oct 23, 2023 at 6:34 PM Pedro Gomes ***@***.***> wrote:
Is there a simple example to reproduce the issue?
—
Reply to this email directly, view it on GitHub
<#2109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGXZUV3DNRF3O55YAWT563YA3PETAVCNFSM6AAAAAA3QKLVDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGA2TONBZGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hello Pedro. While searching a small sample dataset, I have run some
variations on the jobs, and my findings were:
(Please note that *all* "markers" I have mentioned in the next items refer
to solid walls in the mesh, using the RANS solver)
1- When I impose HEATFLUX=0 *and* ISOTHERMAL=290 Kelvin, for the same
markers, there are no complaints from SU2. It shows that SU2 ignores the
imposition of HEATFLUX=0, in this case.
2- Just setting ISOTHERMAL=290 Kelvin (using all of the same markers as in
(item 1), above), without any HEATFLUX setting, then SU2 produces the same
results as in (item1).
3- When some markers are set with HEATFLUX=0 and the rest of them are set
with ISOTHERMAL=290 Kelvin (so that each wall marker in the mesh is
referenced), there are no complaints from SU2, and the job goes as expected.
4-The error message mentioned earlier, appears when one or more solid wall
markers *is not marked* concerning HEATFLUX or ISOTHERMAL
.
My conclusion then is that the error message appeared when I mistakenly
have not included a wall marker (assigning it as a HEATFLUX or an
ISOTHERMAL marker!)
Does it make sense?
Kind regards,
On Mon, Oct 23, 2023 at 7:48 PM Jairo Cavalcante ***@***.***>
wrote:
… Unfortunately, my example involves a swirler and nozzle for the
Navier-Stokes solver with Menter model, so the dataset is relatively large.
Let me check whether some older small Euler mesh exhibits the same message!
I will let you know! Thank you very much.
On Mon, Oct 23, 2023 at 6:34 PM Pedro Gomes ***@***.***>
wrote:
> Is there a simple example to reproduce the issue?
>
> —
> Reply to this email directly, view it on GitHub
> <#2109 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHGXZUV3DNRF3O55YAWT563YA3PETAVCNFSM6AAAAAA3QKLVDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGA2TONBZGY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Yes that makes sense, we are probably missing some validation on markers not appearing on incompatible boundary conditions. |
Thank you very much, Pedro!
Kind regards
…On Tue, Oct 24, 2023 at 9:09 AM Pedro Gomes ***@***.***> wrote:
Yes that makes sense, we are probably missing some validation on markers
not appearing on incompatible boundary conditions.
—
Reply to this email directly, view it on GitHub
<#2109 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGXZUQ652XHGRI7S7C7D7DYA6VYBAVCNFSM6AAAAAA3QKLVDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZXGA4DGNJZHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Proposed Changes
Hi all,
volume heatflux output is not non-dimensional which is inconsistent with how the rest of volume output is handled.
Note that the History outputs (like TOTAL_HEATFLUX over a bunch of surfaces) is re-dimensionalized -> Apparently that hasn't bothered too many people until now but generally that might be sth we/I want to change (?) Let me know
I fixed it in a way that follows the current convention.
In CConjugateHeatInteface.cpp the required heat_flux is (re)computed on its own so I do not expect a problem there but I will check manually as well
If there is other places which might be affected let me know.
PR Checklist