[braennstroem]

Hi,
after a long battle with ICEM I finally could produce a mesh, which I could import in OpenFOAM (fluent-format).

I cloned 'buoyantFoam', deleted the old mesh and imported the new one. Now, I get opening and saving an error-message like: 'Non-optional dictionary entry 'AlphaEps' not found in dictionary .../turbulenceProperties::LRRCoeffs start at line 70 ending at line 78 ... Do you want to edit ...'

I get the same message with the original 'buoyantFoam'. Do I have to adjust anything?

Furthermore I wonder how I could get a zeroGradient-pressure bc for the outlet. I just read 'http://www.cfd-online.com/OpenFOAM_D...ges/1/437.html'; so it does not seem to exist yet!?

And one last question (for now :-)). Where can I find the wall-functions which are used together with the 'wallFunctions' boundary conditions?

Maybe, you have any hints!?

Best Greetings!
Fabian

[hjasak]

Heya,

Try running the code from the command line - there may be a problem with config files + you will get a more sensible error message.

Hrv

[braennstroem]

Hi,

thanks. Running from the commandline works fine for the default kepsilon model, it just complains when using the LRR or LaundnerGibbson models; there are missing 'AlphaEps,AlphaR'. Just adding those does not work in a way that the gui does not complain anymore, but it doesn't run.

You get:

--> FOAM FATAL IO ERROR : keyword laplacian(mut,U) is undefined in dictionary "/home/fab/OpenFOAM/fab-1.1/run/tutorials/buoyantFoam/hotRoom/system/fvSchemes:: laplacianSchemes"

file: /home/fab/OpenFOAM/fab-1.1/run/tutorials/buoyantFoam/hotRoom/system/fvSchemes::l aplacianSchemes from line 59 to line 65.

Function: dictionary::lookupEntry(const word& keyword) const
in file: db/dictionary/dictionary.C at line: 148.


Fabian

[hjasak]

OK, all you need to do now is to keep adding the entries the code complains about into the appropriate dictionary sections and all will be well.

In this case, add:

laplacian(mut,U) Gauss linear corrected;

into the laplacianSchemes section in hotRoom/system/fvSchemes

Good luck,

Hrv

[braennstroem]

That looks pretty easy, thanks!

Now, I did a test run with my new mesh with kepsilon for 10 simulation-seconds; there was no problem at all. Afterwards I changed the inlet-velocity from 2.0 to 0.15 and enlarged the simulation time to 100; I get:

Reading thermophysical properties

Selecting thermodynamics package hThermo<puremixture<consttransport<speciethermo<hc onstthermo<perfectgas>>>>>


--> FOAM FATAL ERROR : Not implemented

Function: defaultFvPatchField<type>::defaultFvPatchField(con st fvPatch& p, const Field<type>& iF)
in file: fields/fvPatchFields/basicFvPatchFields/default/defaultFvPatchField.C at line: 52.

Do you have one more hint what that means?

Fabian

[hjasak]

OK, this is a pretty new trick that requires some care. Here's what happens.

For post-processing purposes, foam now implements a special "default" kind of patch field. When a code attempts to read in a geometric field and hits a patch field (this is a virtual class hierarchy) that it does not know about, it will create a default patch type field. This patch field does not know how to evaluate itself, only to look at its value (which is read from the file), but for post-processing this does not matter.

In your case, the solver has started and hit a patch field type which it does not recognise. As a consequence, it created a "default" patch field; however, this is a solver and it tried to do an operation for this patch field, but it is not implemented! Hence the error :-)

What you should do is look at the patch fields (boundary conditions) for the fields you are trying to work with and figure out which one has gone wrong. In my version of foam I have put s small warning message into:

fields/fvPatchFields/basicFvPatchFields/default/defaultFvPatchField.C

which tells me when this patch field is created (+ some debug info) and makes debugging easier. It is possible that the thermodynamics package is doing some field read for you as well; try unlimiting coredumpsize and tracing back the core dump.

Good luck,

Hrv

[braennstroem]

Thanks, but I am little bit confused about those patch fields. How can they appear when I just change the 'endtime' and the 'inlet-velocity'?

Even when I change those setups back to the one which worked before, I get the same error message!?

Would you mind sending me your mentioned 'debug-info' addition?

Regards!
Fabian

[hjasak]

I've put the following:

Info << "Creating defaultFvPatchField for patch " << p.name() << endl;


into: OpenFOAM-1.1/src/OpenFOAM/lnInclude/defaultFvPatchField.C, line 116.

