CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (https://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   wallHeatFlux utility for an incompressible case (https://www.cfd-online.com/Forums/openfoam-post-processing/101972-wallheatflux-utility-incompressible-case.html)

Mr.Jingles May 18, 2012 10:23

wallHeatFlux utility for an incompressible case
 
Hello Foamers,
my current work is to simulate the heat transfer coefficient by a circular cylinder in cross-flow.
If i run the case with buoyantSimpleFoam (compressible & kOmegaSST) everything is fine, i can use the wallHeatFlux utility.
But if I run the case with buoyantBoussinesqSimpleFoam (incompressible & kOmegaSST) , i have several problems:

1.) How can i generate a Thermophysical model for an incompressible fluid?
I can't use hRhoThermo or icoPolynomial etc.

2.) Run the case with

hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>;

make no sense?! But OpenFoam creates in 0-directory a mut-file wich is only for compressible and writes new k and omega files with compressible wallfunctions, then it calculates for time=0 and at time=10 theres an error.

Is the utility only for compressible fluids?
And there must be a conflict between kOmegaSST and wallHeatFlux, because set RASModel laminar and the case run.

Please help me i am a newbie in CFD

regards

------------------------------------------------------------------------------
Wall heat fluxes [W]
KUGEL 3.47426

Time = 10

Selecting thermodynamics package hPsiThermo<pureMixture<constTransport<specieThermo <hConstThermo<perfectGas>>>>>
Reading/calculating face flux field phi

Selecting RAS turbulence model kOmegaSST

--> Upgrading k to employ run-time selectable wall functions
Backup original k to k.old
Writing updated k
--> Upgrading omega to employ run-time selectable wall functions
Backup original omega to omega.old
Writing updated omega
--> Creating mut to employ run-time selectable wall functions
Writing new mut
--> Creating alphat to employ run-time selectable wall functions
Writing new alphat
bounding k, min: 0 max: 1.1343e-09 average: 2.76378e-13
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#6 Foam::compressible::RASModels::kOmegaSST::F2() const in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#7 Foam::compressible::RASModels::kOmegaSST::kOmegaSS T(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::basicThermo const&, Foam::word const&, Foam::word const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#8 Foam::compressible::RASModel::adddictionaryConstru ctorToTable<Foam::compressible::RASModels::kOmegaS ST>::New(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::basicThermo const&, Foam::word const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#9 Foam::compressible::RASModel::New(Foam::GeometricF ield<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::basicThermo const&, Foam::word const&) in "/opt/openfoam201/platforms/linux64GccDPOpt/lib/libcompressibleRASModels.so"
#10
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/wallHeatFlux"
#11 __libc_start_main in "/lib/libc.so.6"
#12
in "/opt/openfoam201/platforms/linux64GccDPOpt/bin/wallHeatFlux"
Floating point exception

Mr.Jingles May 18, 2012 14:19

I have solved my first problem and added wallHeatFluxRho, now i can use hRhoThermo etc.

But my current problem is that I can't use wallHeatFluxRho or wallHeatFlux with kOmegaSST.
I tried to change pressure values from zero to 1e-12 on whole calculation field on first time step, without sucess.
as in http://www.cfd-online.com/Forums/openfoam/72534-wallheatflux-utility-openfoam1-6-a.html
In my opinion, this would solve my problem if openfoam don't calculate the first time step.
But I need a solution for the next time steps.

Nobody has an idea to solve this problem?

regards

eelcovv May 21, 2012 08:08

wallheatflux for incompressible flows
 
1 Attachment(s)
Hi,

I modified the standard wallHeatflux utility which comes default with OF into a version for incompressible flows already a while ago. Also removed a bug out of the code. Well, have a look at the code, it works for me.

One remark though: the utility does not seem to work when you use groovyBC for your temperature boundary conditions. It does not crash, but the resulting wall heat flux will not be correct. In case you want to use this utility in combination with groovyBC, you have to edit your results file T and change all groovyBC bc's into fixedValues (while leaving the non-uniform list of temperature at the wall as generated by groovyBC). Then the generated heatflux will be correct.

Eelco

