[syavash]

--> FOAM FATAL IO ERROR: 
keyword div(U) is undefined in dictionary "/media/syavash/science/PHD_Thesis/New/system/fvSchemes.divSchemes"

file: /media/syavash/science/PHD_Thesis/New/system/fvSchemes.divSchemes from line 30 to line 36.

    From function dictionary::lookupEntry(const word&, bool, bool) const
    in file db/dictionary/dictionary.C at line 437.

FOAM exiting

Dear Ville

I think div(U) is missing from fvSchemes. I have added it like:

div(U)          Gauss linear;

but now another error appears as follows:

--> FOAM FATAL ERROR: 
incompatible dimensions for operation 
    [p[0 0 -2 0 0 0 0] ] == [div(U)[0 0 -1 0 0 0 0] ]

    From function checkMethod(const fvMatrix<Type>&, const GeometricField<Type, fvPatchField, volMesh>&)
    in file /home/syavash/OpenFOAM/OpenFOAM-2.3.1/src/finiteVolume/lnInclude/fvMatrix.C at line 1356.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  void Foam::checkMethod<double>(Foam::fvMatrix<double> const&, Foam::DimensionedField<double, Foam::volMesh> const&, char const*) at ??:?
#3  
 at ??:?
#4  
 at ??:?
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  
 at ??:?
Aborted (core dumped)

I suppose this error implies inconsistancy in pressure units which you expressed above. How can I resolve this problem now?!

Syavash

[syavash]

I suppose this error implies inconsistancy in pressure units which you expressed above. How can I resolve this problem now?!

I changed the pressure dimension in 0/p to [ 0 2 -1 0 0 0 0 ] and the simulation goes on!
But I think a clarification on fvSchemes helps me a lot!
Another point is that I can only see pressure residuals on the screen. How should I include velocity residuals either?!

Syavash

Edit: Can you post an example of fvSchemes & fvSolution files?!

[syavash]

Originally Posted by ville

Sure. Please bare in mind that the conclusions I've made on runtime differences
were mostly for turbulent flows in parallel runs. Full conclusions are probably
depending on the number of processors, the parallel system which you use, the linear solver, the case (e.g. laminar vs turbulent). Good to start with lid driven cavity and check if you can reproduce the Ghia's data.

Dear Ville,

Any comments?!

[Braxus]

Dear All,

Il read this topic and succefully do the implementation of rk4 time scheme.
Is someone have some return to do about it ?
I have the same error than you, but i dislike the new pressure dimension, may we have not well do some operation.

I try the simulation of blasius boundary flow, and the time step down to 1.e-150 any idea.

Thank you for answers.

[ajogajog]

Originally Posted by ville

Large-eddy simulation in a complex hill terrain enabled by a compact fractional step OpenFOAM® solver


http://www.sciencedirect.com/science...65997814001513

Best wishes,
Ville

Dear Ville,

I have read your paper and your code. you have done a wonderful work in this and help me a lot.
but i still have some questions, i cannot figure it out.
1>as we know, the rk4 is a fully explicit method, in openfoam, the explicit equation should use the fvc::ddt. but you use the fvm::ddt in code, such as
solve(fvm::ddt(rho) + rhokcycle0 * RK4values[cycle]); (solve rho)

why? and what's the meaning?

2> can we implement the time schemes directly in folder? in this way, maybe we can use the RK4 in all of the solvers

thank you !!!
Best,
Frank

[chengyu]

Originally Posted by syavash

--> FOAM FATAL ERROR: 
incompatible dimensions for operation 
    [p[0 0 -2 0 0 0 0] ] == [div(U)[0 0 -1 0 0 0 0] ]

    From function checkMethod(const fvMatrix<Type>&, const GeometricField<Type, fvPatchField, volMesh>&)
    in file /home/syavash/OpenFOAM/OpenFOAM-2.3.1/src/finiteVolume/lnInclude/fvMatrix.C at line 1356.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  void Foam::checkMethod<double>(Foam::fvMatrix<double> const&, Foam::DimensionedField<double, Foam::volMesh> const&, char const*) at ??:?
#3  
 at ??:?
#4  
 at ??:?
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  
 at ??:?
Aborted (core dumped)

I suppose this error implies inconsistancy in pressure units which you expressed above. How can I resolve this problem now?!