As for the other part of your comment (I don't want to be rude, sorry), it sounds like the "I haven't changed anything" syndrome. If the code really breaks where it should not, could you please prepare a little example for me (code + case) and I will debug it + tell you exactly what happens.

Ideally, I would be grateful if you could reproduce the error with one of the standard codes and a (modified?) tutorial case. It would also be worth while checking that you have done everything right before I start working on it.

Regards,

Hrv

[braennstroem]

Thanks! It's compiling...

You are right it sounds like 'haven't changed anything' syndrome; I will do some more investigations on the two cases (tutorial and my cloned modified one)...
if that doesn't help I would like to make a small example. What does 'code + case' mean? Wouldn't it be enough to prepare the case; I thought that I didn't change anything in the code yet?

Fabian

[hjasak]

I always assume people have changed both the code and case - this is typical for FOAM users. If you haven't changed the code, just let me know and I'll use the standard one; if the case is a tutorial, a short E-mail describing what parameters you've changed and how would be sufficient.

In any case, I would be grateful to you and anyone else sending "code + case" to have a look at the guidelines on how to do it: get rid of unnecessary *.o and other files, run wclean, throw the mesh away if blockMesh is used, get rid of unnecessary result files etc.

Hrv

[braennstroem]

Hi,

I just talk to my supervisor; there is a chance putting the files on our ftp-server.
This is probably the best alternative!?

Greetings!
Fabian

[hjasak]

No need - I have reproduced the error.

There were several problems:
1) if you use fixedValue boundary conditions on the temperature, and try and run the LRR turbulence model, it fails with the error in dimensions. This is because the dimensionSet for R in the hotRoom tutorial is wrong. It should say:

dimensions [0 2 -2 0 0 0 0];

(bug fix submitted)

2) the second error is to do with the wallFixedHeatFlux b.c. In basicThermo.C, line 48, the boundary types for h are chosen and that one does not know what to do with the what heat flux b.c. The traceback is below + I need to think about this because there's no simple and general solution.

Here's the trace-back:

coyote*110-> gdb buoyantFoam /home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support hotRoom
Excess command line arguments ignored. (hotRoom)
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

"/home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support" is not a core dump: Is a directory
(gdb) r /home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support hotRoom
Starting program: /home/coyote/hjasak/OpenFOAM/OpenFOAM-1.1/applications/bin/linuxDebug/buoyantFoa m /home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support hotRoom
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 30239)]
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.1 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : /home/coyote/hjasak/OpenFOAM/OpenFOAM-1.1/applications/bin/linuxDebug/buoyantFoa m /home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support hotRoom
Date : May 16 2005
Time : 23:32:20
Host : coyote
PID : 30239
Root : /home/coyote/hjasak/OpenFOAM/hjasak-1.1/run/support
Case : hotRoom
Nprocs : 1
Create time

Create mesh for time = 0


Reading environmentalProperties
Reading thermophysical properties

Selecting thermodynamics package hThermo<puremixture<consttransport<speciethermo<hc onstthermo<perfectgas>>>>>
Creating defaultFvPatchField for patch floor


--> FOAM FATAL ERROR : Not implemented

Function: defaultFvPatchField<type>::defaultFvPatchField(con st fvPatch& p, const Field<type>& iF)
in file: fields/fvPatchFields/basicFvPatchFields/default/defaultFvPatchField.C at line: 52.