gschaider May 21, 2012 17:52

Quote:

Originally Posted by eelcovv (Post 362191)

One remark though: the utility does not seem to work when you use groovyBC for your temperature boundary conditions. It does not crash, but the resulting wall heat flux will not be correct. In case you want to use this utility in combination with groovyBC, you have to edit your results file T and change all groovyBC bc's into fixedValues (while leaving the non-uniform list of temperature at the wall as generated by groovyBC). Then the generated heatflux will be correct.

That is interesting. Maybe the problem is that groovyBC is a mixed-BC. If you're using groovyBC as a pure Dirichlet-BC then you could try groovyBCFixedValue (it is in the same library). Maybe that helps

eelcovv May 23, 2012 03:53

I use groovyBC for the temperature (required for the heatFlux utility) only for setting gradients (for imposing either the wall heatflux or a heat transfer coeffcient). Is this possible via a non-mixed BC as well?

I noticed that all utilities (also the ones coming with OF) do not handle groovyBC correctly. A quick way for me to work around is is to change all type groovyBC; lines to type fixedValue;; using two ;;, such you can change it back easily. Use sed to do it quickly

sed -ie 's/groovyBC/fixedValue;/' `find [0-9]* -name T`
wallHeatFluxIncompressible
sed -ie 's/fixedValue;;/groovyBC;/' `find [0-9]* -name T`

Let me know if you want to report the bug on Mantis.
eelco

gschaider May 23, 2012 04:23

Quote:

Originally Posted by eelcovv (Post 362604)
I use groovyBC for the temperature (required for the heatFlux utility) only for setting gradients (for imposing either the wall heatflux or a heat transfer coeffcient). Is this possible via a non-mixed BC as well?

I noticed that all utilities (also the ones coming with OF) do not handle groovyBC correctly. A quick way for me to work around is is to change all type groovyBC; lines to type fixedValue;; using two ;;, such you can change it back easily. Use sed to do it quickly

sed -ie 's/groovyBC/fixedValue;/' `find [0-9]* -name T`
wallHeatFluxIncompressible
sed -ie 's/fixedValue;;/groovyBC;/' `find [0-9]* -name T`

Let me know if you want to report the bug on Mantis.
eelco

No. If you need the gradient the fixed-variant is not an option.

The problem probably is that groovyBC is not fully evaluated when being loaded. The reason is that the expression may depend on fields that are created later during startup. Also groovyBC does not force the loading of fields because it expects all fields to be in memory.

Yes. Please add a bug on the Mantis. If possible add a SMALL example case with a description of the expected result ("Heatflux on patch wall should be 666")

gschaider May 23, 2012 19:47

Quote:

Originally Posted by eelcovv (Post 362604)
I use groovyBC for the temperature (required for the heatFlux utility) only for setting gradients (for imposing either the wall heatflux or a heat transfer coeffcient). Is this possible via a non-mixed BC as well?

I noticed that all utilities (also the ones coming with OF) do not handle groovyBC correctly. A quick way for me to work around is is to change all type groovyBC; lines to type fixedValue;; using two ;;, such you can change it back easily. Use sed to do it quickly

sed -ie 's/groovyBC/fixedValue;/' `find [0-9]* -name T`
wallHeatFluxIncompressible
sed -ie 's/fixedValue;;/groovyBC;/' `find [0-9]* -name T`

Let me know if you want to report the bug on Mantis.
eelco

It occurred to me that there was a similar problem some time ago (potentialFoam does not update BCs either) and I introduced a "silent" option evaluateDuringConstruction to groovyBC (you should see it in later timesteps). Try setting
Code:

evaluateDuringConstruction true;
and see if your problem goes away

eelcovv May 24, 2012 08:31

1 Attachment(s)
Bernard,

I just tested your suggestion. Indeed setting evaluateDuringConstruction works: the correct value is obtained for external utilities.

However, I often use a field from the solver in groovyBC, for instance to use the turbulent heat diffusivity to calculate the gradT based on that. Apparently, if evaluateDuringConstruction is used, this is not allowed. If I swhich of this option the simulation runs, but erronous results for wallHeatFluxIncomressible are obtained. Replacing groovyBC with fixedValue before running wallHeatFluxIncomressible helps.

