[sturgeon]

Hi all

I'm attempting to develop a new solver and keep running into checkerboarding issues. I've been looking online and trying to find the cause. In the wiki describing buoyantBoussenesqPisoFoam, it mentions:

Most importantly, lines 17--20 set up the Poisson equation for the pressure correction and can be seen to be the face-located analog to Equation 27. This shows that pressure is being predicted at the cell centers using face-centered information. This procedure effectively applies Rhie-Chow interpolation which avoids the checkerboard pressure oscillations that can occur on a co-located grid

http://openfoamwiki.net/index.php/Bu...sinesqPisoFoam

However, I closely followed the methods described in the above link when creating the solver and used the same way of building the equations to apply Rhie-Chow interpolation, so I don't think that is it.

In this thread (How to avoid checkerboard?), a user mentions checkerboarding caused by using slip and noSlip boundary conditions, which I am using. However, his issue is solved by increasing corrector loops (which doesn't help me) and another user points out that this means his case just hadn't converged yet. So I'm not sure if his assessment that his boundary conditions were causing checkerboarding or not is accurate.

In another thread (Checkerboarding with interFoam) a user mentions from literature that there's a minimum courrant number allowable to avoid checkerboarding. I couldn't find the literature in question but I tried messing around with cell size and timestep to remove checkerboarding, but unsuccessfully. Am I correct in understanding that there's in fact a minimum allowable courrant number? And is this the absolute minimum for any cell in the entire domain, or an average?

My case is a very simple one (2D, left inlet, right fixed pressure outlet, ceiling and floor are slip and noslip respectively) and my solver is a modification of buoyantBoussenesqPimpleFoam. I've disabled my modifications and it simply behaves like bBPF so I am fairly certain my coding isn't the issue. (Running the same case with bBPF produces identical results.)



Above is the vertical velocity profile at the inlet. There should be nothing really affecting the vertical velocity at all.

Now obviously I don't expect anyone to look through my code and case files to figure out why this is occurring - I was hoping someone could give me some insight as to why this kind of problem might be occurring, or expand upon the information I've found already

Cheers

EDIT: Also, I spent a lot of time messing around with the schemes but this also never seemed to make much difference. Courrant number was always kept well below 1

Second edit:

I found these threads: Oscillatory inlet velocity and Mesh problem/ coarse OK - fine not OK

The issues seem to be very similar. The fixedMean velocity as suggested in the first thread didn't make any difference but I'll attempt the other possible fixes related to the issue. If anyone could provide any insight into any of this,I would be grateful

Third edit:

I tried the method of having a patch of slip adjacent to the inlet, but this just caused the strange vertical velocities to be pushed further down the domain. I also used laminar instead of kEpsilon for turbulence and the vertical velocity anomaly in the corner was lessened by several orders of magnitude, but still present.

[tom_flint2012]

Hi,

I’m dealing woth a similar issue and found some success by taking the courant number right down to 0.01. I’m dealing with state change and this issue presents itself as my phases transition so slightly different to your case.
Did you have any other success getting rid of the checkerboard?

All the best,

Tom

[sturgeon]

Originally Posted by tom_flint2012

Hi,

I’m dealing woth a similar issue and found some success by taking the courant number right down to 0.01. I’m dealing with state change and this issue presents itself as my phases transition so slightly different to your case.
Did you have any other success getting rid of the checkerboard?

All the best,

Tom

Hi Tom

No success really. Put this whole thing on the back burner because it was going nowhere. Getting back into it now. I'll post here/PM you if I have any success

Cheers
sturgeon

[mAlletto]

Did you try to have a bit finer grid in streamwise direction close to the inlet boundary. Usually this kind of oscillation come from second order discretization and the truncation error leads to oscillation.

Furthermore if you apply a block profile at the inlet this is not consistent with the slip boundary conditions. (it's only a guess you apply a block profile since you did not post the boundary conditions).

A block profile in combination with a no slip boundary condition leads high velocity gradients in stream wise direction close to the ground which should be resolved adequately with a finer grid in stream wise direction

[sturgeon]

Originally Posted by mAlletto

Did you try to have a bit finer grid in streamwise direction close to the inlet boundary. Usually this kind of oscillation come from second order discretization and the truncation error leads to oscillation.

Furthermore if you apply a block profile at the inlet this is not consistent with the slip boundary conditions. (it's only a guess you apply a block profile since you did not post the boundary conditions).

A block profile in combination with a no slip boundary condition leads high velocity gradients in stream wise direction close to the ground which should be resolved adequately with a finer grid in stream wise direction

Thanks for the reply. I will see if this resolves my issue. If by block profile you mean fixedValue then yes that is what I used.

For clarification, when you say a block profile is not consistent with slip boundary... do you mean it's not consistent with slip or no slip? Because intuitively I feel like the block would be consistent with slip but not no slip. Isn't slip essentially symmetry with no wall effects, so the block fixedValue boundary would be consistent?

Cheers
sturgeon

[mAlletto]

Sorry I mean that a constant velocity profile is not consistent with a no slip boundary condition

[sturgeon]

Originally Posted by mAlletto

Sorry I mean that a constant velocity profile is not consistent with a no slip boundary condition

Thanks for the response. Messing about with the refinements you suggested seems to improve the case, so I'll see if it's good enough to work with my actual application.

I am still quite confused though - I was building my case based on the tutorials, specifically circuitBoardCooling. In the results for that tutorial, you can see there are perturbations in the left hand corners, where the inlet meets the noSlip boundaries. But that case doesn't seem to require any special treatment or non-uniform grids to avoid the checkerboarding I experience. Why is this?

Cheers
sturgeon

[mAlletto]

What Kind of boundary conditions do you apply for the Temperature?

[sturgeon]

Originally Posted by mAlletto

What Kind of boundary conditions do you apply for the Temperature?

zeroGradient for the floor and ceiling, fixed value for inlet, inletoutlet for the outlet.

EDIT: I've also tried using meanValue for the velocity inlet and pressure outlet, not sure if I'm really using them right since I can't find much online or anything in the tutorials. Most of the checkerboarding seems to vanish except in the extreme corners of the inlet, but the horizontal velocity isn't consistent down the horizontal axis. Along the middle it drops off by about 5%, and along the noSlip wall it varies quite wildly, so I still don't have this set up right.

[mAlletto]

Ok the check board velocity is quite normal in the corner I think.

Let's think about a constant inlet profile. This profile is not consistent with the no slip boundary condition since one has to have zero velocity at the wall.

This leads to a deceleration of the flow in stream wise direction in the first cell after the boundary. Due to the continuity equation to the flow is imposed a velocity normal to the wall at the second cell away of the wall. This together with the sharp gradient in the pressure (the truncation error of the rhiew and Chow interpolation is proportional to the 4th derivative of the pressure) leads to an oscillating velocity close to the corner.

The reason of the retardation of the flow away from the wall is not clear to me. At least the average velocity should be equal every where because of mass conservation.

[sturgeon]

Originally Posted by mAlletto

Ok the check board velocity is quite normal in the corner I think.

Let's think about a constant inlet profile. This profile is not consistent with the no slip boundary condition since one has to have zero velocity at the wall.

This leads to a deceleration of the flow in stream wise direction in the first cell after the boundary. Due to the continuity equation to the flow is imposed a velocity normal to the wall at the second cell away of the wall. This together with the sharp gradient in the pressure (the truncation error of the rhiew and Chow interpolation is proportional to the 4th derivative of the pressure) leads to an oscillating velocity close to the corner.

The reason of the retardation of the flow away from the wall is not clear to me. At least the average velocity should be equal every where because of mass conservation.

Thank you for the information. Like I said, using meanValue for the velocity inlet seems to improve things a little but the result doesn't seem physical. Do you have any experience in using meanValue?

Also, are you saying that in theory, fixedValue for the inlet should be fine, as long as the mesh is sufficiently refined around this area?

EDIT: I'm actually just doing these runs in vanilla buoyantBoussinesqPimpleFoam now, so my custom solver is definitely not the issue.

[mAlletto]

I do not have any experience with meanValue. I think using fixedValue at the inlet is fine enough if your zone of interest is enough away from the inlet in order that the flow can adjust and became fully developed.

The best inlet condition is the one which perfectly reproduces the actual condition at the point very you artificially cut the domain.

Using fixedValue is for sure not a boundary condition like this. However if your boundary is far away from the zone of interest, the flow can adjust to the geometry and wall boundary conditions applied and you get realistic condition at the zone you are interested in.

[sturgeon]

Originally Posted by mAlletto

I do not have any experience with meanValue. I think using fixedValue at the inlet is fine enough if your zone of interest is enough away from the inlet in order that the flow can adjust and became fully developed.

The best inlet condition is the one which perfectly reproduces the actual condition at the point very you artificially cut the domain.

Using fixedValue is for sure not a boundary condition like this. However if your boundary is far away from the zone of interest, the flow can adjust to the geometry and wall boundary conditions applied and you get realistic condition at the zone you are interested in.

Okay, thanks for your advice, I will continue to try and figure out what else is causing the problem.

Cheers
sturgeon

[Gerry Kan]

Dear Sturgeon:

I also ran into this problem. I modified rhoPimpleFoam (compressible, transient) to include effects of gravity in the momentum equation (I decided not to use p_rgh as per problem requirements and available data). At first I thought it was a problem with my coding or my boundary condition, but I am more convinced this issue appears due to the combination of the physics that is involved.

To test this, I have a simple rectangular box created in blockMesh with the following boundary conditions:

U: noSlip on all walls
T and p: fixedValue on bottom wall, zeroGradient on all other walls

Using the modified rhoPimpleFoam with gravity effects, I expect the temperature and pressure to settle to a hydrostatic equilibrium state. Instead I see the checkerboard effect, not unlike what you posted, in the vicinity of the bottom wall (where the fixedValue T and p are). Since U, T, and p are all coupled as the solver is compressible, the checkerboard shows up also everywhere, and the solution gets "stuck". The checkboard effect was not observed near the remaining zeroGradient boundaries.

I have also different settings in fvSchemes and fvSolutions. Adjusting sizes of time step and grid cell did not improve the situation. Increasing nCorrectors to a very high value (e.g., 10+) seems to moderate said checkboard a little bit but does not completly eliminate the issue.

However, it disappears if the gravity effects are turned off, either by removing the gravity term (rho * g) from UEqn.H, or by simply setting the gravity vector to zero.

I don't know if the minimum Courant number condition is the culprit, I will need to look into this.

Otherwise, I don't know if there are other places I can look at. Aside from the observation that it is a result of compressibility and hydrostatic effects, I don't know much more how to proceed.

Gerry.

[tom_flint2012]

Gerry,

I have seen similar behaviour in a multiphase solver I created and added a diffusion term to. With this I had to have a smaller timestep. It may be worth dividing your timestep by 10/20 and seeing if you observe the same behaviour as a first thought.

[Gerry Kan]

Dear Tom:

Thanks. This problem is time step and grid independent. Last night I was thinking about fireFoam and how it handles hydrostatic pressure (I have another post on this a few weeks ago ... see link ).

The concept of p_rgh and ph_rgh are still a bit unintuitive for me, and I will have to think really hard on how I could reformulate my pressure boundary conditions. But I will give it another try to see this solves my problem.

Gerry.