2017-12-15 18:01 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002722OpenFOAMFeaturepublic2017-11-29 11:16
Reporteratulkjoy 
Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformCentos OSCentos 7.0OS VersionCentos 7.0
Product Versiondev 
Target VersionFixed in Version5.x 
Summary0002722: Wall Heat Flux function object
Description/OpenFOAM-dev/src/functionObjects/field/wallHeatFlux/wallHeatFlux.C
Total heat flux should be cumulative of convective heat flux and radiative heat flux at boundary. At wall boundary lower temperature then next adjacent cell due to gradient or snGrad convectibe heat flux will be negative.

wallHeatFluxBf[patchi] = heatFluxBf[patchi]; // ln 78 Col 45

This results in substracation not addition

wallHeatFluxBf[patchi] += radHeatFluxBf[patchi]; // Ln 90 col 61
Steps To ReproducewallHeatFluxBf[patchi] = -heatFluxBf[patchi]; //sign has been changed to make it +ve due to which or better make it +ve always if it is negative to see the effect
TagsfunctionObject
Attached Files

-Relationships
+Relationships

-Notes

~0008863

henry (manager)

Can you provide a simple case or is there a tutorial case which demonstrates the need for this change?

~0008864

StephanG (reporter)

I don't quite understand what you are getting at. The heat flux can be negative. This is not an error. The sign tells you if the heat is flowing into the domain or if it is leaving it. For CHT one side is always negative and the other positive.

~0008874

wyldckat (updater)

@atulkjoy: Please provide more details for this bug report, as requested on the rules page: https://bugs.openfoam.org/rules.php

I know that you asked about this on this thread: https://www.cfd-online.com/Forums/openfoam-post-processing/192658-wall-heat-flux-utulity.html

But in this report here, please also provide the evidences of what you initially discovered and how you reached the conclusion regarding what should be the correct sign. I know that you provided the plots and results on that thread, but it's not accessible to the public unless people log in there, so please post the images here as well.

----

@Henry and @StephanG: Just in case atulkjoy doesn't answer in the meantime, here is a partial quote of what I wrote regarding this topic on that thread:

   In OpenFOAM 4.x and older, the calculation is done as:

       convective_term - radiative_term

   While in OpenFOAM 5.x and newer, the calculation is done as:

       convective_term + radiative_term

   I haven't managed to figure out which one is correct, because I haven't managed to figure out what is the sign convention for Qr and for the convective heat flux.
   At a first glance, it seemed like Qr was always positive ("q = Boltzman * T^4 * Area"), which doesn't make much sense in this context, since it should be a subtraction of the two or more temperature[/radiation] sources, imposed on the wall.

~0009093

wyldckat (updater)

I have some more details on this topic, but I haven't had the time to sort through them yet and confirm what is correct. But here goes the information I've gathered so far:

 1. The change in the sign for this calculation has already occurred in the past. Start reading from the following Juho's comment here: https://bugs.openfoam.org/view.php?id=1856#c5713 - in report #1856.

    - In a nutshell, see the bug fix in this commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/5749c95ed68e40c11ea586549fb667553d218f1f


 2. A recent optimization that was implemented into this 'wallHeatFlux' function object - see Issue #2725: https://bugs.openfoam.org/view.php?id=2725 - has lead to not allowing the calculation of said wall heat flux on coupled patches, which is the test that was indications by Juho in the aforementioned issue #1856, and I quote:

> Steps to reproduce:
> 1. Run the chtMultiRegionSimpleFoam multiRegionHeaterRadiation tutorial to convergence
> 2. Check the heat balance between the regions with the wallHeatFlux utility


Therefore, once it's possible to run the function object with the tutorial case "chtMultiRegionSimpleFoam/multiRegionHeaterRadiation", it's possible to assess if the radiation term is meant to be added or subtracted.

~0009095

henry (manager)

@wyldckat It is not clear to me how the changes for #2725 affect this, could you clarify?

~0009098

wyldckat (updater)

@Henry: I don't have an updated build of OpenFOAM-dev at hand right now, but when the tutorial case "chtMultiRegionSimpleFoam/multiRegionHeaterRadiation" is run with the function object 'wallHeatFlux', I get an error message about 'snGrad' not being implemented for coupled patches.

Therefore, I was not able to do the same test that Juho did for the last fix in #1856, i.e. to verify which sign should be used when accounting the radiation term into the 'wallHeatFlux'.

My apologies for not opening another report for the 'snGrad' issue sooner, but I was planning on opening it only when I had all of the pieces and patch... but a couple of weeks passed by since then, so it seemed best to at least provide what I already knew about this current report and associated information.

~0009100

henry (manager)

@wyldckat: Thanks for the clarification, I will investigate.

~0009101

tniemi (reporter)

Just to comment, the sign convention of qr is such that it is the net amount of radiation absorbed by the wall -> positive qr indicates that energy is flowing into the wall and out of the domain. This means that qr behaves opposite to wallHeatFluxBf which is negative if the flux is out of the domain. This was the reason why the sign was changed previously. Easiest fix would be changing += to -= in line 91 in wallHeatFlux.C.

~0009102

henry (manager)

@wyldckat: I am not able to reproduce the problem, I have added

functions
{
    #includeFunc wallHeatFlux(region=heater)
}

to the controlDict and the case runs fine and generates heat flux data for the patch. Could you provide more details for how to reproduce the problem?

~0009103

wyldckat (updater)

@Henry: If it's working fine for you, then please move onward. I will open a new bug report if I'm able to reproduce the issue I had with snGrad+coupled boundaries.

In the meantime, tniemi's answer seems to clarify the need for the original bug report.

~0009104

henry (manager)

Thanks Timo

Resolved in OpenFOAM-5.x by commit a268af97208e55ed1d4f1ebff4d95a9faf64ef9c

Resolved in OpenFOAM-dev by commit 396259f105b2542912c35b29c4d8b96df5d3a77c
+Notes

-Issue History
Date Modified Username Field Change
2017-10-12 11:29 atulkjoy New Issue
2017-10-12 11:29 atulkjoy File Added: wallHeatFlux.C
2017-10-12 11:29 atulkjoy Tag Attached: functionObject
2017-10-12 15:45 henry Note Added: 0008863
2017-10-13 09:21 StephanG Note Added: 0008864
2017-10-15 10:22 wyldckat Note Added: 0008874
2017-11-28 23:06 wyldckat Note Added: 0009093
2017-11-28 23:38 henry Note Added: 0009095
2017-11-29 08:54 wyldckat Note Added: 0009098
2017-11-29 09:09 henry Note Added: 0009100
2017-11-29 10:37 tniemi Note Added: 0009101
2017-11-29 10:42 henry Note Added: 0009102
2017-11-29 10:58 wyldckat Note Added: 0009103
2017-11-29 11:16 henry Assigned To => henry
2017-11-29 11:16 henry Status new => resolved
2017-11-29 11:16 henry Resolution open => fixed
2017-11-29 11:16 henry Fixed in Version => 5.x
2017-11-29 11:16 henry Note Added: 0009104
+Issue History