[herenger]

Dear all.

I currently am trying to compare results of turbulent, laminar and inviscid simulations. My test case is a wicked gate of a bulb turbine with a mesh of ~540k nodes. In order to perform laminar simulations I followed two approaches, one consisting in modifying simpleFoam , the other in selecting turbulence model laminar (as I have been suggested during the OF workshop in Montreal). To create my laminar simpleFoam version I mainly removed all turbulence related expressions and replaced + turbulence->divR(U) by - fvm::laplacian(nu, U).

Both simulations hereby show almost the same Ux, Uy, Uz, and p residuals, yet they show a completely different behaviour for the time step continuity error. After 600 iterations the *final* residuals hereby for both variants are unacceptably high. Note that for a turbulent k-epsilon simulation for the same case the solution has is well converged after ~ 250 iterations. Another issue is that my simpleLaminarFoam solver needs around 3 times longer for 600 iterations as simpleFoam with turbulence model laminar selected.

Any ideas about what is happening here?

To create a simpleFoam based inviscid solver I further removed -fvm::laplacian(nu, U). In the test case I set slip boundary conditions for for all patches except inlet and outlet. This solver now causes some trouble as it throws a floating point exception when either flux field phi file isn't present in the 0 directory or U in the 0 directory is not initialized with non 0 values. Hereby it is sufficient if one of phi or U is present/initialized for the solver to run without throwing the floating point exception.

Note then when setting viscosity to 0 (as I also have been suggested during the OF workshop) simpleFoam also throws a floating point exception.