I have uploaded the bug to mantis, you can get it there. But I will also upload the case here for other people to have a look at. The wall heat flux utitlity for incompressible flows is added (it does not come with OF). I noticed that it seems that there is still something wrong with the utility, because in the turbulent case the heat flux calculate is scale with a factor rho0. Perhaps the scalign with rho is done twice somehow? Do you see what goes wrong.
Well anyway, perhaps there is a better workarround beside replacing groovyBC which also works with fields used in BC. Hope you can solve it

Regards
Eelco

gschaider May 24, 2012 10:28

Quote:

Originally Posted by eelcovv (Post 362890)
Bernard,

I just tested your suggestion. Indeed setting evaluateDuringConstruction works: the correct value is obtained for external utilities.

However, I often use a field from the solver in groovyBC, for instance to use the turbulent heat diffusivity to calculate the gradT based on that. Apparently, if evaluateDuringConstruction is used, this is not allowed. If I swhich of this option the simulation runs, but erronous results for wallHeatFluxIncomressible are obtained. Replacing groovyBC with fixedValue before running wallHeatFluxIncomressible helps.

I have uploaded the bug to mantis, you can get it there. But I will also upload the case here for other people to have a look at. The wall heat flux utitlity for incompressible flows is added (it does not come with OF). I noticed that it seems that there is still something wrong with the utility, because in the turbulent case the heat flux calculate is scale with a factor rho0. Perhaps the scalign with rho is done twice somehow? Do you see what goes wrong.
Well anyway, perhaps there is a better workarround beside replacing groovyBC which also works with fields used in BC. Hope you can solve it

Regards
Eelco

For those interested in progress on the groovy-side: https://sourceforge.net/apps/mantisb...iew.php?id=134

About kappat: this is a classic chicken/egg-problem in the solver: T is constructed first, the turbulence-field later (this is the reason why the evaluation does not happen during the initialization).

eelcovv June 1, 2012 05:00

2 Attachment(s)
For those interested: Bernard fixed a bug in groovyBC so that now it is allowed to used external applications on fields which contain groovyBC boundaries.

https://sourceforge.net/apps/mantisb...iew.php?id=134

Here I am adding the test case containing and slightly improved version of WallHeatfluxIncomressible + the test case I use to set wall heat fluxed using groovyBC. If you run the case you can see that the wall heat flux imposed is now exactly 1 W/m2 (as specified by groovyBC).

Good luck!

Regards
Eelco

stilljourney June 20, 2012 07:02

Hi eelcovv,

thanks for the utility and test case! Now I can run the test case without problem; but I met some difficulty when trying to obtain the wall heat flux. When executing WallHeatFluxIncompressible, I got:


Create time

Create mesh for time = 0

Time = 0
Reading field p



--> FOAM FATAL IO ERROR:
cannot find file

file: /home/jing/OpenFOAM/jing-2.1.0/run/testCases/hotRoomGroovyBC/0/p at line 0.

From function regIOobject::readStream()
in file db/regIOobject/regIOobjectRead.C at line 73.

Then I checked the /0 folder; there is only p_rgh rather than p there. I checked out some old threads but am still confused. Would you give me a hint on how to get an initial p file?

I'm very new to openFoam and have been learning from the forum. Thanks in advance for the help!

Best regards,
Jing

eelcovv June 26, 2012 04:55

1 Attachment(s)
Hi Jing,

The solver buoyantBoussinesqSimpleFoam uses p_rgh which is p minus the hydrostatic pressure rho*g*height. p is only later calculated and generated by the solver. So in the 0 directory it is not present yet, that's why the utility stops, because it apparently needs it. I you realy want to calculate the heat flux at time 0 (which does not make sense because the temperature field still needs to be calculated) then you can copy p_rgh to p. I actually realise that the pressure is not required for calculating the heat flux, so you can also comment out the lines in the utility that read the pressure. I checked and it works. See the new version. p is now not required anymore.

Regards
Eelco

Tiffany August 30, 2012 18:49

