|
[Sponsors] |
Huge negative pressure after first iteration using rhoPorousSimpleFoam |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 15, 2010, 02:24 |
Huge negative pressure after first iteration using rhoPorousSimpleFoam
|
#1 |
New Member
Join Date: May 2010
Posts: 6
Rep Power: 16 |
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! |
|
July 15, 2010, 06:30 |
|
#2 |
Senior Member
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 17 |
Hi,
you can try the following stuff:
Stefan |
|
July 15, 2010, 12:48 |
|
#3 |
New Member
Join Date: May 2010
Posts: 6
Rep Power: 16 |
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? |
|
July 16, 2010, 04:19 |
|
#4 |
Senior Member
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 17 |
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 Code:
min(this->db().time().timeIndex()/raiseTime_, 1.0)*referenceValue_ Regards, Stefan |
|
July 18, 2010, 21:45 |
|
#5 |
New Member
Join Date: May 2010
Posts: 6
Rep Power: 16 |
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. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pressure BC for combustion chamber | Giuki | FLUENT | 1 | July 19, 2011 12:35 |
seeking for help about a room with negative pressure | mengyue1 | FLUENT | 0 | November 26, 2009 07:40 |
High pressure in rhopSonicFoam results in negative pressure | shangzung | OpenFOAM | 0 | November 5, 2009 04:24 |
what the result is negatif pressure at inlet | chong chee nan | FLUENT | 0 | December 29, 2001 06:13 |
Hydrostatic pressure in 2-phase flow modeling (CFX4.2) | HB &DS | CFX | 0 | January 9, 2000 14:19 |