Syavash

Obviously, it is a problem of time dimension, the reason is a lack of deltaT parameter on the construction of pressure correction, plz refer to Projection method, see the "Chorin's projection method" part.
To help the one who is interested, I paste the corresponding code down here

// PressureCorrection.H

#include "continuityErrs.H"
U.correctBoundaryConditions();
solve(pEqn == fvc::div(U)/runTime.deltaT());
U = U - fvc::grad(p)*runTime.deltaT();
U.correctBoundaryConditions();

[syavash]

Originally Posted by chengyu

Obviously, it is a problem of time dimension, the reason is a lack of deltaT parameter on the construction of pressure correction, plz refer to Projection method, see the "Chorin's projection method" part.
To help the one who is interested, I paste the corresponding code down here

// PressureCorrection.H

#include "continuityErrs.H"
U.correctBoundaryConditions();
solve(pEqn == fvc::div(U)/runTime.deltaT());
U = U - fvc::grad(p)*runTime.deltaT();
U.correctBoundaryConditions();

Thanks fo your comment Yu Cheng. I have implemented the RK4 solver with the help of Dr. Vuorinen and your comment. Please check the file attached and let me know if there is something not right with the solver.

Kind Regards,
Syavash

[chengyu]

Thank you for sharing the code, Syavash. Could you kindly attach a minimum test case for the code, for example maybe a small case changing the OpenFOAM cavity. I believe this will help the other foamers.

Best regards,

Yu CHENG

[syavash]

Originally Posted by chengyu

Thank you for sharing the code, Syavash. Could you kindly attach a minimum test case for the code, for example maybe a small case changing the OpenFOAM cavity. I believe this will help the other foamers.

Best regards,

Yu CHENG

Dear Yu Cheng,

Very good idea. I have modified the solver to be able to take a constant source term into account. I have also provided a lid-driven cavity example with the new RK4Foam solver. I hope the other foamers would find it useful and hopefully do some experiments and comparisons.

Kind Regards,
Syavash

[chengyu]

Hey Syavash,

You've done a great work! I have compiled the code and run the cavity case, the preliminary results seem to be reasonable. I believe this work will definitely help other foamers. Thank you!

Best wishes!

Yu.

[rr3245]

Originally Posted by chengyu

Hey Syavash,

You've done a great work! I have compiled the code and run the cavity case, the preliminary results seem to be reasonable. I believe this work will definitely help other foamers. Thank you!

Best wishes!

Yu.

Hi Yu,

I have implemented this solver and I'm comparing it to pimpleFoam. It's compiling fine and also seems to be solving. However, I have two questions:

(1) What is the justification for multiplying or dividing by runTime.deltaT()? I can see that we need this for dimensional purposes, but how will this change the solver? Will this term factorise out?
(2) How will residuals be affected? I seem to have very high initial pressure residuals in the rk4projection method (compared to my pimpleFoam case). I'm using the same fvSolution specs for both cases, so I didn't expect this.

Thanks, RH.

[kermelosh]

Hey Syavash,

Thank you for the solver and the test case. I was able to compile the solver and run the test case with out a glitch. I tried comparing the solver running time between the RK4Foam and pisoFoam and found out that while the results are almost identical, the RK4Foam took more than 5 times the solver time of the pisoFOAM. The case I run was the cavity case with RE = 2500 and implementing RAS modeling. I was under the impression that RK4Foam results in saving of solver running time. Is that wrong or is there something I am doing wrong?

Thanks

[rr3245]

Originally Posted by kermelosh

Hey Syavash,

Thank you for the solver and the test case. I was able to compile the solver and run the test case with out a glitch. I tried comparing the solver running time between the RK4Foam and pisoFoam and found out that while the results are almost identical, the RK4Foam took more than 5 times the solver time of the pisoFOAM. The case I run was the cavity case with RE = 2500 and implementing RAS modeling. I was under the impression that RK4Foam results in saving of solver running time. Is that wrong or is there something I am doing wrong?

Thanks

I have the same problem, it doesn't run anywhere near as fast as I was expecting. RH.

[syavash]

Originally Posted by kermelosh

Hey Syavash,