This is probably a really dumb question, but before I mess something up by attempting to add this, I wanted to double check I was doing it correctly. I've unpacked the file and placed it in the OpenFOAM-2.1.1/applications/utilities/postProcessing/wall directory. What should happen next?

(I apologize. I'm new to OpenFOAM, CFD, and C++. I'd really appreciate the help!)

romant August 31, 2012 04:16

Quote:

Originally Posted by Tiffany (Post 379608)
This is probably a really dumb question, but before I mess something up by attempting to add this, I wanted to double check I was doing it correctly. I've unpacked the file and placed it in the OpenFOAM-2.1.1/applications/utilities/postProcessing/wall directory. What should happen next?

(I apologize. I'm new to OpenFOAM, CFD, and C++. I'd really appreciate the help!)

There is no need to unpack this into the root directory, except if you share the openfoam with multiple users on your machine.

Unpack the the folder into your Openfoam Folder so that you have a structure like /home/user/OpenFOAM/user-2.1.1/wallHeatFluxIncompressible where user is your username. Then navigate into this folder on a terminal and just run wmake in that directory. After a short while you have a working wallHeatFluxIncompressible utility that you can use. If you can't call it in the terminal, just re source your .bashrc or just start a new terminal.

This description assumes that you installed OpenFOAM through the sources and carried out all required steps as described in http://www.openfoam.org/download/ubuntu.php

djw1 September 7, 2012 19:04

Many thanks to Eelco for the incompressible heat flux utility.
Saved my rear.

Be aware you may have to set tolerances very tightly
to get steady state heat out to equal heat in. Being converged on temperature
does not mean you are converged on the wall temp gradients.

Jack

ramon November 30, 2012 03:04

Hi eelcovv
thanks for the utility and test case!
I use chtmultiregionsimplefoam solver for incompressible fluid and solid temperature is changed each time step.
can i use your utility to calculate wallheatflux?
would you plz help me calculate nusselt number(from wallheatflux) in this case?

jorkolino July 21, 2013 20:16

Quote:

Originally Posted by eelcovv (Post 368330)
Hi Jing,

The solver buoyantBoussinesqSimpleFoam uses p_rgh which is p minus the hydrostatic pressure rho*g*height. p is only later calculated and generated by the solver. So in the 0 directory it is not present yet, that's why the utility stops, because it apparently needs it. I you realy want to calculate the heat flux at time 0 (which does not make sense because the temperature field still needs to be calculated) then you can copy p_rgh to p. I actually realise that the pressure is not required for calculating the heat flux, so you can also comment out the lines in the utility that read the pressure. I checked and it works. See the new version. p is now not required anymore.

Regards
Eelco

It compiles well, but generates wrong heatflux and gradT data on surfaces that have boundary condition of heatflux. Even though the heatflux is set to non-zero value, the utility generates only zeros. It works well on "fixed temperature" boundary conditions though.

Ed: I've coded part of the algorithm directly into the solver and it works like a charm. What is wrong with this utility then, or with OF at all, if such a utility cannot access the Temperature field of the calculated solution?! Why the same code works seamlessly when integrated into the solver? Very inconsistent.

By the way Eelco, is there any particular reason you define extra volScalarField object to write heatflux data into file? Why not use readily available heatFlux surface scalar field?

AmirBaqa1987 October 5, 2013 10:18

1 Attachment(s)
Hi Dear eelcovv

my case is incompressible and laminar .
I have changed the wallHeatFluxIncompressible, I've compiled that but when I write wallHeatFluxIncompressible at terminal,terminal says:
Code:

Create mesh for time = 0

Time = 0
Reading wallHeatFluxDict



--> FOAM FATAL IO ERROR:
cannot open file

file: /home/amir/Desktop/pipeNanoHeatSimpleFoam/constant/wallHeatFluxDict at line 0.

    From function regIOobject::readStream()
    in file db/regIOobject/regIOobjectRead.C at line 87.

FOAM exiting


can you help me please?
i've attached my wallHeatFluxIncompressible
thanks a lot.
Arjang

wyldckat October 6, 2013 11:08

