[gunner10]

Dear all,

I am trying to simulate a supersonic flow (M=7) over a double wedge geometry, using sonicFoam. However, my simulation always fails and the same error is presented for several boundary conditions and time steps. I know that this error indicates that temperature or another quantity diverges or takes negative values. Is there a problem with the solvers or do i have a bad setup for such case? Has any of you ever tried to simulate such a case? The error is presented in the attached photo. Please reply!

Thanks in advance,
Gunner10 [IMG]


https://drive.google.com/open?id=1xkUtXfUkQdBSveWfywyokgB1rdb8csY8[/IMG]

[gunner10]

After a lot of effort, I reduced the time step and the solver doesn't crash anymore. The time step is dt=10^-10, too small but it works (Mach=7), while the maximum CFL is almost 0.0004. If anyone has another idea, please reply!!!

[piu58]

It is not normal that you need such a tiny time step. There are some reasons possible:
- the mesh is not well balanced
- the boundary conditions are non physical
- the setting of material constants are non physical

I recommend to write a result every time step and look with paraFoam where the problematic area is. Then you may got an idea where to look first.

[gunner10]

Thank you for your response.
Regarding mesh, the checkMesh command leads to a mesh-fail for cells with small determinants. Although I do not know if this has a huge impact, the same error is, also, presented in other cases where sonicFoam works fine.

As for the material constants, the transport model is "const" where kinematic viscosity and Prandtl number are defined. An idea might have been to use "sutherland" transport model, in order to change Prandtl with regard to temperature.

Finally, the boundary conditions are presented below. I am not sure of what you mean by "non physical boundaries".


U
internalField uniform (3810 0 0);

boundaryField
{
inlet
{
type fixedValue;
value uniform (3810 0 0);
}

outlet
{
type waveTransmissive;
U U;
rho rho;
phi phi;
fieldInf (3810 0 0);
lInf 3.6;
gamma 1.4;
value uniform (3810 0 0);
}

wall
{
type fixedValue;
value uniform (0 0 0);
}

farfield
{
type slip;
}

sides
{
type symmetry;
}


p
internalField uniform 101000;

boundaryField
{
inlet
{
type fixedValue;
value uniform 101000;
}

outlet
{
type waveTransmissive;
p p;
rho rho;
phi phi;
fieldInf 101000;
lInf 3.6;
gamma 1.4;
value uniform 101000;
}

wall
{
type zeroGradient;
}

farfield
{
type zeroGradient;
}

sides
{
type symmetry;
}


T
internalField uniform 710;

boundaryField
{
inlet
{
type fixedValue;
value uniform 710;
}

outlet
{
type waveTransmissive;
T T;
rho rho;
phi phi;
fieldInf 710;
lInf 3.6;
gamma 1.4;
value uniform 710;
}

wall
{
type zeroGradient;
}

farfield
{
type zeroGradient;
}

sides
{
type symmetry;
}

[gunner10]

I tried the "sutherland" transport model and the previous error is gone and the time step is now 5e-7 with maximum CFL 0.16. Now there is a new issue (next photo). It is probably poor setup of the boundary conditions. Any ideas? I use similar boundaries as mentioned above.


https://drive.google.com/open?id=1R_...SX4m_WqPp2_u_Y

[deepbandivadekar]

Are you sure waveTransmissive can be used like this? I have only seen it being used for pressure and not U or T.

[gunner10]

Dear deepbandivadekar thank you for your response.
I have tried both U and T without waveTransmissive condition and instead, I used zeroGradient, but the error remains the same.
I have, also, noticed that before the solver crashes, the max CFL grows rapidly, from 0.1 up to 8 and then back to approx. 0.1, until the solver stops.
Now I am trying a simulation with lower Mach number (M=3) than before with a time step 1e-8. So far the simulation runs without errors, while the flow phenomena are taking shape.

[deepbandivadekar]

Originally Posted by gunner10

Dear deepbandivadekar thank you for your response.
I have tried both U and T without waveTransmissive condition and instead, I used zeroGradient, but the error remains the same.
I have, also, noticed that before the solver crashes, the max CFL grows rapidly, from 0.1 up to 8 and then back to approx. 0.1, until the solver stops.
Now I am trying a simulation with lower Mach number (M=3) than before with a time step 1e-8. So far the simulation runs without errors, while the flow phenomena are taking shape.

Okay. I am sorry I can't help much because am new to OpenFoam myself. But changing to the sutherland scheme may not be root cause. The old error disappears probably because the Sutherland model doesn't work same and thus doesn't encounter the trigger for error.


In any case, I'm curious about this case. Please do update here and if possible share your case files.

[gunner10]

Originally Posted by deepbandivadekar

Okay. I am sorry I can't help much because am new to OpenFoam myself. But changing to the sutherland scheme may not be root cause. The old error disappears probably because the Sutherland model doesn't work same and thus doesn't encounter the trigger for error.


In any case, I'm curious about this case. Please do update here and if possible share your case files.

Maybe you are right about the sutherland model. Anyway thanks. The files can be found at the following link:

https://drive.google.com/open?id=1k3...skU8hdr9ms8dd_

[gunner10]

Dear Foamers,

After a lot of effort, I finally managed to run properly a supersonic flow over a double wedge. This post works as a summary of my errors and the solution I found, in order to solve my case.

My simulation was about a supersonic flow (M=7) over a double wedge using sonicFoam solver. Two different errors presented. The first one was a "FOAM FATAL ERROR: Maximum number of iterations exceeded" (Picture Fatal_Error). This error solved by changing the transport thermophysical problem from "const" to "Sutherland".
After this change, a second error appeared. This error caused a solver crash (Picture Error2).
In both errors, the maximum Courant number was inexplicably increased leading to solution fail.

The proposed solution
After I checked my hybrid mesh, by using the command
"checkMesh -allGeometry -allTopology", I found out that the determinants of a few cells were low, leading to a mesh check fail. So I changed my mesh to a fully structured mesh with hexahedral as cells. Thus, the mesh was ok and the sonicFoam run without any error.

gunner10

[piu58]

> I changed my mesh to a fully structured mesh with hexahedral as cells.

Hex meshes are always the better than tetra meshes. But it is more complicated to establish them at irregular geometries. The effort is worthwhile, however.

[gunner10]

You are right. I started, though, with a tetra mesh out of simplicity. My mistake was that I didn't realize, at first, that the problem was my mesh and not my boundary conditions. Finally, the new mesh worked!!!!
I would like to thank you for responding once again!!

Alex