[Shadab]

Hi, Tobi and dear community,

Thank you so much for implementing the AOA calculation for compressible flow and I am sorry for giving this late reply. Dear Tobi, I have some doubts.

1) As I am away from my system installed OpenFOAM and don't know how to use OpenFOAM on Github platform. Therefore I have not compiled the code till now. But in solveAOA function for a compressible flow, I have seen that the dimensions of the source are given as s^(-1). But I think it should be kgm^(-3)s^(-1).

2) Through CFD discussion pages and googling I learned that autoPtr and tmp are smart pointers they used for memory management and without invoking the copy constructor of class therefore to save the memory and computational time. it works by creating a pointer to a class. But still, I do not have the full knowledge about them, when and how to use them in OpenFOAM. Please suggest me some material so that I can have a command on this topic.

3) For calculation of PMV, we have seen that the Relative Humidity specified as a fixed value for the whole domain. From the ventilation study, we found that the relative humidity is a local variable and it varies a lot in a domain.
Therefore I am suggesting that we should solve a water species transport equation in addition to energy equation. From there we obtain the local partial pressure and corresponding to local temperature obtain the saturation pressure then we can obtain the Relative Humidity locally.

4) As you already discussed why can't we use local cell centered velocity instead of the whole average domain velocity and where can I find the EN ISO 7730 calculation.


Thanks & Regards:
Shadab

[Tobi]

Hi Shadab,

I moved you post into a new thread because it is more about the implemented mathematics. First of all thank you for your words and second, lets go directly to your questions:

Keep in mind I am not a civil engineer and I do not have any idea if the values we get from the library are trust able (not based on the equations - more based on the fact that I have no idea how it should be).

Humidity
If the humidity is complete different in the geometry, the results should be calculated based on a volScalarField humidity field. However, I have no time to investigate into that topic. Doing that should not be a big deal. E.g. setting up a humidity field. However, out of the box I have no idea about the functionalities of humidity based on temperature and pressure.

Saturation Pressure
As before, we could implement a local saturation pressure which is calculated based on other quantities. Right now the guy is evaluated in each cell but with a constant humidity based on the formula given there (I did not check this equation).

Velocities
As it is already in the source as a comment, I would personally use the local values instead of a averaged one. However, Thomas Tian who invented this comfort guy first did it that way. He is much more experienced in that topic than me so I kept it as it was but mentioned my doubts in the source code with the comment:

//- Stil in question. Based on EN ISO 7730 calculation done with    
//  an average velocity. However, shouldn't we use the value of each     
//  cell separately?     
Uaverage();

If one (who knows how it should be) tells me that the averaging is wrong, just let me know. Personally, I would suggest to not average the velocity and use the local magnitude.


DIN ISO 7730
You have to buy it.


Pointer
The autoPtr is a smart pointer like auto_ptr, static_ptr, dynamic_ptr as in the standard C++. The tmp<> pointer is smart enough to know how many pointers are pointing to the object. If there is no pointer pointing onto it, it will be destroyed. That was the reason why the reference:

volScalarField& muEff = turb->muEff();

Does not work. In the turb class, the object of type tmp<volScalarField> is build and sent back. Here, we do not store the pointer anymore and thats why the object will be deconstructed. You can compile it but based on the fact that the object does not exist anymore, the reference points to something which is not defined (crash). The actual implementation does take care of everything. What we have to make is to keep the object alive:

tmp<volScalarField> muEfft = turb->muEff(); 
volScalarField& muEff = muEfft();

[Shadab]

Hello Tobi,

Thanks again for answering the above questions.

The doubt with the first question is still remained, As after observing the equation of AOA for compressible flow we see that, all the terms in left hand side have a unit of kgm^(-3), while the right hand side it has a unit of sec^(-1).

According to my observation the compiler should through a dimensional inconsistency error, while compiling the library, buts its not. may be I am missing some point, please help me to understand this.

[Tobi]

No,

while constructing the matrix, we build single matrices which will be returned. In the Matrix-Construction, the units are changed and thus, the dimensions are correct. If one makes a mistake in the e.g. source term (wrong units), the calculation should give a dimension problem error (as you said). E.g.

fvScalarMatrix
(
    fvm::ddt(S)              <<< We build a new matrix and return (the units are not the units of S)
   +fvm::ddt(phi, S)         <<< We build a new matrix and return (the units are not the units of S)
  ==
   dimensionedScalar("S", dimensionSet(0,0,0,0,0,0,0), scalar(1))   <<< here we have to think about
);

-> The result of that would be:

