View Issue Details

IDProjectCategoryView StatusLast Update
0001433OpenFOAM[All Projects] Bugpublic2015-01-18 22:06
ReporterwyldckatAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityN/A
Status resolvedResolutionfixed 
Product Version 
Fixed in Version 
Summary0001433: Units in the incompressible implementation of the class "turbulentHeatFluxTemperatureFvPatchScalarField" aren't perfectly clear
DescriptionIn the file "src/turbulenceModels/incompressible/turbulenceModel/derivedFvPatchFields/turbulentHeatFluxTemperature/turbulentHeatFluxTemperatureFvPatchScalarField.C" is this piece of code:

        case hsFlux:
        {
            gradient() = q_/(Cp0*alphaEffp);
            break;
        }


And in the header is this information:

        heatSource | heat source type: \c flux [W/m2] or \c power [W]| yes |
        q | heat source value | yes |

[...]

    - it is assumed that the units of \c alphaEff are [kg/m/s]
    - the specific heat capcaity is read from the transport dictionary entry
      \c Cp0

(By the way, the typo "capcaity" isn't mine ;) )



Now, the symptoms are as follows:

 1. "Cp0" read from the dictionary has no units, which is somewhat suspicious...

 2. "alphaEff" is commented as being assumed to have the units [kg/m/s], which is a somewhat dangerous assumption, since in the incompressible model it derives from "alphat" which has the dimensions "[0 2 -1 0 0 0 0]".

 3. When the heat source is meant to be flux, it's documented as having the units [W/m2].


If we compare with the compressible implementation of this same boundary condition, we're dealing with this equation:

   gradient() = (q_ + qr)/kappa(Tp)

Which is approximately:
   gradient() = q_/(alphaEff*thermo.Cp)

And where the units are:

 1. "thermo.Cp" is in [J/kg/K] (according to "src/thermophysicalModels/basic/basicThermo/basicThermo.H").

 2. "alphaEff", i.e. "alphat" has the dimensions "[1 -1 -1 0 0 0 0]".

 3. When the heat source is meant to be flux, it's also documented as having the units [W/m2].



Therefore, something is incorrectly documented in the incompressible implementation.
One suggestion would be that the comment is updated to something like this:

    - reminder: the units of \c alphaEff are [m2/s2]
    - the specific heat capacity is read from the transport dictionary entry
      \c Cp0 and is actually Cp*rho, namely in [J/kg/K]*[kg/m3] = [J/m3/K] =
      [kg.m2/s2]/[m3/K] = [kg/m/s2/K]

and that the "Cp0" value read from the dictionary is forced to be read with units, instead of a simple scalar :)
For example:

   Cp0 Cp0 [1 -1 -2 -1 0 0 0] 1000.0;


The other hypothesis is to think the other way around and state that the heat flux is actually the "kinematic heat flux", i.e. "q/rho"... which has some pretty crazy units :)
Additional InformationI've only spotted this while diagnosing the detail mentioned here: http://www.cfd-online.com/Forums/openfoam-post-processing/101972-wallheatflux-utility-incompressible-case-2.html#post516635
TagsNo tags attached.

Activities

wyldckat

2015-01-17 18:58

updater   ~0003548

Greetings,

So I'm guessing that this bug report of mine is suffering from the symptom "tl;dr". Therefore, here's the summarized 3 point report:

1. Files in question are the ones in this folder: "src/turbulenceModels/incompressible/turbulenceModel/derivedFvPatchFields/turbulentHeatFluxTemperature"

2. There is a typo in the header file ".H" where it's spelled "capcaity", which should be "capacity".

3. "Cp0" is not described in the comments within the header file, nor is respective dictionary entry require units, which can lead to serious errors in calculations.

3.a) The quick proposition is to update the respective comment to something like this (maybe not as complex):

    - the specific heat capacity is read from the transport dictionary entry
      \c Cp0 and is actually Cp*rho, namely in [J/kg/K]*[kg/m3] = [J/m3/K] =
      [kg.m2/s2]/[m3/K] = [kg/m/s2/K]

3.b) One perfectionist proposition is to enforce the correct units when reading from the dictionary, e.g.:

   Cp0 Cp0 [1 -1 -2 -1 0 0 0] 1000.0;


For more specific details, please check the original report.
If anything else is needed, like a proof/test case, please let me know.

Best regards,
Bruno

henry

2015-01-18 22:06

manager   ~0003563

Replaced Cp0 with rhoCp0 and added comment concerning units to clarify usage

Resolved by commit 7e448b3295dd77b6d9c7cd0d745b0c02c318cf9d

Issue History

Date Modified Username Field Change
2014-11-01 22:17 wyldckat New Issue
2015-01-17 18:58 wyldckat Note Added: 0003548
2015-01-18 22:06 henry Note Added: 0003563
2015-01-18 22:06 henry Status new => resolved
2015-01-18 22:06 henry Resolution open => fixed
2015-01-18 22:06 henry Assigned To => henry