My complete laminar test case can be found at (http://www.herenger.de/OpenFOAM/rohrturbine_leit.tgz)
The simpleLaminarFoam applicaton can be found at (http://www.herenger.de/OpenFOAM/simpleLaminarFoam.tgz)
My complete inviscid test case can be found at (http://www.herenger.de/OpenFOAM/rohr...t_inviscid.tgz)
The simpleInviscidFoam applicaton can be found at (http://www.herenger.de/OpenFOAM/simpleInviscidFoam.tgz)

Best regards and thanks in advance for any comment, help, idea, hint, etc. ...

Hubert

[herenger]

Hello again.

Meanwhile I did some more turbulent, laminar and inviscid simulations with the same test case. I therefore used simpleFoam with k-Epsilon turbulence model for the turbulent simulation, simpleFoam with turbulence model laminar for the laminar simulation and my simpleInviscidFoam solver for the inviscid simulation. In order to work around the floating point exception for my simpleInviscidFoam solver when in directory 0 either phi is missing or U is not initialized other then 0 I initialized all test cases with a preceding potentialFoam run.

The *best* convergence behaviour hereby apparently belongs to the inviscid simulation:



After roughly 100 iterations convergence seems to be reached at more or less acceptable (?) residual values.

The laminar simulation converges less nicely with a little higher residual values:



I observed the slowest convergence behaviour for the turbulent simulation (though nicer than laminar):



So far so good. Now when looking at runtimes (8 domains on 4 harpertown quadcore CPUs) for all three variants I really was surprised to see that the turbulent run by far was the fastest with a clocktime of 344s for the run.
The laminar simulation run for a clocktime of 590s, the invsicid run needed 432s clocktime.

I really don't understand why the laminar run is so much slower than the turbulent one. Especially as the laminar case does not need more iterations for U or p equation solving.

So if anybody has an idea what potentially is wrong with my laminar setup, please help me ...

Any comments, ideas etc. are more then welcome.

The logs for all three simulations can be found here:

turbulent
laminar
inviscid

[herenger]

Dear all.

After some further investigations on runtime of some simpleFoam variants I found out that there seems to be a problem when executing simpleFoam with laminar turbulence model and my simpleInviscidFoam application in parallel.
The following table shows runtime for serial and parallel execution for simpleFoam with kEpsilon turbulence model, with laminar turbulence model and for simpleInviscidFoam. The parallel runs hereby have been done with 16 domains on 4 harpertown nodes with 2 sockets per node and 4 cores per socket thus leaving half of the cores idle.

---------------------------------| serial | parallel
-------------------------------------------------------------------------------------------
simpleFoam kEpsilon | 1970s | 344s
-------------------------------------------------------------------------------------------
simpleFoam laminar | 1410s | 590s
-------------------------------------------------------------------------------------------
simpleInviscidFoam | 1035s | 432s

Any ideas?

As to one of my numerous other problems I could narrow down the floating point exception in my inviscid solver when neither 0/U is initialized with non zero values nor 0/phi is present. The exception is thrown when solving the momentum predictor.

Hubert
-------------------------------------------------------------------------------------------

[hamcer]

hi Hérenge

I'm not sure, but I think the problem is in the file 0 / U, you must change internalField uniform (0, 0, 0) to internalField uniform (value, value, value).

hope it helps you.

[herenger]

Dear Nacer.

Thanks for your reply.

Actually there shouldn't be any problem with an initial (0 0 0) velocity field or an internal velocity flux field 0 as for example shows the fact that simpleFoam and my simpleLaminarFoam solver run fine on the same case. However, changing only one line in the simpleLaminarFoam code by removing - fvm::laplacian(nu,U) in the UEqn causes a floating point exception to be thrown when trying to solve for the momentum predictor. And this exception seems to be caused by an internal velocity field (0 0 0) (or internal velocity flux field 0) as when initializing the test case with potentialFoam thus having non zero internal velocity and velocity flux fields simpleInviscidFoam runs fine. I was suscpecting that some viscosity related operations might have remained somewhere in the code but as in I removed the transportProperties section createFields.H this would have caused an error at compiletime.

So I still have no clue what the problem actually is ...

So anybody having any idea or whatsoever, please reply ... ;-)

Best regards,

Hubert

[herenger]

Just in case that the stack trace might help ...

Starting time loop

Time = 1

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted: [0xb7f39420]
#3 Foam:ILUPreconditioner::calcReciprocalD(Foam::Fi eld<double>&, Foam::lduMatrix const&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#4 Foam:ILUPreconditioner:ILUPreconditioner(Foam: :lduMatrix::solver const&, Foam::Istream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#5 Foam::lduMatrix:reconditioner::addasymMatrixCons tructorToTable<Foam:ILUPreconditioner>::New(Foam ::lduMatrix::solver const&, Foam::Istream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#6 Foam::lduMatrix:reconditioner::New(Foam::lduMatr ix::solver const&, Foam::Istream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#7 Foam::PBiCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#8 Foam::fvMatrix<Foam::Vector<double> >::solve(Foam::Istream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#9 Foam::lduMatrix::solverPerformance Foam::solve<Foam::Vector<double> >(Foam::tmp<Foam::fvMatrix<Foam::Vector<double> > > const&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#10 main in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#11 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#12 __gxx_personality_v0 at ../sysdeps/i386/elf/start.S:122
Gleitkomma-Ausnahme

[herenger]

Looking at the stack trace lets me suggest that there is some division by zero somewhere in the DILUPreconditioner. So I tried to run simpleInviscidFoam without preconditioner, which in turn lead to another floating point exception which also seems to be caused by some division by zero:

nonePBiCG: Solving for Ux: solution singularity
nonePBiCG: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
nonePBiCG: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
#0 Foam::error:rintStack(Foam::Ostream&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted: [0xb7fe0420]
#3 void Foam::divide<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<Foam::Vector<d ouble>, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#4 Foam::tmp<Foam::GeometricField<Foam::Vector<double >, Foam::fvPatchField, Foam::volMesh> > Foam:perator/<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<Foam ::Vector<double>, Foam::fvPatchField, Foam::volMesh> > const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#5 main in "/home/drfoam/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/simpleInviscidHHFoam"
#6 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#7 __gxx_personality_v0 at ../sysdeps/i386/elf/start.S:122
Gleitkomma-Ausnahme

So obviously lack of friction terms (i.e. - fvm::laplacian(nu,U)) causes a division by zero somewhere in the solution process when a zero initial velocity field is used.


Any ideas why this is the case?

[biau]

herenger,

How did you plot the residuals ? or Which program did you use ?

Thank you