[scipy]

Hello.

I am working on my masters thesis (calculating force coefficients depending on vehicle spacing) and I'm stuck. I validated the experiment by Vino/Watkins done on Ahmed body (30° slant) where they varied x/L from 0.125 to 4.0 and there was no single problem to report.

My meshing approach was this: I made a pure hexa tunnel in ICEM CFD so I could have a satisfactory y+ on the floor and then cut out two cuboid shapes (let's call them car-boxes) where I'd fit the separate hexacore meshes for the bodies made in combination of ICEM CFD and TGrid (Fluent meshing). Since picture is worth a thousand words, here's one:




Screenshots are from the symmetry plane but it's clear how it works.. there's an interface between the tunnel boxes and carboxes, element sizes are nearly matched at those interface, accuracy is great, all the cases converged easily and there was no NASTY prism growth with larger surface triangles that would've usually been on the floor behind the car. Screenshot is of a single vehicle, but obviously I made several tunnels with boxes at difference spacing and just used TGrid to copy/translate the single carbox mesh rearwards. So, the important thing is: there's only ONE car mesh and then it gets copied and translated longitudinally. Exactly the same number of nodes, cells and everything.

I was happy with how "smart" I've been... Now I'm not.

This was all done as a validation of the meshing etc, before I moved on to a more realistic and complex geometry (something resembling a Porsche 911 with a wing made of LS-413 airfoil). Now again.. a single carbox in a tunnel (reference case to obtain Cd/Cl/Cm when no other cars are present in the vicinity) works flawlessly and converges quickly, y+ is unbeatable for the element size and resources used, all good!

However, when two cars are present in the tunnel I am confronted with something I can't quite explain. Pictures following:

Click on the images to get 2560x1600 resolution!

The mesh:


The mesh with cars with y+ distribution plotted:


Front car wheel arch/side without any problems:


Same exact mesh (translated by 1,125 * L along positive Z axis) with a fucken problem - look at the little red spot on the front wheel arch transition onto the side:



Residuals:


Screenshots you are looking at above are from ~565 iterations when k & epsilon started jumping around for the 3rd time.

Local y+ goes to 400-500 at that little area on the wheel arch. k goes to like 40 000 m2/s2 instead of being in the hundreds, pressure goes berserk.. everything starts going to hell.

My question is: WHY? It's the EXACT SAME mesh down to the node count, cell count, position, everything. It passes every mesh check for negative volumes, face handedness, penetrating elements and bla bla bla. Locally the surface mesh is of high quality and the prisms that were grown are of high quality too (first aspect ratio 5, 5 layers, 20 % growth), nice smooth transition into the first tetra layer and then to hexacore. Max element size is 20 mm and so is the interface on the tunnel.

I've also done a x/L = 4 case and ran into a similar problem but this was on the rear wheel (where the spider meets the rim). I thought it was a mesh problem because some elements got moved around during smoothing in ICEM, so I fixed them by hand (there were some typical "pitched tent" structures, dissassociated mesh from proper surface etc). But it seems that these problems will appear at a random place on the car and ONLY at the 2nd car depending on the inter-vehicle distance.

I was thinking about it and ICEM CFD is an octree mesher and everything is divided/multiplied by 2, so my surface elements were 2/4/8/16 mm on the car (16 was maximum) and I guess when the mesh is exported to .msh and I move it in TGrid by a "non-factor of 2" number (say vehicle length is 4,392 m and for x/L=0.125 it was 4,392*1,125 = 4,941 m - this could potentially cause a problem for the solver? I guess I could try moving the 2nd car by a couple of mm forward/backward to see if this will affect anything, but why didn't I have this problem in all the 13 cases of the Ahmed body simulations done in the exact same way?

What I've tried up till now: adapted the local mesh based on y+ in Fluent (refined it), but this just resulted in total divergence a few moments later (look at residuals) where the flow started going towards the 2nd car from all directions and I had a y+ of 1500 on the underbody and shit like that.

If anyone has any ideas: PLEASE do help because my deadline to have all 13 cases finished (and the thesis written up) is 10.7.2015 and each case takes 12 hours to converge (if it would start converging instead of diverging and being a pain in the ass).

Thank you :/

[PSYMN]

It looks to me like you did a great job, but found something very strange. I don't think the issue has anything to do with octree or copying it a specific distance back...

Does the mesh actually look different in that area? I assume it is exactly the same when first imported. Does it change when you merge with the hexa mesh? I wouldn't expect it to because it is so far from the interface, but it would be good to know.

You are in crunch mode, so maybe you want to talk work arounds in case we can't solve it in time... How do you feel about just deleting the trouble mesh in that area? Use the subset controls to add volume elements until your subset includes a little ball of elements, and then delete them. You can then remesh the void or just cover the uncovered faces (so it will appear like a little ball hidden under that wheel well)...

[scipy]

:/

Tried moving the second car by 1 mm rearward but no luck.. same thing happens at 230 iterations.

Will be moving the mesh in ICEM now and try renumbering the elements or something to see if changes anything.

Other than that, I'm out of ideas.

[flotus1]

Since you did such a good job so far I almost dont dare to ask: you already went through the usual steps like using first order upwind schemes and reducing under-relaxation factors? Focus on k and epsilon in the first place.
And which turbulence boundary treatment are you using? "Standard" or "enhanced" wall treatment?

[scipy]

Originally Posted by flotus1

Since you did such a good job so far I almost dont dare to ask: you already went through the usual steps like using first order upwind schemes and reducing under-relaxation factors? Focus on k and epsilon in the first place.
And which turbulence boundary treatment are you using? "Standard" or "enhanced" wall treatment?

Hi,

I didn't think to mention any of that because it was all proven to work on all the test cases and the single car mesh. But here it goes anyway:

Solver is Coupled (single precision, no room for double in the RAM but it's unnecessary anyway), I'm using RKE model with NWT wall treatment (y+ is < 30 only on unimportant parts where the air is moving slowly and the friction component is insignificant), I used first order upwind for the first 30 iterations or so (for k & epsilon, everything else was 2nd order by default) and then switched to 2nd order. URFs were decreased and are 0.25 for both momentum and pressure (because the mesh is of pretty high quality things tend to get transient and start oscilating if I increase URFs). Courant is 50 (decreased from 200). k and epsilon URFs were left at default at 0.8 since this was never a problem at any point before, I've decreased turbulent viscosity URF to 0.8 at the start and then back to 0.95 and under limits I've increased max. turb. viscosity ratio to 10^7 because sometimes at the start of the case there's a warning about that.. I know some people worry that it's unphisical and if you're getting the warning there's a problem with the mesh, but there isn't one It goes away after some iterations anyway and this spares me the crappy messages. It did go above 10^7 at the beginning for this case too, but soon disappeared.

Basically, all the settings I'm using I've tested before and they're such for a reason. This singularity problem just appears out of nowhere after the initial ~200 iterations. I've actually stopped the solution and looked at y+ and Cp at the wheel arch transition and it was all good, 15 iterations later a huge spike in residuals, I immediately stopped it and looked again.. and there it was, the goddamn red zone of a few elements (y+ for example went to 1400 all of a sudden, and was ~60 before).

Tomorrow I'm trying to move the second car mesh in ICEM CFD instead of TGrid (but moving the already made volume mesh from TGrid), after that I'm going to try and move the surface mesh in ICEM before ever going to TGrid and then do a hexacore mesh from the already moved surface mesh. If none of the above fixes the situation I'm just gonna write a bunch of values in Excel and make them follow a common trendline from the Ahmed body cases, take a few snapshots of the beautiful velocity/y+ distributions @ ~200 iterations before everything goes to shit and use that.

[flotus1]

k and epsilon URFs were left at default at 0.8 since this was never a problem at any point before, I've decreased turbulent viscosity URF to 0.8 at the start and then back to 0.95

Just based on the residuals in your figures I would give it a try and decrease the URFs for these three quantities aswell. And keep the first order upwind schemes for a longer amount of iterations.
What is the reason you are using the coupled solver? Have you tried SIMPLE instead?
Have you made sure that the problematic cells are actually in the mesh you copied from the first one or would it be possible that the problems occur on the mesh of the second car that happens to be behind the car in the front?

[scipy]

Originally Posted by flotus1

Just based on the residuals in your figures I would give it a try and decrease the URFs for these three quantities aswell. And keep the first order upwind schemes for a longer amount of iterations.
What is the reason you are using the coupled solver? Have you tried SIMPLE instead?
Have you made sure that the problematic cells are actually in the mesh you copied from the first one or would it be possible that the problems occur on the mesh of the second car that happens to be behind the car in the front?

Well, I can try to decrease the URFs for those, but you can see from the diagram above that the convergence up to ~200 iterations is great and nothing wierd is going on. The reason for using 1st order upwind for a longer time is usually when you have a convergence problem early on - which isn't the case here. I was actually running the cases for a single car in the tunnel with 2nd order everything right after the Hybrid initialization is done.

Coupled solver converges like an order of magnitude faster than SIMPLE (yes, it does use 50 % more RAM to do it, but I've used it since the start and I don't have the time to wait for SIMPLE to do 5000 iterations where Coupled does it in 300). Again, SIMPLE is faster per iteration but overall Coupled is still at least 3x faster in my experience.

As far as problematic cells go: I don't think there are any problematic cells because when I ran a case of x/L=4 then the singularity appeared at the rear wheel spider, when I ran x/L=0.125 it happened at the front wheel arch. I will try to run a x/L=0.250 this evening & over night and see. But I suspect the same thing will happen.

What I'm actually doing now is running the 2nd (copied & translated mesh) in a single car variant, just to make sure it isn't a mesh problem but this suspected "translation/movement" problem. So, it's the copied carbox mesh in a tunnel with a single box (the reference case to obtain drag/lift/moment for an isolated car).

[scipy]

Just an update for anyone still interested..

I've tried moving the following car's surface mesh in TGrid and then making the hexacore, so I end up with two different meshes and not an identical translated one - problems still occur.

Then I tried going from zero and I solved 600 iterations of Inviscid flow (350 in 1st order, 25 0 in second order) - residuals went flat and all seemed ok. Switched to RKE and kept only the k & epsilon on 1st order upwind for 500 iterations. Everything was converging beautifully and residuals dropped to 10^-3 (k&epsilon). Here's a screenshot:



Then at around 1100 iterations I switched to the 2nd order upwind for k & epsilon with URFs at 0.6 for both and 0.8 for turb. viscosity. Everything seemed OK for 200 iterations and then k & epsilon started diverging.



I stopped the solution and looked for the problem, and as expected it's the following car at the front bumper (stagnation point). Some crap is going on there and I can't really explain why, but it only happens when k & epsilon are switched to second order.

Now, my question is.. obviously, 1st order upwind schemes aren't all that accurate. But what I noticed with my case of "only one car in the tunnel" is that when I switched to second order, only the residuals dropped even further - the integral values just continued like they were.. Coefficients of drag/lift/moment didn't change by much. I took this as a good sign since I wasn't doing a grid independence study, I just made a mesh with a max. number of elements that would still fit in my RAM. From what I remember reading early on, if a switch to second order doesn't really change things much, you have a quality mesh. QUESTION finally, if I just left k & epsilon at 1st order upwind accuracy, results are still valid and within a few % of what they would've been at 2nd order, right?

[Far]

Although this thread is old. But just a question why would you go for second order scheme for turbulence?

[scipy]

Originally Posted by Far

Although this thread is old. But just a question why would you go for second order scheme for turbulence?

I just follow the general advice for the solver: that 2nd order discretization yields more accurate results, while 1st order provides more "robust" convergence. So, 1st order for the initial n iterations and then switch to 2nd order to obtain a better end result..

[Far]

Originally Posted by scipy

I just follow the general advice for the solver: that 2nd order discretization yields more accurate results, while 1st order provides more "robust" convergence. So, 1st order for the initial n iterations and then switch to 2nd order to obtain a better end result..

Ok. Let me rephrase question.

2nd order scheme for mometum, energy is requirement for higher accuracy and also a must while submitting research paper to well reputed journals.

Same is not the case with turbulence. As you know that turbulence modeling for the RANS is already is very huge approximation. So there is no point of making any rough approximation (by nature) more accurate by solving it through second order scheme.