fvScalarMatrix
( 
    tmp<fvScalarMatrix>    // returned from fvm::ddt(S)
  + tmp<fvScalarMatrix>    // returned from fvm::div(phi,S)
 ==
    dimensionedScalar(..)
);

So now you have to check out how the sum or the subtraction of a fvScalarMatrix and a dimensionedScalar is done in the class.

I would expect that at the end we have:

fvScalarMatrix
( 
    tmp<fvScalarMatrix>    // fvm::ddt(S)
  + tmp<fvScalarMatrix>    // fvm::div(phi,S)
 ==
    tmp<fvScalarMatrix>    //  dimensionedScalar(..)
);

And I can imagine that the tmp<fvScalarMatrix> that is build from the dimensionedField has different dimensions than the scalar itself.

You should be able to check it out doing the following:

fvScalarMatrix Test
(
    dimensionedScalar("foo", dimensionSet(0,0,0,0,0,0,0), scalar(1))
);

Info<< Test.dimensions() << endl;

However, if this does not work (and based on the fvMatrix class it should not work), you just have to check how the dimensionedScalar is treated inside that. Right now I would expect that the dimensionedScalar will manipulated to a matrix too. The manipulation will make the units different or the tmp<> Matrices and the dimensionedScalar are added and during that operation the dimensionedScalar will be modified in order to fit to the dimensions. I have no time to check this particular guy.

By the way: wasn't it you who asked me this question via E-Mail? I guess now it should be clear, right?

[Shadab]

Dear Tobi,

I only ask the question regarding dimensional convention in fvMatrix through mail and at that time you clear my doubts with unsteady term, convection term and Laplace term.
code:

 fvScalarMatrix AoAEqn
        (
            fvm::ddt(rho, AoA)
          + fvm::div(phi, AoA)
          - fvm::laplacian(muEff, AoA)
         ==
            dimensionedScalar
            (
                "source",
                AoA.dimensions()*dimensionSet(0,0,-1,0,0,0,0),
                scalar(1)
            )
        );

The first term has a unit of (1/delt*rhop*AOA*delV)= kg, similarly other items on left hand side also has the same unit.

The integration of constant source term has(delV*source)= m^(-3)* sec^(-1). Which is different compare to left hand side.

Forgive me if my explanation is wrong.

[Tobi]

Can you publish a short test case for compressible AoA calculations. As I said above, I build it but did not test it - do you get any dimension problems or is the calculation done without problems?

One remark. Based on your assumptions, the last term should only have m^3 because the source has s and I multiply it by 1/s.

[Shadab]

I have not run any case the with compressible AOA, but i will do now and then i will let you know.

[Tobi]

In the fvMatrix.C file you will see how the dimensionedScalar are used:

 1151 template<class Type> 1152 void Foam::fvMatrix<Type>::operator-=
 1153 (
 1154     const dimensioned<Type>& su
 1155 )
 1156 {
 1157     source() += psi().mesh().V()*su;
 1158 }
 1159

As you can see, the source has dimensions of V * su

V = m^3
su = no unit              // because the source is AoA*1/s

So actually you are right, the source gets m^3 but you see that it goes to the source() and not to the matrix. However, based on your stuff, the source as I implemented, could be of wrong units (density is missing).

[Shadab]

Dear Tobi,

yeah I understand the implementation of source term in fvMatrices. but I still have a doubt in this statement.

So actually you are right, the source gets m^3 but you have to remember that it goes to the source() and not to the matrix.

Because when i setup a simple case after the bouyantSimpleFoam solver i run the comfort foam solver and i got this error.

mechartes@MRDC-001:~/Thermal_Comfort/Solver_Development/opencomfort/tutorials/buoyantCavity$ comfortFoam > logComfort


--> FOAM FATAL ERROR:
incompatible dimensions for operation
[AoA[1 -3 0 0 0 0 0] ] == [source[0 0 0 0 0 0 0] ]