Hi Arjang,

OK, I found this thread, after answering to the PM you had sent me. At first, I was going to suggest that you read this thread: http://www.cfd-online.com/Forums/ope...ltiregion.html

But from that error message, it looks like you didn't notice two very important details:
  1. The error message is clearly telling you that this file is missing:
    Code:

    /home/amir/Desktop/pipeNanoHeatSimpleFoam/constant/wallHeatFluxDict
  2. Inside the package you've provided, the file "wallHeatFluxDict" exists inside it. Therefore, it's just a matter of copying it to where the previous message was telling you to copy it to.
Best regards,
Bruno

AmirBaqa1987 October 8, 2013 02:11

Thanks Dear Bruno :)

aevub December 19, 2013 09:48

hi

Is there a example/tutorial on how to use the wallHeatFluxIncompe utility?
What should be included in the wallHeatFluxDict?

Thx!

wyldckat December 29, 2013 16:43

Greetings aevub,

Well... I had already mentioned in my previous post where a "wallHeatFluxDict" can be found:
Quote:

Originally Posted by wyldckat (Post 455311)
2. Inside the package you've provided, the file "wallHeatFluxDict" exists inside it. Therefore, it's just a matter of copying it to where the previous message was telling you to copy it to.

The package in question that you're probably looking for is in post #12.
This is because the one mentioned on the quoted post is for a modified version of the one in #12.

As for an example case... my guess is that you can use any tutorial case that uses heat transfer and uses incompressible flow.

Best regards,
Bruno

Christian1003 May 19, 2014 08:03

Hello,
i have an other problem with using the wallHeatFluxIncompressible tool. I'm computing a case with the buoyantBoussinesqPimpleFoam in OF 2.2 with k-w SST and wall-functions.
When i'm using the tool it makes the error:

--> FOAM FATAL IO ERROR:
Unknown patchField type kappatJayatillekeWallFunction for patch type wall

Valid patchField types are :
...

Sure i can change the wall function and recompute it but is there a solution with this wall-function?

thanks

wyldckat June 22, 2014 15:08

Greetings to all!

I've created a git repo for the utility wallHeatFluxIncompressible by Eelco van Vliet: https://github.com/wyldckat/wallHeatFluxIncompressible
In addition, I've adapted the code to work with OpenFOAM 2.2.x and 2.3.x.

Note: When using OpenFOAM 2.2.0, you should use the code that is meant for OpenFOAM 2.1.x, because the field names in 2.2.0 are still using the old field naming convention "kappat" and "kappaEff", while 2.2.1 and above use "alphat" and "alphaEff".


@Chris: I don't know if you've managed to solve the problem you had, but if you're using OpenFOAM 2.2.1 or 2.2.2 or 2.2.x, then try using the code from the repository I've indicated above.

Best regards,
Bruno

kmargaris October 30, 2014 06:49

2 Attachment(s)
Hi all!

I have created a simple model (attached) of natural convection inside a rectangular domain. I used the wallHeatFluxIncompressible utility to check the heat flux balance. I got the expected result, 10 W/m2 were applied to wall4 as BC and 10 W/m2 are coming out wall3 which had a constant temperature BC:

Quote:

Wall heat fluxes
wall1: Total 0 [W] over 1 [m2] (0 [W/m2])
wall2: Total 0 [W] over 1 [m2] (0 [W/m2])
wall3: Total -0.1000000647 [W] over 0.01 [m2] (-10.00000647 [W/m2])
wall4: Total 0.1 [W] over 0.01 [m2] (10 [W/m2])
floor: Total 0 [W] over 0.01 [m2] (0 [W/m2])
ceiling: Total 0 [W] over 0.01 [m2] (0 [W/m2])
However, in order to get this result I had to set rho0 equal to 1.0 in the transport properties dictionary file (attached).

Could someone explain why this is happenning?

ssss October 30, 2014 07:00

Quote:

Originally Posted by kmargaris (Post 516635)
Hi all!

I have created a simple model (attached) of natural convection inside a rectangular domain. I used the wallHeatFluxIncompressible utility to check the heat flux balance. I got the expected result, 10 W/m2 were applied to wall4 as BC and 10 W/m2 are coming out wall3 which had a constant temperature BC:



