[dappe]

Hello everybody,
I'm working on an axysymmetric impinging jet and I want to compare the results found with Fluent. I already have the mesh, a 1 degree wedge of the jet and all the boundary conditions. I'm using OpenFoam 2.4 in openSUSE 13.2. The turbulence model is kOmegaSST and the solver is rhoSimpleFoam.
The simulation crashes at the 2nd iteration with this error message:

#0 Foam::error:rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::hePsiThermo<Foam:siThermo, Foam:ureMixture<Foam::sutherlandTransport<Foam:: species::thermo<Foam::hConstThermo<Foam:erfectGa s<Foam::specie> >, Foam::sensibleInternalEnergy> > > >::calculate() at ??:?
#4 Foam::hePsiThermo<Foam:siThermo, Foam:ureMixture<Foam::sutherlandTransport<Foam:: species::thermo<Foam::hConstThermo<Foam:erfectGa s<Foam::specie> >, Foam::sensibleInternalEnergy> > > >::correct() at ??:?
#5 ? at ??:?
#6 __libc_start_main in "/lib64/libc.so.6"
#7 ? at /home/abuild/rpmbuild/BUILD/glibc-2.19/csu/../sysdeps/x86_64/start.S:125
Floating point exception


I had one similar error in a previous simulation and I managed to fix it changing my bc (one field was 0 and that is why I have had a Floating exception error), but now the bcs should be right.
My OpenFOAM' knowledge is very limited; however, I tried to fix this problem in several ways suggested in other threads but I haven't found a solution. I ve also switched off the turbulence model just to see if the problem was there but it didnt work.
In the attachment you can find my case without the mesh (otherwise the file would have been too much big for the uploading). I have also added a screen of my domain so you can better understand the case.
May you help me with this error please?
Thank you in advance.
Alessandro

[Flowkersma]

Hi,

I think you should use wedge boundary condition for "front" and "back" planes. Look at $FOAM_TUTORIALS/incompressible/pimpleDyMFoam/movingCone/ for example.

Regards,
Mikko

[dappe]

Thank you Mikko!!!
I've just modified the case with the wedge bc but I'm having some problems.
First, I had to modify the orientation of th mesh because OF wants the x axis as axis of symmetry (I'm not sure about that but after using 'transformPoints' to rotate it I have no more that error).
However after the modification, when I try to run the solver, there are some FOAM warnings. They say that the wedge patches are no more planar!!
Before I didn't have this problem.
Using checkMesh, it returns me an error: 'Cannot find opposite wedge for wedge sym_fluid'. I have a patch named 'axy' that forms the edge where the two wedge patches should join; is it possible the 'axy patch doesn't allow OF to recognize the opposite wedge properly?
Also with this problems, the solver managed to run but it stopped at the second iteration giving me the same error I have had before with simmetry boundary conditions.

However the mesh is imported from Fluent (it was made with Autogrid Igg) and it s 3d. I d like to know if I ve to put wedge or symmetry bc, because in Fluent who studied this case simulated only this piece of jet and then he extended the solution during postprocessing.
Any suggestion?

Alessandro

[Flowkersma]

Dear Alessandro,

I assumed that you want to do a 2D simulation and therefore you should use wedge boundary condition. OpenFOAM always uses 3D mesh so the mesh should have one cell in the direction of rotation. If you want to run a 3D simulation then you should use cyclic boundary condition.

I'm not a master with the wedge type mesh but I've done a few impinging jet simulations and here is what I've found out. I've always done my mesh with blockMesh and extrudeMesh. First I create one cell deep planar mesh with blockMesh and then I extrude it to wedge with extrudeMesh. I've always used y-axis as axis of rotation but I think any axis should work. I've had similar problems with checkMesh. I get no errors when the wedge is 2.5 degrees thick and it is symmetric to xy-plane. I use symmetryPlane boundary condition for the axis of symmetry edge.

Regards,
Mikko

[dappe]

Thanks Mikko!!
However I was wrong, my mesh should be a 2D one. In fact I have only one cell in the direction of rotation.
Changing the bc of the axys of symmetry edge to symmetryPlane I have the same problems I had before.
The problem is that I can't do my own mesh with extrudeMesh etc because I m comparing Fluent and OF so I want to use the same mesh. That is why I imported the mesh from Fluent.
If you give me your email address I can send you the complete case with also the imported mesh.
However with every bc I tried I m having everytime the same error after the 2nd iteration and I don't know if it depends on bcs or other.

[dappe]

Is there an alternative to rhoSimpleFoam solver for my case?

[dappe]

Thanks to Mikko's help, I managed to run the simulation for both laminar and Spalart-Allmaras turbulence model.
Using kOmegaSST model (the one I'm supposed to use for my simulation), it stops at the second iteration with the same error I wrote in the 1st post.
I can't understand how it is possible: it should be a bc problem for the kOmegaSST quantities.
I had a look to some papers but with Openfoam I need to give a value in every patch, and it's not clear for me which one.
However my solutions don't converge (with both Spalart & laminar).

Probably the crash is due to the temperature that goes below 0 after the first iteration. My professor told me that it could be a relaxation factors issue.
I tried to change some values according to other threads but I didn't solve the problem.
Moreover all my simulations (laminar and turbulent) produce oscillating residuals and don't converge.
Any help???
Alessandro

[dappe]

At the end I managed to run my simulation also with kOmegaSSt turbulence model. The problem was in the fvschemes file. After some changes in gradSchemes, divSchemes and laplacianSchemes, it works.
The solution is quite good and almost completely similar to the Fluent one previously calculated. The only differerence is the overshoot in the T field next to the outlet (see the attachement).
Here the T is more or less 30K higher than the max T set in the domain (Twall=644K).
Can someone suggest me some more changes in order to remove this overshoot?
Here you have my fvSchemes file.

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default Gauss linear;
// default cellMDLimited Gauss linear 1;
//grad(U) cellMDLimited Gauss linear 1;
//grad(T) cellMDLimited Gauss linear 1;
//grad(p) cellMDLimited Gauss linear 1;
//grad(e) ...;


}

divSchemes
{
//default none;
// default Gauss upwind;
//div(phi,U) bounded Gauss linearUpwind grad(U); //also for T added on the advice of Joel
//div(phi,T) bounded Gauss linearUpwind grad(T);
div(phi,U) bounded Gauss linearUpwind grad(U);
div(phi,nuTilda) bounded Gauss linearUpwind grad(nuTilda);
div((nuEff*dev(T(grad(U))))) Gauss linear;
div(phi,omega) bounded Gauss upwind;
div((muEff*dev2(T(grad(U))))) Gauss linear;
div(phi,Ekp) bounded Gauss upwind;
div(phi,e) bounded Gauss upwind;
div(phi,k) bounded Gauss upwind;
}

laplacianSchemes
{
default Gauss linear corrected;
// default Gauss linear orthogonal;
// default Gauss linear limited 1;

}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default corrected;
// default orthogonal;
}

fluxRequired
{
default no;
p ;
}


Thank you in advance for the help.
Have a nice day.
Alex