From function void Foam::checkMethod(const Foam::fvMatrix<Type>&, const Foam::dimensioned<Type>&, const char*) [with Type = double]
in file lnInclude/fvMatrix.C at line 1324.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-5.0/src/OSspecific/POSIX/printStack.C:218
#1 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/error.C:249
#2 Foam::Ostream& Foam:perator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/home/mechartes/OpenFOAM/mechartes-5.0/platforms/linux64GccDPInt32Debug/bin/comfortFoam"
#3 void Foam::checkMethod<double>(Foam::fvMatrix<double> const&, Foam::dimensioned<double> const&, char const*) at ~/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMatrix.C:1324
#4 Foam::tmp<Foam::fvMatrix<double> > Foam:perator==<double>(Foam::tmp<Foam::fvMatrix< double> > const&, Foam::dimensioned<double> const&) at ~/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMatrix.C:1573
#5 Foam:penComfort::solveAoA(Foam::GeometricField<d ouble, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&) const at ~/OpenFOAM/OpenFOAM-5.0/src/opencomfort/src/openComfort/openComfort.C:345
#6 Foam:penComfort::AoA() const at ~/OpenFOAM/OpenFOAM-5.0/src/opencomfort/src/openComfort/openComfort.C:253
#7 ? in "/home/mechartes/OpenFOAM/mechartes-5.0/platforms/linux64GccDPInt32Debug/bin/comfortFoam"
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? in "/home/mechartes/OpenFOAM/mechartes-5.0/platforms/linux64GccDPInt32Debug/bin/comfortFoam"
Aborted (core dumped)
mechartes@MRDC-001:~/Thermal_Comfort/Solver_Development/opencomfort/tutorials/buoyantCavity$

logcomfort file is also attached in zip file. Now I will try with source unit as kg/m^3 by multiplying rho on right hand side.

[Tobi]

Correct. The dimensions of the RHS should be rho*AoA as it would be in the integral form:



So the formulation should be:

          ==
             dimensionedScalar
             (
                 "source",
-                AoA.dimensions()*dimensionSet(0,0,-1,0,0,0,0),
+                AoA.dimensions()*dimensionSet(0,0,-1,0,0,0,0)*rho.dimensions(),
                 scalar(1)
             )

I resolved that problem in commit f76abc5861f620e1bd67daad693400577f87d87d
Thank you very much for the hint.

[Shadab]

The problem is resolved yet. It saying the improper way of calling the dimensioned function.

mechartes@MRDC-001:~/Thermal_Comfort/opencomfort/src/openComfort$ wclean libso
wclean libso .
mechartes@MRDC-001:~/Thermal_Comfort/opencomfort/src/openComfort$ clear