FOAM aborting


Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 30239)]
0x40db2b71 in kill () from /lib/i686/libc.so.6
(gdb) where
#0 0x40db2b71 in kill () from /lib/i686/libc.so.6
#1 0x40d40cf1 in pthread_kill () from /lib/i686/libpthread.so.0
#2 0x40d4100b in raise () from /lib/i686/libpthread.so.0
#3 0x40db2904 in raise () from /lib/i686/libc.so.6
#4 0x40db3e8c in abort () from /lib/i686/libc.so.6
#5 0x405fa291 in Foam::error::abort (this=0x40c17b60) at error.C:224
#6 0x080723a9 in Foam::operator<<> (os=@0x80f3208, m={fPtr_ = {__pfn = 0x405fa022 <foam::error::abort()>, __delta = 0}, err_ = @0x40c17b60}) at errorManip.H:85
#7 0x407d7ae3 in defaultFvPatchField (this=0x82579f8, p=@0x81c7510, iF=@0x824d2ac) at defaultFvPatchField.C:48
#8 0x407d7967 in Foam::fvPatchField<double>::addpatchConstructorToT able<foam::defaultfvpatchfield <double> >::New (p=@0x81c7510, iF=@0x824d2ac) at fvPatchField.H:105
#9 0x0808e2cf in Foam::fvPatchField<double>::New (patchFieldType=@0x825122c, p=@0x81c7510, iF=@0x824d2ac) at newFvPatchField.C:80
#10 0x0808256a in GeometricBoundaryField (this=0x824d300, bmesh=@0xbfffcfc0, field=@0x824d2ac, patchFieldTypes=@0xbfffb190) at GeometricBoundaryField.C:116
#11 0x4022c007 in GeometricField (this=0x824d270, io=@0xbfffb120, mesh=@0xbfffc6f0, ds=@0xbfffb150, patchFieldTypes=@0xbfffb190) at GeometricField.C:183
#12 0x4022cabd in hThermo (this=0x824ce88, mesh=@0xbfffc6f0) at hThermo.C:58
#13 0x4022c8e8 in Foam::basicThermo::addfvMeshConstructorToTable<foa m::hthermo<foam::puremixture<f oam::consttransport<foam::speciethermo<foam::hcons tthermo<foam::perfectgas> > > > > >::New (mesh=@0xbfffc6f0) at basicThermo.H:88
#14 0x402298eb in Foam::basicThermo::New (mesh=@0xbfffc6f0) at basicThermo/newBasicThermo.C:78
#15 0x0806c585 in main (argc=3, argv=0xbfffd2d4) at createFields.H:6
(gdb) k
Kill the program being debugged? (y or n) y
(gdb) q

The actual problem is located in:

OpenFOAM-1.1/src/thermophysicalModels/basic/basicThermo/basicThermo.C, line 49

Please submit this as a bug report (code = buoyantFoam, case = hotRoom tutorial + wallFixedHeatFlux b.c. instead of fixedValue on T)

Hrv

[braennstroem]

Thanks for the investigations! I submitted the bug report.

Fabian

[braennstroem]

Hi,
like you said it is a bug, but I am trying to get back the configuration which I had when it was working. I still think that I did not change the bc for the fixedHeatFlux at the cylinders (like written above :-).
Now, I tested it with a fixed temperature at the cylinders... it runs, but stops due to exceeding the iteration limit of 1000 in the second step; strange!?

Regards!
Fabian

[coops]

Hello All,

I am looking at the buoyantFOAM solver and wish to edit it. I see that pRef is set within the model. Is it possible to do away with this? I need to have an height varying pressure profile and I can't see how pRef will work in this case.

Is this possible to do? I need to enure hydrostatic equilibrium and previously I have had trouble with this and thought a buoyancy model may be more appropriate. (I also have a height varying temperature profile and calculate rho using the ideal gas law!)

Thanks in advance,

Shaun

[coops]

Hello all,

I have been looking at the buoyantFoam code and I have a question.

In createFields.H a volScalarField called pd

pd == p - rho*gh - pRef

therefore:

p = pd + rho*gh + pRef

Now turning to UEqn.H I see:

solve(UEqn == -fvc::grad(pd) - fvc::grad(rho)*gh)

This is the part that is confusing me. I appears that the gradient of p has been taken and this is then used in UEqn.H.

However, using p = pd + rho*gh + pRef,

-grad(p) = -grad(pd) - grad(rho*gh) - grad(pRef)

grad(pRef) = 0 as it is simply a value, thus

-grad(p) = -grad(pd) - grad(rho*gh)

-grad(p) = -grad(pd) - rho*grad(gh) - grad(rho)*gh

However, the the middle term (-rho*grad(gh)) is not in the UEqn.

Can someone help me understand why this term is not there!

Thanks

Shaun

[david_h]

Shaun,

The middle term is the body force term:
-rho grad(gh) = -rho grad ( g.x ) = - rho grad(g).x - rho g . grad(x) = - rho g

since for this application "g" is constant vector

Dave

[hartinger]

grad(gh) = grad(g & mesh.C())
results in a constant gradient for a uniform mesh in direction of g

so, for the moment i share shaun's confusion

markus

[david_h]

It might be clearer in indicial notation:

d(g_i x_i)/d(x_j) = g_i d(x_i)/d(x_j) + d(g_i)/d(x_j) x_i = g_i delta_{ij} + 0 x_i = g_j

[hartinger]

the momentum equation without buoyancy:
LHS = -grad(p)

with buoyancy:
LHS = -grad(p) + rho g

forgot about that little detail, the two "rho g" cancel out

thanks david