View Issue Details

IDProjectCategoryView StatusLast Update
0002532OpenFOAM[All Projects] Bugpublic2017-05-04 12:04
ReporterpilschkaAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSDebianOS Version8
Product Version 
Fixed in Version 
Summary0002532: wrong values of thermal conductivity (kappa) in Sutherland model
DescriptionWhen using sutherland formula for calculating temperature depending viscosity values, the thermal conductivity is calculated with modified Eucken equation. In OF it reads

inline Foam::scalar Foam::sutherlandTransport<Thermo>::kappa
    const scalar p, const scalar T
) const
    scalar Cv_ = this->Cv(p, T);
    return mu(p, T)*Cv_*(1.32 + 1.77*this->R()/Cv_);

In my test case mu and Cv are correct but kappa is much higher as the measurement Value for that temperature (Lemmon at al 2004).
Using the formula above in a separate python script, kappa is calculated correctly.

for T = 300:
kappa OpenFoam= 0.03769
kappa(python) = 0.026922
kappa(Lemmon) = 0.0263529

Lemmon, EW ; Jacobsen, RT: Viscosity and thermal conductivity equations for nitrogen, oxygen, argon, and air. (2004)
Steps To Reproduce# start rhoSimpleFoam simulation
# open results in paraview
# compare values with that from python script ""



2017-04-28 11:44


BugReportSutherland.tar.gz (439,145 bytes)


2017-04-28 11:57

manager   ~0008051

Could you test OpenFOAM-dev, all the thermodynamics has been changed from mole to mass-basis which will change the operation of this function.


2017-05-02 11:29

reporter   ~0008060

Today I tested the case with OpenFOAM-dev. Since I couldn't manage to install swak4foam for the dev version
I compared the thermal diffusivity for the enthalpy (alpha = kappa/Cp). (only thermo:alpha is available in

And for alpha I get the same values as before with OpenFOAM-4.1.


2017-05-02 11:38

manager   ~0008061

Have you checked to see which part of the function

inline Foam::scalar Foam::sutherlandTransport<Thermo>::kappa
    const scalar p, const scalar T
) const
    scalar Cv_ = this->Cv(p, T);
    return mu(p, T)*Cv_*(1.32 + 1.77*this->R()/Cv_);

is not behaving correctly?


2017-05-02 12:07

reporter   ~0008062

No I haven't. My C++ skills are at best rudimental. I just checked mu and Cv in
paraview (written with swak4foam). I don't think that the specific gas constant
R() can be problem, but I don't know how to proof it, since a simple

Info<<'R = '<< this->R() << endl;

doesn't work.


2017-05-02 12:36

manager   ~0008063

Info << "R = " << this->R() << endl;


2017-05-02 13:21

reporter   ~0008064

Oh sorry, please excuse my inaccuracy. I did write it as you typed, but didn't get a message on the screen. I guess I put the line at the wrong place, although I tried different positions.
Sorry again for my low C++ knowledge.


2017-05-02 13:29

manager   ~0008065

You probably haven't recompiled the relevant libraries. Note that these low-level thermo classes are templates so you will need to recompile the libraries which instantiate them.


2017-05-02 14:49

manager   ~0008067



2017-05-03 07:20

reporter   ~0008069

I looked into this and the difference seems to be due to using sensibleInternalEnergy. In this case alpha is not kappa/Cp, but kappa/Cv. Taking this into account the results from python and OF are similar, slight difference due to using janaf in OF.

alpha(OF): 3.73905e-5
kappa/cv(python): 3.74119e-5

However, the actual problem is in the ambigous use of alphah in most transport models. The definition of the function is to give diffusivity of enthalpy, but the function uses Cpv and actually gives either diffusivity of enthalpy or energy. heThermo assumes it is always diffusivity for enthalpy and thus calculates kappa=Cp*alpha, which goes wrong if InternalEnergy is used.


2017-05-03 08:01

reporter   ~0008070

