[md_lieber]

Hi guys. I've been using OpenFOAM for the last couple of months and I've got a problem that I just can't seem to work out. I'm using the compressible rhoPorousSimpleFoam solver for a backstep geometry, and even though I specify the initial pressure field to be around 85000Pa, during the very first iteration the entire pressure field goes to -2E-6 Pa and gets bounded by whatever my pMin value is (default is 100Pa).

It totally messes with my density and the solver can never recover the pressure field. I've saved every iteration and reviewed it in paraFoam and, indeed, iter=0 the entire field is at 85000Pa, and then iter=1 it's bounded to ~100Pa.

The setup that I believe is most correct uses:

p_in
type totalPressure
p0 uniform 101325
value uniform 85000
phi phi
rho rho
psi none
gamma 1.4

p_out
zeroGradient (but I've also tried fixedValue to no avail).

p_init --> uniform 85000

U_in
flowRateInletVelocity (but I've also tried fixedValue to no avail).
flowRate 3
value uniform (0 180 0)

U_out
inletOutlet
value uniform (0 180 0)
inletValue (0 180 0)

U_init --> uniform (0 180 0)

It's a RANS turbulence model and I've tried kOmegaSST and kEpsilon with the same results. I've also used all second order, all first order, and a mix of the two for the fvSchemes settings, and it never changes the insanely negative pressures I'm seeing after the first iteration. Mesh sizes range from 1 million to 5 million gridpoints with a wall y+ of about 35 (structured elements, generated in Pointwise).

Can anybody throw out any ideas or suggestions? I'm really pulling my hair our here. Thanks!

[herbert]

Hi,

you can try the following stuff:

1. Do a very strong underrelaxation of density in the beginning of you calculation (e.g. 0.01 or lower). So your pressure field won't immediatly destroy the density field.
2. Start with a lower inlet velocity and raise it with time
3. Initialize the flow field be doing a incompressible calculation with constant transport properties

Good luck,
Stefan

[md_lieber]

Hi Stefan,

Good suggestions, thanks! I should have mentioned that I am already using 0.05 under-relaxation for rho and 0.3 for p, but I will definitely try taking rho a little bit lower.

If I'm doing a steady-state simulation, is there any way to prescribe the inlet velocity boundary condition to change after a certain number of iterations? I'd love to say "Start at 1m/s and raise to 180m/s over the course of 5,000 iterations." I'm afraid it would take a very long time if I set U_in = 1m/s, decompose the 5 million grid-point mesh, solve for awhile, reconstruct, change in the inlet velocity, and repeat the whole procedure many times to 'step up' the velocity.

Could you elaborate on the third suggestion? I've tried using potentialFoam to get a reasonable velocity field but, at least so far, it doesn't seem to have helped stabilize the pressure field during those first few iterations.


That actually brings up another question. If the point of under-relaxation is that it prevents one variable from changing to the "new solution" instantly, how could my pressure field go from ~85000Pa to the pMin (100Pa) in one iteration with a P under-relaxation of 0.3?

[herbert]

Hi,

I don't know how your programming skills are, but I think the easiest way is to create a new boundary condition derived from fixedValue. The only steps needed are to introduce two new members (a referenceValue and a raiseTime) and to scale give something like

min(this->db().time().timeIndex()/raiseTime_, 1.0)*referenceValue_

to the fixedValue bc in updateCoeffs(). You can also have a look to the timeVarying bc's in Foam.

Regards,
Stefan

[md_lieber]

I have managed to isolate the issue to the mesh size. By changing only the number of grid points along connectors (or face edges, however you call them), I can reduce the mesh to about 300k points. At that resolution, OpenFOAM runs as expected and converges to a nice looking (albeit low-resolution) solution.

Resolutions higher than that always blow up. Here's the shocker: they even blow up when I map the converged solution from the 300k-point model! Pressure is nice and stable at 300k, I map the solution on to a 1M point model and the pressure "bubble" just downstream of the step starts to grow non-physically and causes the entire simulation to blow up (this is with p under-relaxed to as low as 0.05!)

Since I know most schemes are *more* stable on higher-resolutions meshes, why would a model run great at 300k points and be totally unstable at anything higher than that? I'm sure it's not a RAM or CPU problem, as I'm hardly taxing the system at 5 million gridpoints.