mechartes@MRDC-001:~/Thermal_Comfort/opencomfort/src/openComfort$ wmake libso
wmake libso .
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file openComfort.C
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O0 -fdefault-inline -ggdb3 -DFULLDEBUG -DNoRepository -ftemplate-depth-100 -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/TurbulenceModels/turbulenceModels/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/TurbulenceModels/incompressible/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/TurbulenceModels/compressible/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/thermophysicalModels/basic/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/transportModels -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/transportModels/incompressible/singlePhaseTransportModel -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/transportModels/compressible/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/meshTools/lnInclude -IlnInclude -I. -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude -I/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OSspecific/POSIX/lnInclude -fPIC -c openComfort.C -o Make/linux64GccDPInt32Debug/openComfort.o
openComfort.C: In member function ‘void Foam:penComfort::solveAoA(const volScalarField&, const volScalarField&, const surfaceScalarField&) const’:
openComfort.C:345:13: error: no matching function for call to ‘Foam::dimensioned<double>::dimensioned(const char [7], Foam::dimensionSet, Foam::dimensionSet, Foam::scalar)’
)
^
In file included from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:340:0,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedScalar.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/TimeState.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/Time.H:47,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dataTemplates.C:27,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/data.H:117,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMesh.H:57,
from openComfort.H:39,
from openComfort.C:25:
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:163:1: note: candidate: Foam::dimensioned<Type>::dimensioned() [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:163:1: note: candidate expects 0 arguments, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:147:1: note: candidate: Foam::dimensioned<Type>::dimensioned(const Foam::word&, const Foam::dimensionSet&, const Foam::dictionary&) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:147:1: note: candidate expects 3 arguments, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:131:1: note: candidate: Foam::dimensioned<Type>::dimensioned(const Foam::word&, const Foam::dimensionSet&, Foam::Istream&) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:131:1: note: candidate expects 3 arguments, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:114:1: note: candidate: Foam::dimensioned<Type>::dimensioned(const Foam::word&, Foam::Istream&) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:114:1: note: candidate expects 2 arguments, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:102:1: note: candidate: Foam::dimensioned<Type>::dimensioned(Foam::Istream &) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:102:1: note: candidate expects 1 argument, 4 provided
In file included from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedScalar.H:38:0,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/TimeState.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/Time.H:47,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dataTemplates.C:27,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/data.H:117,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMesh.H:57,
from openComfort.H:39,
from openComfort.C:25:
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:101:9: note: candidate: Foam::dimensioned<Type>::dimensioned(const Type&) [with Type = double]
dimensioned(const Type& t)
^~~~~~~~~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:101:9: note: candidate expects 1 argument, 4 provided
In file included from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:340:0,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedScalar.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/TimeState.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/Time.H:47,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dataTemplates.C:27,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/data.H:117,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMesh.H:57,
from openComfort.H:39,
from openComfort.C:25:
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:89:1: note: candidate: Foam::dimensioned<Type>::dimensioned(const Foam::word&, const Foam::dimensioned<Type>&) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:89:1: note: candidate expects 2 arguments, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:75:1: note: candidate: Foam::dimensioned<Type>::dimensioned(const Foam::word&, const Foam::dimensionSet&, Type) [with Type = double]
Foam::dimensioned<Type>::dimensioned
^~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.C:75:1: note: candidate expects 3 arguments, 4 provided
In file included from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedScalar.H:38:0,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/TimeState.H:38,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/Time.H:47,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dataTemplates.C:27,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/data.H:117,
from /home/mechartes/OpenFOAM/OpenFOAM-5.0/src/finiteVolume/lnInclude/fvMesh.H:57,
from openComfort.H:39,
from openComfort.C:25:
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:65:7: note: candidate: Foam::dimensioned<double>::dimensioned(const Foam::dimensioned<double>&)
class dimensioned
^~~~~~~~~~~
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:65:7: note: candidate expects 1 argument, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:65:7: note: candidate: Foam::dimensioned<double>::dimensioned(Foam::dimen sioned<double>&&)
/home/mechartes/OpenFOAM/OpenFOAM-5.0/src/OpenFOAM/lnInclude/dimensionedType.H:65:7: note: candidate expects 1 argument, 4 provided
/home/mechartes/OpenFOAM/OpenFOAM-5.0/wmake/rules/General/transform:25: recipe for target 'Make/linux64GccDPInt32Debug/openComfort.o' failed
make: *** [Make/linux64GccDPInt32Debug/openComfort.o] Error 1

I think the second line is no need to add, because third line is enough, and I also seen in error report it expecting 3 argument but given 4. Therefore I have tried with removing the second line, still the error is same.

I have another doubt, here instead of applying scalar (1) it should be multiplied with rho.

[Shadab]

The problem is resolved if we specify like this

dimensionedScalar
(
"source",
//AoA.dimensions()*dimensionSet(0,0,-1,0,0,0,0),
//rho.dimensions()*AoA.dimensions()*
dimensionSet(1,-3,0,0,0,0,0),
scalar (1)
)

But still i have one doubt should we multiply rho with one ( because one indicate Sc=1). when I try to multiply rho with scalar (1) or single rho. Then the library is not compiling , it gives the error of improper function calling.

[Tobi]

Hi,

please pull my repo:

wclean
git pull
wmake libso

I have no idea what you did but the commit I made works at least with the compilation. I do not agree to your multiplication with rho because we want to have the source to be equal to one and not one multiplied by rho. Which means for each second we want to have the source to become one more and not one*rho. E.g. (no convection no diffusion)




However, now I am even a bit confused :P
I need some time to think about that. Thanks for the discussion.

[Tobi]

Summary. You were right with almost everything.

• The form as it is in the mathematical way has to be used
• That means the value has to be multiplied by the density
• I added a new test case for compressible solvers in order to show that everything is correct with the AoA (0.2m with 0.02 m/s -> AoA = 10 s but only if the density is included).

Thanks for the discussion. I am going to amend the last commit. For completeness:

       fvScalarMatrix AoAEqn
        (
            fvm::ddt(rho, AoA)
          + fvm::div(phi, AoA)
          - fvm::laplacian(muEff, AoA)
         ==
            dimensionedScalar
            (
                "source",
                AoA.dimensions()*dimensionSet(0,0,-1,0,0,0,0),
                scalar(1)
            )*rho
        );

[Tobi]

I made some stupid git things but now it should be fine with the commit 87209dc
I also put the new tutorial in.

Let me know if there is some mistake.

[Shadab]

Hello Tobi,

I have checked the comfortFoam solver for compressible flow in laminar and turbulent case. In both cases it is running fine and thank you so much for your cooperation.

Actually i want to cross check the PMV and PPD equation. When I compare the equations from the given below website with the equations implemented in code, I observe some changes. Therefore, It will be nice if you can provide me the equations for PMV and PPD.

The website link:

https://sustainabilityworkshop.autod...hermal-comfort

I am not able to obtain the expressions given in reference of the page.

[Tobi]

Hi,

the equations given in the website you refer to are not in correlation to the norm I have. I do not know if they also made mistakes (e.g. first term, e^( ) -> is exp in the new version 2005). The library I build is based on ISO 7730:2005. The link provides information of a 20 years older ISO norm.

To check it, you need the reference.