I looked at heThermo more thoroughly and indeed it always assumes alpha is kappa/Cp and for instance in alphaEff it does the conversion with CpByCpv. So I guess everything would work out if alphah-functions would always return the diffusivity of enthalpy. This way both kappa and the laminar part of alphaEff would be correct.

The ambigous alphah is used at least in sutherland, polynomial and logPolynomial models and also in solid transport models.


2017-05-03 15:08

manager   ~0008074

Timo: I have just committed your proposed change in OpenFOAM-dev for testing:

commit 7acfa95ea0416e6e3f070465d802cd42142d68d8

    thermophysicalModels: Corrected alphah to be enthalpy based

If this resolves the issue I will make the same change to OpenFOAM-4.x.


2017-05-04 09:17

reporter   ~0008079

Yes, I think the issue is now solved. Now both the sensibleEnthalpy and internalEnergy give exactly the same results for kappa and alpha and the results agree with the python test program. (provided that the same parameters, such as Cp, T, R, are used both in OF and python)


2017-05-04 09:24

reporter   ~0008080

To nitpick, the heSolidThermo calculates alpha as kappa/cpv, so it could be also changed to be kappa/cp. However, I guess for solids cp=cv and I don't know if heSolidThermo is even instantiated for internalEnergy, so this is extremely minor. Also, as there is no alphaEff, the user would need to ensure that correct alpha was used in the thermal equation in case of internalEnergy and cp!=cv.


2017-05-04 09:29

administrator   ~0008082

Last edited: 2017-05-04 09:46

View 3 revisions

Currently heSolidThermo will work with e or h because alpha = kappa/cpv (i.e. alpha(he) not alphah). If alpha is changed to be consistent with fluid thermo, alphaEff would need to be introduced to rescale alphah to alpha(he) but it would be confusing because the heat transfer is always "laminar" in a solid.


2017-05-04 09:32

reporter   ~0008083

Yes, I agree. It is just the minor discrepancy that thermo.alpha() is supposed to return "Thermal diffusivity for enthalpy of mixture", but as you said, alphaEff would be also confusing.

But to summarize, I think the patch is good and could be pushed to 4.x.


2017-05-04 12:04

manager   ~0008084

Resolved in OpenFOAM-dev by commit 7acfa95ea0416e6e3f070465d802cd42142d68d8

Resolved in OpenFOAM-4.x by commit ecc796de7661dda9225d3ff1dd53cb1aa5ac003c

Issue History

Date Modified Username Field Change
2017-04-28 11:44 pilschka New Issue
2017-04-28 11:44 pilschka File Added: BugReportSutherland.tar.gz
2017-04-28 11:44 pilschka Tag Attached: thermo
2017-04-28 11:57 henry Note Added: 0008051
2017-05-02 11:29 pilschka Note Added: 0008060
2017-05-02 11:38 henry Note Added: 0008061
2017-05-02 12:07 pilschka Note Added: 0008062
2017-05-02 12:36 henry Note Added: 0008063
2017-05-02 13:21 pilschka Note Added: 0008064
2017-05-02 13:29 henry Note Added: 0008065
2017-05-02 14:49 henry Note Added: 0008067
2017-05-03 07:20 tniemi Note Added: 0008069
2017-05-03 08:01 tniemi Note Added: 0008070
2017-05-03 15:08 henry Note Added: 0008074
2017-05-04 09:17 tniemi Note Added: 0008079
2017-05-04 09:24 tniemi Note Added: 0008080
2017-05-04 09:29 administrator Note Added: 0008082
2017-05-04 09:32 tniemi Note Added: 0008083
2017-05-04 09:46 henry Note Edited: 0008082 View Revisions
2017-05-04 09:46 henry Note Edited: 0008082 View Revisions
2017-05-04 12:04 henry Assigned To => henry
2017-05-04 12:04 henry Status new => resolved
2017-05-04 12:04 henry Resolution open => fixed
2017-05-04 12:04 henry Fixed in Version => 4.x
2017-05-04 12:04 henry Note Added: 0008084