However, in order to get this result I had to set rho0 equal to 1.0 in the transport properties dictionary file (attached).

Could someone explain why this is happenning?

You are working in an incompressible case so pressure is divided by rho. But as I think Openfoam doesn't divide the pressure by your rho, so he uses rho=1 and then

Code:

surfaceScalarField heatFlux =fvc::interpolate(kappaEff*Cp0*rho0)*gradT;
rho0 should be the density of the solver so 1.

This is the only thing I can imagine that can explain it, but I'm pretty sure I'm not right.

wyldckat November 1, 2014 16:35

Greetings to all!

@kmargaris: From the files in the case you provided, I had to guess that you used the solver buoyantBoussinesqPimpleFoam.

The answer by ssss seems to be correct. More details:
Can you spot the problem?


Essentially, the inverted equation implemented in the boundary condition would be this:
Code:

q_ = gradient()*(Cp0*alphaEffp)
which clearly has no reference to "rho", hence being considered as "1.0".

I took a quick look at the compressible implementation of this boundary condition... and it's essentially the same equation, i.e.:
Code:

q_/(alphaEff*thermo.Cp)
Which means that some particular detail is being missed here... OK, it looks like the problem is in the units for "alpha":
  • incompressible "alphat" field:
    Code:

    dimensions      [0 2 -1 0 0 0 0];
  • compressible "alphat" field:
    Code:

    dimensions      [1 -1 -1 0 0 0 0];
And there you have it, the reason why "rho" is interpreted as "1.0"... although... the header file "turbulentHeatFluxTemperatureFvPatchScalarFiel d.H" clearly stated that it was assuming "alphaEff" is already in "kg/m/s"... oh my, this looks like a bug in OpenFOAM :eek:! Then again, it's more likely to be a typo in the header's comment!?

So, essentially, the problem is that the heat flux used in the boundary condition is actually "q/rho", i.e. the possibly named kinematic heat flux...


Mmm... I'll report this on the bug tracker...
edit: Bug reported at http://www.openfoam.org/mantisbt/view.php?id=1433

Best regards,
Bruno

kmargaris November 3, 2014 04:56

@wyldckat: Thanks for the explanation and for submitting the bug report.

It seems that this bug only affects the post processing; the actual heat flux boundary condition is applied correctly in this case, right?

wyldckat November 8, 2014 09:20

Hi kmargaris,

The boundary condition is incorrect. It would only be correct if Cp0 value was in fact "Cp*rho".
In other words, you can fix the problem for the boundary condition if you simply define "rho" as 1.0 and that "Cp0" is the result of "Cp*rho".

Best regards,
Bruno

hswzzz January 7, 2015 01:26

Dear wyldckat
 
@ wyldckat

hello, I tried to use your 'wallHeatFluxIncompressible' in my problem. (buoyantBoussinesqPimpleFoam with LES, oneEqEddy)
(I think my result is reasonable when I comparing the temperature and velocity with literature.)
Your utility was completely working and calculating wallHeatFlux!
When I plot the wallHeatFlux, the trend is similar with literature, however, the magnitude is totally different. (e.g. literature: 100, my case: 0.1)

Do you have any idea for this problem?

I use Cp0 =1.005, rho0=1.166

Thank you

wyldckat January 11, 2015 15:35

Greetings hswzzz,

I'm sorry to say that you haven't provided enough information in order to deduce what might be wrong.

Nonetheless, if I have to guess, since the discrepancy is at a scale of 1000, then my guess is that you were not careful enough with the units of the final mesh. OpenFOAM deals with metre by default and you probably planned for the mesh to be in millimetre.

Best regards,
Bruno

Naresh yathuru March 16, 2015 12:54

Hi Foamers,

Sorry for restarting the thread again.i am using buoyant boussinesq simpleFoam. i have read most of the threads here how to calculate wall heat flux. now i got a question may be its dumb, I have given temprature b.c on a surface patch is it now possible to find the heat flux on this patch after the simulaion?

