CFD Online Discussion Forums - Poiseuille's inlet velocity profile

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM (https://www.cfd-online.com/Forums/openfoam/)

- - Poiseuille's inlet velocity profile (https://www.cfd-online.com/Forums/openfoam/70700-poiseuilles-inlet-velocity-profile.html)

Poiseuille's inlet velocity profile

Hello colleagues!
I need to set non-uniform boundary inlet velocity profile (e.g. parabolic, Poiseuille's law). Please explain me, how to do it.

Best regards, Aleksey.

Aleksey,

If you look at the incompressible/simpleFoam/pitzDailyExptInlet tutorial, that gives you a pretty easy way to set a parabolic profile. You change the points file in /constant/boundaryData/inlet to the points you need for your mesh, then change the U file in the /constant/boundaryData/inlet/0 directory to set a parabolic profile to match your points. The tutorial has a parabolic profile. I have used this method to make a log law profile.

There are many other methods described in the forums - this one is quite simple, and it works.

Good luck, Alan

Now I have a new question.
I try to make my own patch for entering boundary conditions. I've analyzed source code of some patches and I think I can do what I want.
BUT! How to make OpenFOAM solvers to use it. I mean, how to compile new patch and insert it to program?
Please, help me with problem.
Best regards, Aleksey.

Take a look at the GroovyBC created by Bernhard. It is often much more convenient than writing your BC for each case. You can find it here on the wiki:

http://openfoamwiki.net/index.php/Contrib_groovyBC

About using your BC, simply build it with

wmake libso

and then add a line as

libs ( "libOpenFOAM.so" "libgroovyBC.so" ) ;

to your controlDict, replacing libgroovyBC.so with the library corresponding to your BC.

Best,

Thank you very much, Alberto!

simpleFoam Blows up with Parabolic Inlet Pipe Flow

Hi Alberto,

I have read lots and lots of your posts and they have helped me greatly with learning how to use OpenFOAM.

However, Now I am running into a wall again - (it doesn't hurt that much after the thousandth times). I'm hoping you could help me.

I am simulating a pipe with sudden expansion with a parabolic inlet velocity using simpleFoam - see attached.

The simulation started with laminar for 2000 iterations (residuals flat off after this) - solution attached.

Quote:

Centreline Inlet Velocity is 0.178 m/s. Re_D=40,750.
GroovyBC was used to set the parabolic inlet velocity profile.

Then I restarted the simulation using RNGKEpsilon model.
The simulation crashed after 2 iterations! Consistently.
Error message indicate divide by zero problem for k and epsilon (See below).

Please NOTE that if I use NON-parabolic inlet (i.e. fixedValue), everything is fine - I got a good converged solution.

I used Upwind Div scheme with cellLimited interpolation scheme.
I have tried both PCG and GAMG for pressure, and PBiCG and GAMG for U|k|epsilon.
I have also tried varying URF.

I suspect the problem is in my BCs and bad starting solution for k and epsilon (since the flow is now parabolic from the inlet).
But, I can't figure out. I've also tried setting parabolic inlet profiles for k and epsilon to no avail.

Please help!.

My 0/epsilon:

Code:

inlet

    {

        type            turbulentMixingLengthDissipationRateInlet;

        mixingLength    0.05;

        value           uniform 1e-06;  //Estimated based on TurbIntensity of 5% at inlet and 0.05m eddy length scale

    }

My 0/k:

Code:

inlet

    {

        type            turbulentIntensityKineticEnergyInlet;

        intensity       0.05;

        value           uniform 0.0001;  //Estimated based on TurbIntensity of 5% at inlet and 0.05m eddy length scale

    }

Thank you very much.
I hope I do get any help this time.
Please.. It's quite difficult to get help from this forum.

Regards,
Stefano

Code:

Time = 2



DILUPBiCG:  Solving for Ux, Initial residual = 0.00855909, Final residual = 7.45812e-10, No Iterations 17

DILUPBiCG:  Solving for Uy, Initial residual = 0.0467024, Final residual = 6.71306e-10, No Iterations 17

DILUPBiCG:  Solving for Uz, Initial residual = 0.0490525, Final residual = 5.95911e-10, No Iterations 18

GAMG:  Solving for p, Initial residual = 0.192423, Final residual = 8.18271e-11, No Iterations 40

GAMG:  Solving for p, Initial residual = 0.0344647, Final residual = 6.74495e-11, No Iterations 35

GAMG:  Solving for p, Initial residual = 0.0101951, Final residual = 7.61577e-11, No Iterations 32

time step continuity errors : sum local = 8.98665e-13, global = 1.02105e-14, cumulative = 6.25679e-15

[4] #0  Foam::error::printStack(Foam::Ostream&) in  "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libOpenFOAM.so"

[4] #1  Foam::sigFpe::sigFpeHandler(int) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libOpenFOAM.so"

[4] #2  __restore_rt at sigaction.c:0

[4] #3  Foam::divide(Foam::Field<double>&,  Foam::UList<double> const&, Foam::UList<double>  const&) in  "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libOpenFOAM.so"

[4] #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  "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libincompressibleRASModels.so"

[4] #5  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField,  Foam::volMesh> > Foam::operator/<Foam::fvPatchField,  Foam::volMesh>(Foam::tmp<Foam::GeometricField<double,  Foam::fvPatchField, Foam::volMesh> > const&,  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>  const&) in  "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libincompressibleRASModels.so"

[4] #6  Foam::incompressible::RASModels::RNGkEpsilon::correct() in  "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linux64GccDPOpt/libincompressibleRASModels.so"

[4] #7  main in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/applications/bin/linux64GccDPOpt/simpleFoam"

[4] #8  __libc_start_main in "/lib64/libc.so.6"

[4] #9  Foam::regIOobject::writeObject(Foam::IOstream::streamFormat,  Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in   "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/applications/bin/linux64GccDPOpt/simpleFoam"

Try a few things:

Start with a uniform initial condition. Does the behavior change?
Use fixedValue conditions for k and epsilon at the inlet.
Try a different turbulence model (standard k-epsilon, or, better, the realizable k-epsilon).

Best,

Hi Alberto,

That is a super quick reply! Thank you :)

I'm trying your suggestions #1 and #3 at the same time.
It runs fine (up to 10 iterations now).

I'll try running this to convergence, then change the inlet BC to parabolic velocity.

Do you think I need to change the k and epsilon BCs to parabolic at the inlet as well?
I think this would be wrong since k and epsilon does not vary linearly with velocity.

So, I think the problem was in the large difference between the k and epsilon initial guesses and the parabolic velocity inlet?

Thanks again.
I'll let you know how it goes.

Kind Regards,
Stefano

Just wondering now, how do I change the inlet BC during runtime or after nth iterations?

Quote:

Originally Posted by swahono (Post 286298)

Do you think I need to change the k and epsilon BCs to parabolic at the inlet as well?
I think this would be wrong since k and epsilon does not vary linearly with velocity.

So, I think the problem was in the large difference between the k and epsilon initial guesses and the parabolic velocity inlet?

I would not bother using a parabolic profile with a RANS simulation to be honest. Start with a flat profile, and eventually make the inlet a bit longer. Or use something closer to a turbulent profile.

Best,

Hi Alberto,

I apologise to swamp your email address.
I have misread your post.

I have tried starting the calculation from uniform field before.
The behaviour was exactly the same (crashed on the 2nd iteration).

What I'm trying now is running with tophat inlet velocity, and change BC after nth iterations.

So, I guess back to square one :(

Sorry.

Any idea?

Thank you.

Kind Regards,
Stefano

Quote:

Originally Posted by alberto (Post 286300)

Could you please elaborate more why this is the case?
I have done lots of simulations with flat profile on this geometry, and I thought of comparing the results if the inlet pipe flow is "fully developed".

What do you mean by "turbulent profile"?

Thank you.

Kind Regards,
Stefano

Quote:

Originally Posted by swahono (Post 286303)

The problem is that a parabolic profile is not fully developed for a turbulent flow (there are empirical profiles for turbulent flows in the literature).

Btw, you said Re = 750. Strictly speaking, you are in the transition region (not fully developed), and you should use a low-Re model (I am sorry, I just noticed your Re) like Launder-Sharma-KE. You will need a good resolution of the boundary layer.

Hi Alberto,

Quote:

Originally Posted by alberto (Post 286306)

The problem is that a parabolic profile is not fully developed for a turbulent flow (there are empirical profiles for turbulent flows in the literature).

I have tested running the simulation with a 1/7th power law turbulent BL inlet velocity profile for fully developed pipe flow (BL thickness = Radius of Pipe). The same blow up of epsilon occured.

I used the U/Uc = pow((1-r/rc),1/7) velocity profile at inlet (set using groovyBC).

Then I used 'applyBoundaryLayer' tool to calculate the initial guess of epsilon distribution near wall, with yBL = rc (pipe radius). In fully-developed turbulent pipe flow, the BL thickness is equal to the pipe radius.

>> applyBoundaryLayer -ybl 0.665 -writenut

The run (epsilon) blew up after 3 iterations - division by zero problem (I think).
Strangely, the k and epsilon residuals in the last iteration before blew up were 1e-06 and 0.7 respectively.

Quote:

Originally Posted by alberto (Post 286306)

Btw, you said Re = 750. Strictly speaking, you are in the transition region (not fully developed), and you should use a low-Re model (I am sorry, I just noticed your Re) like Launder-Sharma-KE. You will need a good resolution of the boundary layer.

No, The Re_D is 40750 based on pipe diameter. So it is well in the turbulent regime.

I am really not sure what is causing the numerical error at this stage, any idea?:(:confused:

Has anyone encountered this problem when simulating pipe flow with a 'fully-developed' inlet BC? Surely someone has done this before - at least for constant cross-section pipe.

Kind Regards,
Stefano

Quote:

Originally Posted by swahono (Post 286440)

No, The Re_D is 40750 based on pipe diameter. So it is well in the turbulent regime.

Sorry, I misread.

Quote:

Has anyone encountered this problem when simulating pipe flow with a 'fully-developed' inlet BC? Surely someone has done this before - at least for constant cross-section pipe.

Could you post a simple case reproducing the problem?

Best,

Quote:

Originally Posted by alberto (Post 286551)

Could you post a simple case reproducing the problem?

Hi Alberto,

I have emailed you the case to your gmail email address.
The case was too large to attach in this forum (3MB) since max allowed attachment is 97KB. The mesh size has been reduced significantly - it's a coarse mesh with only 100000 cells.

Thank you so much for your kind help.

Kind Regards,
Stefano

Hi,

after how many iterations should it crash? :-)

It looks like it is happily converging on my workstation. I modified the linear solver settings slightly, but I don't think that's the reason...

Hints:

p at inlet: zeroGradient. You specify U already.
Relaxation factors for k and epsilon: 0.4
Tolerance for p in linear solvers: 10^-8 (or 10^-10). Anyway, at least one order of magnitude lower than the rest. Use GAMG to reduce the iterations.
The numerical schemes look a bit weird. Do you want to use first-order upwind (which is what you are using)?
- You apply a limiter also to grad(p). Avoid if possible.
Final suggestion: that geometry could be meshed very easily with a fully hex mesh, which would improve convergence. Project the small pipe, and mesh the section with a "pave" mesh. Then project that mesh along the small pipe. The external part has a section that can be mapped: you simply have to specify the proper number of nodes on the external circumference. A hex mesh could reduce your computational time too: less cells, better convergence.

What version of OpenFOAM are you running?

Best,

Quote:

Originally Posted by alberto (Post 286645)

after how many iterations should it crash? :-)

It looks like it is happily converging on my workstation. I modified the linear solver settings slightly, but I don't think that's the reason...

What version of OpenFOAM are you running?

Thanks heaps for trying running the case and tidying up my setup.
I tried running your modified case as it is, and the exact same bizarre behavior happened.. It crashed on the second iterations on my machine (I was running it serial) - See below log printout.

And I have tested running it on 2 different workstations (one running Ubuntu, the other running Fedora). No difference in outcome.

I'm using OpenFOAM 1.7.0. This is most extraordinary.
What version of OpenFOAM are you using?

Do you have any idea of what may be the problem?
I'm really lost .. even on how to debug it now.
Seems the problem is on the OpenFOAM setup on my workstation.

Could you suggest anything?
I really appreciate your help and suggestions.

Kind Regards,
Stefano

Code:

Create time



Create mesh for time = 0



Reading field p



Reading field U



Reading/calculating face flux field phi



Selecting incompressible transport model Newtonian

Selecting RAS turbulence model realizableKE

realizableKECoeffs

{

    Cmu             0.09;

    A0              4;

    C2              1.9;

    sigmak          1;

    sigmaEps        1.2;

}





Starting time loop



Time = 1



smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 3.59393e-08, No Iterations 24

smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 3.23144e-08, No Iterations 20

smoothSolver:  Solving for Uz, Initial residual = 1, Final residual = 8.44441e-08, No Iterations 18

GAMG:  Solving for p, Initial residual = 1, Final residual = 9.59021e-09, No Iterations 93

GAMG:  Solving for p, Initial residual = 0.490638, Final residual = 8.86246e-09, No Iterations 57

GAMG:  Solving for p, Initial residual = 0.0631056, Final residual = 9.40724e-09, No Iterations 53

time step continuity errors : sum local = 1.00658e-09, global = 5.77004e-11, cumulative = 5.77004e-11

smoothSolver:  Solving for epsilon, Initial residual = 0.569468, Final residual = 1.03889e-08, No Iterations 10

smoothSolver:  Solving for k, Initial residual = 1, Final residual = 5.21329e-09, No Iterations 12

bounding k, min: 0 max: 0.0851712 average: 0.000115257

ExecutionTime = 13.64 s  ClockTime = 14 s



Time = 2



smoothSolver:  Solving for Ux, Initial residual = 0.546612, Final residual = 4.7862e-08, No Iterations 24

smoothSolver:  Solving for Uy, Initial residual = 0.409151, Final residual = 3.74731e-08, No Iterations 22

smoothSolver:  Solving for Uz, Initial residual = 0.410256, Final residual = 2.61424e-08, No Iterations 22

GAMG:  Solving for p, Initial residual = 0.173568, Final residual = 7.41398e-09, No Iterations 37

GAMG:  Solving for p, Initial residual = 0.0556567, Final residual = 8.85002e-09, No Iterations 25

GAMG:  Solving for p, Initial residual = 0.0104717, Final residual = 9.56729e-09, No Iterations 24

time step continuity errors : sum local = 2.40749e-09, global = -3.52641e-11, cumulative = 2.24363e-11

#0  Foam::error::printStack(Foam::Ostream&) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/libOpenFOAM.so"

#1  Foam::sigFpe::sigFpeHandler(int) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/libOpenFOAM.so"

#2  Uninterpreted: 

#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/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 "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/libincompressibleRASModels.so"

#5  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/libincompressibleRASModels.so"

#6  Foam::incompressible::RASModels::realizableKE::correct() in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/lib/linuxGccDPOpt/libincompressibleRASModels.so"

#7  

 in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/applications/bin/linuxGccDPOpt/simpleFoam"

#8  __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"

#9  

 in "/home/stefano/OpenFOAM/OpenFOAM-1.7.0/applications/bin/linuxGccDPOpt/simpleFoam"

Floating point exception

Hi Stefano,

I use OpenFOAM 1.7.x, running it in serial mode. I would suggest you to

Update to 1.7.x, or at least to 1.7.1. (Since you use tet meshes, 1.6-ext brings some nice improvement, so you might want to consider it in the future)
Run the case with an unmodified simpleFoam, if you changed the code.

Additionally, what compiler are you using?

Best,

Good day, Alberto!

I have just built OF 1.7.1 on my machine, and run unmodified simpleFoam on the case. The exact same thing happened - crashed on the 2nd iter - exact same error msg.

I'm using gcc 4.4.3.

Actually, does the error msg look meaningful to you?
Can we decipher this error message?

Code:

#0  Foam::error::printStack(Foam::Ostream&) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.1/lib/linuxGccDPOpt/libOpenFOAM.so"

#1  Foam::sigFpe::sigFpeHandler(int) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.1/lib/linuxGccDPOpt/libOpenFOAM.so"

#2  Uninterpreted: 

#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/stefano/OpenFOAM/OpenFOAM-1.7.1/lib/linuxGccDPOpt/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 "/home/stefano/OpenFOAM/OpenFOAM-1.7.1/lib/linuxGccDPOpt/libincompressibleRASModels.so"

Does it perhaps got to do with my groovyBC? :confused:
If it's not too much of a hassle for you, could you please email me your groovyBC source code. I may have a corrupted version?

Thank you, Alberto! :)

I very much appreciate it.

Kind Regards,
Stefano

Quote:

Originally Posted by swahono (Post 286834)

Actually, does the error msg look meaningful to you?
Can we decipher this error message?

It looks like a division by zero in the turbulence model...

I used this version:

Code:

svn checkout https://openfoam-extend.svn.sourcefo...aries/groovyBC

Best,
Alberto

Thank you, Alberto.

Unfortunately I can't use SVN at work computer due to a proxy. I downloaded the groovyBC source code through the web portal.
I'll try downloading it later.

Thanks again for all your help.

Kind Regards,
Stefano

Quote:

Originally Posted by swahono (Post 287300)

Thank you, Alberto.

Unfortunately I can't use SVN at work computer due to a proxy.

You find it here:

http://dl.dropbox.com/u/659842/groovyBC.tar.gz

Notice that you might have to run wclean before wmake, since it was built on my machine.

Where do I send the bill? :D

Best,

Quote:

Originally Posted by alberto (Post 287308)

You find it here:

http://dl.dropbox.com/u/659842/groovyBC.tar.gz

Notice that you might have to run wclean before wmake, since it was built on my machine.

Wow.. that's very kind of you! I was going to use my home machine to get the code using SVN.

Quote:

Originally Posted by alberto (Post 287308)

Where do I send the bill? :D

What is your hourly rate?
You can send it to the Australian Govt (my employer) :D
What I can do to repay you is to pass everything I've learned about OF on to other people who are in the same position as me - struggling with OpenFOAM.

Ok, I have re-made your groovyBC
wclean
wmake libso

It returned errors (see error msg below), but I think it still compiled the library.
- I may have gotten the same error message before, but ignored it because the library and BC type is still recognized by OpenFOAM despite the compilation error msg. -

I checked both the GCC version and bison version installed on my machine is as required by groovyBC
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
bison (GNU Bison) 2.4.1

The simulation still crashed on the second iteration using your copy of the newly compiled groovyBC. :(

Just wondering if you had the same error msg (-See below) as me when you compiled the groovyBC on your machine?

Thanks, Alberto! :)

Kind Regards,
Stefano

The compilation error msg:

Code:

$ wmake libso

Making dependency list for source file PatchValueExpressionParser.yy

Making dependency list for source file PatchResult.C

Making dependency list for source file PatchValueExpressionLexer.ll

Making dependency list for source file PatchValueExpressionDriver.C

Making dependency list for source file groovyBCFvPatchFields.C

could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionDriver.C

could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionParser.yy

could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionLexer.ll

Making dependency list for source file groovyBCPointPatchFields.C

could not open file MixedPointPatchField.H for source file groovyBCPointPatchFields.C

could not open file PatchValueExpressionParser.tab.hh for source file groovyBCFvPatchFields.C

could not open file PatchValueExpressionParser.tab.hh for source file groovyBCPointPatchFields.C

could not open file PointPatchFieldMapper.H for source file groovyBCPointPatchFields.C

SOURCE=PatchResult.C ;  g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3  -DNoRepository -ftemplate-depth-40 -IMake/linuxGccDPOpt              -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude  -IlnInclude -I. -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linuxGccDPOpt/PatchResult.o

SOURCE=PatchValueExpressionLexer.ll ; rm Make/linuxGccDPOpt/PatchValueExpressionLexer.C ; flex -f $SOURCE ; mv *.c Make/linuxGccDPOpt/PatchValueExpressionLexer.C ; g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3  -DNoRepository -ftemplate-depth-40 -IMake/linuxGccDPOpt              -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude  -IlnInclude -I. -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC -c Make/linuxGccDPOpt/PatchValueExpressionLexer.C -o Make/linuxGccDPOpt/PatchValueExpressionLexer.o 

SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linuxGccDPOpt/PatchValueExpressionParser.C Make/linuxGccDPOpt/PatchValueExpressionParser.tab.hh; bison -ra -v  -d $SOURCE ;  mv *.tab.cc Make/linuxGccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linuxGccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linuxGccDPOpt ;  g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3  -DNoRepository -ftemplate-depth-40 -IMake/linuxGccDPOpt              -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude  -IlnInclude -I. -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC -c  Make/linuxGccDPOpt/PatchValueExpressionParser.C -o Make/linuxGccDPOpt/PatchValueExpressionParser.o 

SOURCE=PatchValueExpressionDriver.C ;  g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3  -DNoRepository -ftemplate-depth-40 -IMake/linuxGccDPOpt              -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude  -IlnInclude -I. -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linuxGccDPOpt/PatchValueExpressionDriver.o

rm: cannot remove `Make/linuxGccDPOpt/PatchValueExpressionLexer.C': No such file or directory

In file included from PatchValueExpressionDriver.H:59,

                 from PatchValueExpressionDriver.C:34:

PatchValueExpressionParser.tab.hh:44:20: error: stack.hh: No such file or directory

lex.ve.c:372: warning: use of old-style cast

lex.ve.c:442: warning: use of old-style cast

lex.ve.c:442: warning: use of old-style cast

PatchResult.C: In member function ‘void Foam::PatchResult::uglyDelete()’:

PatchResult.C:95: warning: deleting ‘void*’ is undefined

In file included from location.hh:44,

                 from PatchValueExpressionParser.tab.hh:65,

                 from PatchValueExpressionDriver.H:59,

                 from PatchValueExpressionDriver.C:34:

position.hh: In function ‘bool pve::operator==(const pve::position&, const pve::position&)’:

position.hh:136: warning: suggest parentheses around ‘&&’ within ‘||’

In file included from PatchValueExpressionDriver.H:59,

                 from PatchValueExpressionDriver.C:34:

PatchValueExpressionParser.tab.hh: At global scope:

PatchValueExpressionParser.tab.hh:309: error: ISO C++ forbids declaration of ‘stack’ with no type

PatchValueExpressionParser.tab.hh:309: error: expected ‘;’ before ‘<’ token

PatchValueExpressionParser.tab.hh:311: error: ISO C++ forbids declaration of ‘stack’ with no type

PatchValueExpressionParser.tab.hh:311: error: expected ‘;’ before ‘<’ token

PatchValueExpressionParser.tab.hh:313: error: ISO C++ forbids declaration of ‘stack’ with no type

PatchValueExpressionParser.tab.hh:313: error: expected ‘;’ before ‘<’ token

PatchValueExpressionParser.tab.hh:316: error: ‘state_stack_type’ does not name a type

PatchValueExpressionParser.tab.hh:318: error: ‘semantic_stack_type’ does not name a type

PatchValueExpressionParser.tab.hh:320: error: ‘location_stack_type’ does not name a type

In file included from Make/linuxGccDPOpt/location.hh:44,

                 from PatchValueExpressionParser.tab.hh:65,

                 from PatchValueExpressionParser.tab.cc:61:

position.hh: In function ‘bool pve::operator==(const pve::position&, const pve::position&)’:

position.hh:136: warning: suggest parentheses around ‘&&’ within ‘||’

In file included from Make/linuxGccDPOpt/location.hh:44,

                 from PatchValueExpressionParser.tab.hh:65,

                 from lnInclude/PatchValueExpressionDriver.H:59,

                 from PatchValueExpressionLexer.ll:3:

position.hh: In function ‘bool pve::operator==(const pve::position&, const pve::position&)’:

position.hh:136: warning: suggest parentheses around ‘&&’ within ‘||’

lex.ve.c: In function ‘int pvelex(pve::PatchValueExpressionParser::semantic_type*, pve::location*, Foam::PatchValueExpressionDriver&)’:

lex.ve.c:9465: warning: use of old-style cast

lex.ve.c:9465: warning: use of old-style cast

lex.ve.c:9482: warning: use of old-style cast

lex.ve.c:9495: warning: use of old-style cast

lex.ve.c:9962: warning: use of old-style cast

lex.ve.c: In function ‘int yy_get_next_buffer()’:

lex.ve.c:10141: warning: use of old-style cast

lex.ve.c:10164: warning: use of old-style cast

lex.ve.c:10177: warning: use of old-style cast

lex.ve.c:10177: warning: use of old-style cast

lex.ve.c:10198: warning: use of old-style cast

lex.ve.c:10198: warning: use of old-style cast

lex.ve.c:10223: warning: use of old-style cast

lex.ve.c:10226: warning: use of old-style cast

lex.ve.c:10226: warning: use of old-style cast

lex.ve.c: In function ‘yy_state_type yy_get_previous_state()’:

lex.ve.c:10261: warning: use of old-style cast

lex.ve.c:10261: warning: use of old-style cast

lex.ve.c: In function ‘int yyinput()’:

lex.ve.c:10379: warning: use of old-style cast

lex.ve.c: In function ‘yy_buffer_state* ve_create_buffer(FILE*, int)’:

lex.ve.c:10478: warning: use of old-style cast

lex.ve.c:10487: warning: use of old-style cast

lex.ve.c: In function ‘void ve_delete_buffer(yy_buffer_state*)’:

lex.ve.c:10513: warning: use of old-style cast

lex.ve.c:10516: warning: use of old-style cast

lex.ve.c:10518: warning: use of old-style cast

lex.ve.c: In function ‘void veensure_buffer_stack()’:

lex.ve.c:10685: warning: use of old-style cast

lex.ve.c:10705: warning: use of old-style cast

lex.ve.c: In function ‘yy_buffer_state* ve_scan_buffer(char*, yy_size_t)’:

lex.ve.c:10733: warning: use of old-style cast

lex.ve.c: In function ‘yy_buffer_state* ve_scan_bytes(const char*, int)’:

lex.ve.c:10786: warning: use of old-style cast

lex.ve.c: In function ‘void yy_push_state(int)’:

lex.ve.c:10822: warning: use of old-style cast

lex.ve.c:10825: warning: use of old-style cast

lex.ve.c:10825: warning: use of old-style cast

lex.ve.c: In function ‘int yy_init_globals()’:

lex.ve.c:10992: warning: use of old-style cast

lex.ve.c:11005: warning: use of old-style cast

lex.ve.c:11006: warning: use of old-style cast

lex.ve.c: In function ‘void* vealloc(yy_size_t)’:

lex.ve.c:11072: warning: use of old-style cast

lex.ve.c: In function ‘void* verealloc(void*, yy_size_t)’:

lex.ve.c:11084: warning: use of old-style cast

lex.ve.c:11084: warning: use of old-style cast

lex.ve.c: In function ‘void vefree(void*)’:

lex.ve.c:11089: warning: use of old-style cast

SOURCE=groovyBCFvPatchFields.C ;  g++ -m32 -Dlinux -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -O3  -DNoRepository -ftemplate-depth-40 -IMake/linuxGccDPOpt              -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/finiteVolume/lnInclude  -IlnInclude -I. -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OpenFOAM/lnInclude -I/home/stefano/OpenFOAM/OpenFOAM-1.7.1/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linuxGccDPOpt/groovyBCFvPatchFields.o

make: *** [Make/linuxGccDPOpt/PatchValueExpressionDriver.o] Error 1

make: *** Waiting for unfinished jobs....

PatchValueExpressionParser.tab.cc: In member function ‘unsigned char pve::PatchValueExpressionParser::yytranslate_(int)’:

PatchValueExpressionParser.tab.cc:4941: warning: use of old-style cast

In file included from Make/linuxGccDPOpt/location.hh:44,

                 from PatchValueExpressionParser.tab.hh:65,

                 from PatchValueExpressionDriver.H:59,

                 from groovyBCFvPatchField.H:48,

                 from groovyBCFvPatchFields.H:37,

                 from groovyBCFvPatchFields.C:36:

position.hh: In function ‘bool pve::operator==(const pve::position&, const pve::position&)’:

position.hh:136: warning: suggest parentheses around ‘&&’ within ‘||’

lex.ve.c: At global scope:

lex.ve.c:10809: warning: ‘void yy_push_state(int)’ defined but not used

lex.ve.c:10837: warning: ‘void yy_pop_state()’ defined but not used

lex.ve.c:10849: warning: ‘int yy_top_state()’ defined but not used

Quote:

Originally Posted by swahono (Post 287313)

I was just joking! :D

We all struggle with OpenFOAM because "documentation is not important!". A lost battle of years... :mad:

Quote:

Ok, I have re-made your groovyBC
wclean
wmake libso

It returned errors (see error msg below), but I think it still compiled the library.
- I may have gotten the same error message before, but ignored it because the library and BC type is still recognized by OpenFOAM despite the compilation error msg. -

I checked both the GCC version and bison version installed on my machine is as required by groovyBC
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
bison (GNU Bison) 2.4.1

The simulation still crashed on the second iteration using your copy of the newly compiled groovyBC. :(

Just wondering if you had the same error msg (-See below) as me when you compiled the groovyBC on your machine?

Yes, I have quite some message too. But it seems to work properly. I have gcc 4.5.0 (openSUSE), and bison 2.4.1.

Best,