Pressure Checkerboard Patterns in Vehicle Aerodynamics Simulations

[finzeo]

Hello everyone,

As I mentioned in some other posts, I am simulating the flow around ground vehicle models in a wind tunnel using version 8.0. After many runs and analyses, I managed to match the numerical results with the experimental data (https://ntrs.nasa.gov/citations/20010038028); however, upon visually inspecting the solution, I notice the presence of checkerboards in the pressure field (see image 1). It's a vehicle similar to the Ahmed body with a 14° yaw angle; the image corresponds to a top view of the midplane. Flow is from left to right.

Despite numerous runs and changes in the setup, this issue persists to varying degrees. Starting from a uniform velocity initial condition, this checkerboard does not appear initially, and the residuals are smooth (without significant oscillations). When the vehicle wake reaches the 1:2 mesh expansion near the outlet patch, the checkerboard starts to form, and pressure residuals begin to oscillate (see image 2; don't mind the oscillations seen in the omega variable; that was resolved with others advection schemes easily). This persists over time and even becomes more pronounced, though the simulation does not diverge or abort.

Analyzing drag values, side forces, pressure coefficients at specific positions, and friction coefficients at specific points yields very good results, but I suspect this checkerboard might be influencing these outcomes. Here is a list of different setups I tried without success:

1. Variation of advection term schemes: From central differencing to high upwind blending and other intermediate schemes, none resolved the issue.
2. Solver and preconditioner setup: Focused on those used for pressure; tried all available solvers for pressure without significant changes
3. Gradient calculation strategies: Switched from least squares to Green-Gauss, with first and second-order limiters in the former, and varying climgr, without resolving the issue.
4. Using a different turbulence model: Currently using SST DDES for transient history; switching to RANS SST still shows checkerboards.
5. Increasing solver precision: Set all solver precision variables epsilon to 1e-8 and increased RHS iterations, but the issue persisted.
6. Tried imvisf=0 and imvisf=1.
7. Tried rcfact=1 and rcfact=0 (as Rhie-Chow is related to checkerboards), without success.
8. Outlet boundary condition: Using BC outlet without manually setting pressure; using BC pressure outlet (setting outlet pressure) did not improve the issue. Attempting to set reference pressure position in cs_user_parameters.c is ineffective (seen in another post).
9. Extending the refined mesh zone: To avoid a 1:2 transition in the wake region, currently in progress.

If needed, I attach the run files that may be helpful. I can also provide the mesh via a link, as it is ~1 GB (ask me). Any guidance or suggestions on what else to try would be greatly appreciated.

Thank you very much.

[Yvan Fournier]

Hello,

What CFL number do you have ? Checkerboarding can appear in areas where the time step is very small relative to the mesh size and velocoty, so that the Rhie&Chow coupling (which is unfortunately sensitive to the time step) becomes less effective. I am not aware of checkerboarding in other cases.

So the most influential parameter is usually the time step.

Best regards,

Yvan

[finzeo]

Hello Yvan,

Yes, the time step I am using is extremely low. Here I attach part of the listing.

The issue is that if I perform a temporal convergence study focusing on the drag, Cp, and Cf values, I notice sensitivity if I go above dt=5e-6 seconds; below this time step, the results remain quite stable. My previous post about using second-order time discretization aimed to use a relatively higher dt while still maintaining the convergence of drag, Cp, and Cf (initially, to have less expensive simulations, but now this would be an additional motivation). However, enabling second-order time discretization only in the terms that do not throw an error did not result in an improvement.

Regarding what you mentioned about Rhie-Chow, I understand that with the rcfact parameter, one can switch between using the factor dt or 1/A_u. I tried both ways (rcfact=0 and rcfact=1), and this did not improve the issue. Is there anything else I could try varying in the Rhie-Chow interpolation setup? I would prefer not to increase the time step because the results would not be converged.

[Yvan Fournier]

Hello,

I mentioned your post to other colleagues who have more expertise in the numerics of the code, and I'll remind them to check, but I know of no option more relevant than adjusting rcfact, using a local time step (pseudo-steady option), or changing the mesh.

In you listed options, I do not see a mention of the local time step (pseudo steady) option. If your flow is a steady flow, that would be the first (and best) option to test.

Best regards,

Yvan

[finzeo]

Hi Yvan,

Thanks for your response. I have continued testing various possibilities:

• Changing rcfact did not help; I understand that in both cases (=0 or =1), there is an approximately proportional dependence on dt in the Rhie-Chow term that adds diffusion. I tried using a dt ten times higher (5e-5 s) and noticed that the checkerboard effect significantly decreases, but at the cost of some accuracy (generally, the errors relative to experimental data increased from 1-4% to around 10%).

• Additionally, I modified the mesh: I extended one of the refinement zones near the vehicle to the patch outlet, which eliminated the checkerboard effect downstream, although it is still noticeable towards the sides of that refinement zone (see attached image). For reference, I am attaching a video showing how the pressure varies over time (I am using BC outlet, which I understand automatically sets a reference pressure value).

• Moreover, using the pseudo-steady option is not useful for me as I need to know the transient history (in fact, I am using the DDES turbulence model).

I believe that the mesh modification is a satisfactory solution, but it is a major headache to resort to such low time steps to maintain accuracy. I know I made another post about this earlier, but perhaps now, presenting all this information, you might have some suggestions to achieve less sensitivity with the time step.

Thanks in advance for any advice.

[Yvan Fournier]

Hello,

The sensitivity to the time step is a headache for us too, though recurring posts on this forum are quite interesting, as they add important knowledge and insight, and this issue is often forgotten, as it is much more sensitive for some types of computations than for others (for example a user reported high sensitivity in LES that we had not encountered, due to using a fluid with very different density than those we usually handle). But if we had a simple solution, we would have deployed it. The staggered approach used in CDO could help but this is long term work, and models currently handed with CDO do not include turbulence at all.

Another user posted to an interesting article regarding a similar subject (https://github.com/LIHPC-Computational- ... agix3d.git), but I do not think we have looked at it yet, so cannot say whether it is similar or not to things we tried.

Regarding the second order time stepping, I'll mention specifically to the developer of our DES module, to check if he has any ideas/suggestions.

Best regards,

Yvan