i tired the wallheatflux command on the terminal.
can somebody help me.

Thank You.

regards,
Naresh

Naresh yathuru March 16, 2015 15:24

Hi Bruno,

I also used the turbulentHeatFluxtemperature to specify the heat flux boundary conditions for a patch and i got unphysical result. i m using buoyantboussinesqsimpleFoam. Now i understand the reason. Thanks for the explanation.

That being said is there any other posibility to specify heatFlux boundary condition for a patch?

2. i have another doubt could you please through some light on why should Cp0 should be specified as 1.0. because for TurbulenceHeatFluxTemperature B.C Cp0 is specified as 1006 though they both has the same dimensions m^2/s^2/k

This is very crucial for me right now . thank you.



regards,
Naresh Yathuru

wyldckat April 5, 2015 08:04

Greetings Naresh,

Quote:

Originally Posted by Naresh yathuru (Post 536559)
i tired the wallheatflux command on the terminal.

Installation instructions for compiling wallHeatFluxIncompressible are given here: https://github.com/wyldckat/wallHeatFluxIncompressible

Usage instructions are given in post #19.

Quote:

Originally Posted by Naresh yathuru (Post 536602)
2. i have another doubt could you please through some light on why should Cp0 should be specified as 1.0. because for TurbulenceHeatFluxTemperature B.C Cp0 is specified as 1006 though they both has the same dimensions m^2/s^2/k

This was explained in detail in the posts #27, #29 and in the bug report http://www.openfoam.org/mantisbt/view.php?id=1433

It's not "Cp0" that should be set to "1.0", it's "rho0" that should be "1.0", as already explained in post #29:
Quote:

Originally Posted by wyldckat (Post 518037)
It would only be correct if Cp0 value was in fact "Cp*rho".
In other words, you can fix the problem for the boundary condition if you simply define "rho" as 1.0 and that "Cp0" is the result of "Cp*rho".


Best regards,
Bruno

Naresh yathuru April 7, 2015 02:57

Hello bruno,

thank you so much for the reply. I have read the posts you have mentioned already. and sorry if my question was not clear. My question was concerning the wallHeatfluxIncompressible. in the readme file it says the following:

Modified version of wallHeatFlux based on suggestion of to change combustion flow to normal flows

http://www.cfd-online.com/Forums/ope...ance-flow.html

I replaced the createField with the boussinesqSimpleFoam

In this version it is required to specify values for the density, heat capacity, and Prandtl numbers in the transportProperties dictionary like
Code:

// Laminar Prandtl number
Pr              Pr [0 0 0 0 0 0 0] 0.9;

// Turbulent Prandtl number
Prt            Prt [0 0 0 0 0 0 0] 0.85;

// Cp0 value needed for wallHeatFluxIncompressible
rho0            rho0 [1 -3 0 0 0 0 0] 1.2; // this rho0

// rho0 value needed for wallHeatFluxIncompressible
Cp0            Cp0 [0 2 -2 -1 0 0 0] 1.0; // i meant this cp0

could u please through some light on this. i tried but i couldnt figure it out.

may be this is a silly question could you tell me please which value should i use for cp0 and rho0 when i use turbulentwallheatFlux B.C and if i m using the wallheatfluxincompressible utility to find the flux on the patches. should i use Cp0 = 1.0 or 1005.

Thank you,

regards,
Naresh

wyldckat April 12, 2015 16:13

Hi Naresh,

Quote:

Originally Posted by Naresh yathuru (Post 540258)
may be this is a silly question could you tell me please which value should i use for cp0 and rho0 when i use turbulentwallheatFlux B.C and if i m using the wallheatfluxincompressible utility to find the flux on the patches. should i use Cp0 = 1.0 or 1005.

You'll have to provide more details on how you originally defined your simulation case. Because you're asking about details that relate to post-processing a case I/we know nothing about.
In other words, if you don't indicate how your case was originally created and defined, I don't know how is should be handled at the end of the simulation.

Best regards,
Bruno

Naresh yathuru April 13, 2015 12:43

Quote:

