CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Laminar simpleFoam and inviscid simpleFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes
  • 2 Post By herenger
  • 1 Post By herenger

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   June 10, 2009, 09:12
Default Laminar simpleFoam and inviscid simpleFoam
  #1
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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
Rafael Jurado and PanPeter like this.
herenger is offline   Reply With Quote

Old   June 12, 2009, 07:35
Default Convergence and runtime for turbulent and laminar simpleFoam simulations
  #2
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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
Rafael Jurado likes this.
herenger is offline   Reply With Quote

Old   June 23, 2009, 08:14
Post Serial and parallel runtime for turbulent and laminar simpleFoam
  #3
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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
-------------------------------------------------------------------------------------------
herenger is offline   Reply With Quote

Old   June 25, 2009, 14:43
Default
  #4
Member
 
hamdi
Join Date: Mar 2009
Posts: 75
Rep Power: 17
hamcer is on a distinguished road
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.
hamcer is offline   Reply With Quote

Old   June 26, 2009, 05:34
Default Laminar simpleFoam and inviscid simpleFoam III
  #5
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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 is offline   Reply With Quote

Old   June 26, 2009, 05:49
Default Laminar simpleFoam and inviscid simpleFoam IV
  #6
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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 is offline   Reply With Quote

Old   June 30, 2009, 05:00
Default simpleInviscidFoam Floating Point Exception
  #7
New Member
 
Hubert Hérenger
Join Date: Mar 2009
Posts: 7
Rep Power: 17
herenger is on a distinguished road
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?

Last edited by herenger; June 30, 2009 at 12:43.
herenger is offline   Reply With Quote

Old   July 11, 2013, 06:27
Default
  #8
New Member
 
Julio Silveira
Join Date: Feb 2013
Location: London
Posts: 15
Rep Power: 13
biau is on a distinguished road
herenger,

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

Thank you
biau is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 10:47.