Thank you for the solver and the test case. I was able to compile the solver and run the test case with out a glitch. I tried comparing the solver running time between the RK4Foam and pisoFoam and found out that while the results are almost identical, the RK4Foam took more than 5 times the solver time of the pisoFOAM. The case I run was the cavity case with RE = 2500 and implementing RAS modeling. I was under the impression that RK4Foam results in saving of solver running time. Is that wrong or is there something I am doing wrong?

Thanks

Hi,

The runtime depends on the number of processes as well. I have compared both pisoFoam and RK4 in LES simulations with cell number in order of 1e+8 and over 100 processes. I found them quite equally fast.
However, it should be noted that in RK4 solver, the pressure equation (elliptic) is solved 4 times while in pisoFoam it is solved only 2 times in default! This is the main reason why RK4 could be slower than pisoFoam in some cases.
In the end, I stick with pisoFoam as I found it more robust and more accurate in some canonical flow simulations!

Best Regards,
Syavash

[syavash]

Originally Posted by rr3245

Hi Yu,

I have implemented this solver and I'm comparing it to pimpleFoam. It's compiling fine and also seems to be solving. However, I have two questions:

(1) What is the justification for multiplying or dividing by runTime.deltaT()? I can see that we need this for dimensional purposes, but how will this change the solver? Will this term factorise out?
(2) How will residuals be affected? I seem to have very high initial pressure residuals in the rk4projection method (compared to my pimpleFoam case). I'm using the same fvSolution specs for both cases, so I didn't expect this.

Thanks, RH.

Hi,

The deltaT term is multiplied by because simply it is there in the original N-S equations! Have a look at some numerical textbook on Runge-Kutta algorithm.

Best Regards,
Syavash

[rr3245]

Originally Posted by syavash

Hi,

The runtime depends on the number of processes as well. I have compared both pisoFoam and RK4 in LES simulations with cell number in order of 1e+8 and over 100 processes. I found them quite equally fast.
However, it should be noted that in RK4 solver, the pressure equation (elliptic) is solved 4 times while in pisoFoam it is solved only 2 times in default! This is the main reason why RK4 could be slower than pisoFoam in some cases.
In the end, I stick with pisoFoam as I found it more robust and more accurate in some canonical flow simulations!

Best Regards,
Syavash

I ensured that the pressure equation was also being solved 4 times in piso and pimpleFOAM in order to make a direct comparison with RK4. I found no speed-up, in fact the times were very similar, if not slower. RH.

[syavash]

Originally Posted by rr3245

I ensured that the pressure equation was also being solved 4 times in piso and pimpleFOAM in order to make a direct comparison with RK4. I found no speed-up, in fact the times were very similar, if not slower. RH.

I guess the main motive behind RK4 was its temporal accuracy (4th order) over PISO with 2nd order accuracy. Some acoustic solvers may benefit from that. Putting it aside, I see no particular reason to use RK4 over pisoFoam.

Best Regards,
Syavash

[rr3245]

Originally Posted by syavash

I guess the main motive behind RK4 was its temporal accuracy (4th order) over PISO with 2nd order accuracy. Some acoustic solvers may benefit from that. Putting it aside, I see no particular reason to use RK4 over pisoFoam.

Best Regards,
Syavash

The one positive I had was stability. I tested it on the Taylor-Green 3D vortex flow, and at certain points in the simulation, piso/pimple were crashing. RK4 was running fine however. RH.

[Santiago]

Originally Posted by syavash

I guess the main motive behind RK4 was its temporal accuracy (4th order) over PISO with 2nd order accuracy. Some acoustic solvers may benefit from that. Putting it aside, I see no particular reason to use RK4 over pisoFoam.

Best Regards,
Syavash

It is very important if you need at least (and at most) 2nd order accuracy in time for the non-linear term....

[Hen Cruise]

Originally Posted by syavash

Dear Yu Cheng,

Very good idea. I have modified the solver to be able to take a constant source term into account. I have also provided a lid-driven cavity example with the new RK4Foam solver. I hope the other foamers would find it useful and hopefully do some experiments and comparisons.

Kind Regards,
Syavash

Hi, syavash, thanks very much for your great work, and i want to know,

Is it possible to modified the 'RK4' be an convenient 'option' in fvschemes file for ddtSchemes such as 'Euler' or 'backward'? then used for most compressible or incompressible solvers?