You'll have to provide more details on how you originally defined your simulation case. Because you're asking about details that relate to post-processing a case I/we know nothing about.
In other words, if you don't indicate how your case was originally created and defined, I don't know how is should be handled at the end of the simulation.

Best regards,
Bruno
thanks for the reply.I am doing a indoor airflow simulation. my geometry is basically a room with inlet, outlet and an object inside.

Code:

dimensions      [0 0 0 1 0 0 0];

internalField  uniform 293; //17C

boundaryField
{
    inlet
    {
        type            fixedValue;
        value          uniform 293.15; // 20C
    }
    outlet
    {
        type            zeroGradient;
       
    }
    sideandfloorwalls
    {
        type            zeroGradient;
       
    }
    lightingwall
    {
        //type            wallHeatFlux;
        //heatFlux        uniform -200;
        // This did not work for incompressible flows. I read somewhere that this B:C does not exist in OF 230
   
        type            turbulentHeatFluxTemperature;
        heatSource      flux;
        q              uniform -200; // w/m^2 // This is just a check . this would generate a surface temperature of -27 C
        alphaEff        alphaEff;
        value          uniform 273; // place holder
    }
    /*{
        type            fixedValue;
        value          uniform 323.15; // for the time being or flux 100 w/m
    }*/
    innercube
    {
        type            zeroGradient;
        //value          uniform 313.15;
    }
    roof
    {
        type            zeroGradient;
        //value          uniform 291.15;
    }
}

This is my T B.c

and this how i specified my transport properties
Quote:

transportModel Newtonian;

// Laminar viscosity
nu nu [0 2 -1 0 0 0 0] 1.7e-05;

// Thermal expansion coefficient
beta beta [0 0 0 -1 0 0 0] 3.4482e-03; // 1/Tref

// Reference temperature
TRef TRef [0 0 0 1 0 0 0] 290;

// Laminar Prandtl number
Pr Pr [0 0 0 0 0 0 0] 0.9;

// Turbulent Prandtl number
Prt Prt [0 0 0 0 0 0 0] 0.7;

// Cp0 value needed for wallHeatFluxIncompressible
//rho0 rho0 [1 -3 0 0 0 0 0] 1.2;

// rho0 value needed for wallHeatFluxIncompressible
//Cp0 1005;

// Cp0 value needed for wallHeatFluxIncompressible
rho0 rho0 [1 -3 0 0 0 0 0] 1;

// rho0 value needed for wallHeatFluxIncompressible
Cp0 1005;

and my 0 folder has wallGradT, wallheatFlux,GradT folders as mentioned in the test case ffor the wallheatFluxincompressible.

when i use turbulentHeatFluxtemperature boundary condition i specify cp0 as 1005. but according to the read me file in the wallheatfluxincompressible it says

Quote:

// Cp0 value needed for wallHeatFluxIncompressible
rho0 rho0 [1 -3 0 0 0 0 0] 1.2;

// rho0 value needed for wallHeatFluxIncompressible
Cp0 Cp0 [0 2 -2 -1 0 0 0] 1.0;
My doubt is that, should cp0 be specified as 1.0 or can it be changed according to the case?

i m a little confused.

Thank you
Regards,
Naresh

gomsy1987 April 15, 2015 05:12

Hi Eelcovv

Can you please suggest how to use the "wallHeatFluxIncompressible" utilty file. I mean is it like just cope paste the files to the respective directory and than running the utility command from the terminal will work??

Warm regards
Gautam

Naresh yathuru April 15, 2015 05:28

Hi goutham,


I use it this way. I copy pase the respective files eg, GradT and other required files in the 0 folder before starting the simulation. after the simulation is done u can type wallHeatfluxTemperature and the patchname in yout terminal . it is basically a post processing utility.

i assume u already installed the wallHeatFluxIncompressible utility successfully and checked .

All the best.
Naresh

gomsy1987 April 15, 2015 10:13

Hi Naresh

Thanks for your reply. I just downloaded the zipfile given in this thread. After that I am not understanding if to copy the folder to "/applications/utilities" or some other steps to follow. Please help me.

Thanking you
Gautam


All times are GMT -4. The time now is 06:07.