Congratulation Dale! Obvious winner is 1 layer mesh: you provided the proof. I discovered it (on TET mesh, when checking NACAD0012 profile on a series of endless simulations I did not want to run, but Ric, you and I, were in a kind of competition). So it does extend to HEX mesh and the proof is an elegant advance in CFD practice. 
Thanks Retsam 
But you know me I have to do this:
But until we can determine that ‘blindfolded best practices’ meshes and sim setups using TET cells can closely match valid experimental wind tunnel results for NACA0012 airfoil, Ahmed 3D body and Drivaer Car , I will still think that all TET CFD sims as just eye candy… (I even still have some doubts about Hex meshes 
)
Once again Dale you have outdone yourself. These results are extremely useful, not only for a “best practice” methodology, but also for our design report when we present the car. I think this will give us some great feedback from the judges.
The U magnitude plots look awesome! Its crazy how much of a difference this makes. I made a nifty little GIF out of your pictures too.
I think at this point I am ready to go back to the full car simulations using the 1 layer approach. Im interested to see if we can apply this BL strategy to the rest of the car. I also want to do a simulation of the car using the old method and compare the results of those. Should be interesting
1 Like
Cool, but I like the arrow keys better since I can change the image at the rate I want to
.
.
.
.
.
Sooo, with much more thinking about how to use ORSI, I have come up with a realization 
The ORSI moving average filter does a GREAT job at predicting a single result value of interest if the result values are oscillating about a stable value
The problem lies in the fact that simulations currently do not stop when all the results values are nearest to their current ORSI value… This means that when your simulation ends (however triggered), you could be saving the full solution set of result values at any stage of their oscillations…
Even at 3000 iterations, both of these meshes’ sim runs have result values oscillating over about a 10% range…
So while we can predict a good single filtered value with ORSI, the solution sets will not represent data that represents those ORSI values… This means that my U magnitude images (based on solution set values at exactly 3000 iterations) WILL NOT SHOW WHAT WE EXPECT and in this case perhaps only within ±5% 
Here are those U magntude images at iteration 3000 (with the ORSI values at 3000i shown AND the percent variation from ORSI of the solution set data values at 3000 iterations…
.
This is just a caution post for when images from solution set data is presented…
.
.
.
.
EDIT: And even more importantly, this justifies the need to have ORSI… By that I mean, in the past people are generally just using the result values from the last iteration in their solver log when they say for instance that the CD of my sim results was 0.5 (or whatever). They likely even say that the results were stable without really knowing whether they were or not… They do not realize that if they stopped their 3000 iteration run just 15 iterations earlier the solver log could report at CD of 0.45 from the same run… (not so good is it)…
So if i understand you correctly, the fluctuations from the outputs need to be matched with the ORSI results where the exact time step or iteration is showing where we need to take the data from. In the pic below of the oscillating Cd has upper and lower limits. Is the average of these numbers enough or does the “true” value of Cd needs to be matched at where fluctuations are at the 1%, given to us by ORSI.
I understand that the visual aspect of the results is either at the last time step recorded, for what we have done at 1000, or when you manually stop the simulation.
What you are referring to is when the data output is taken when the simulation times out and the data given could be either at the top or bottom peak of the data oscillation correct? Therefore only numerical data can be trusted but the visual indicator of higher magnitude values, like we saw in the 1 layer boundary layer, is not accurate as it could be either the top, bottom, or middle of the oscillating values.
I will continue with full car attempts tomorrow
Yes if we want to visualize images and flow patterns etc (anything in a solution set) at the ORSI values. I think ORSI values most accurately represents the solvers idea of what its best guess at the best solution would be (it is always just guessing)…
See my explanation of a ‘visually’ obtained ORSI here
YES
I would say the ‘best curve fitted’ iteration based numerical values could be most trusted, not just numerical data… (I have shown a visual method of curve fitting and we now have ORSI by moving average curve fitting)… Full solutions sets are just snapshots in the guess process…
And here are some 1 and 3 layer Turbulence plots for discussion:
.
.
.
.
.
.
.
.
.
.
(Wow, I made my BMB outlet wall just far enough from the geometry here, I will do better next time
).
1 Like
So kinda a beginner question: i see you are using Magnitude and omega for the visuals. Any reason you are not using Velocity and Pressure? If i want to check the post processing in Simscale quick (i will most likely us paraview for almost everything now though) there are a lot of options. There is also normal and node data, i still need to research all of these and i also need to research nut.
There are even more oprtions then this
Because I am investigating the effect between 1 and 3 layer meshes and the biggest question I have is whether we are properly calculating properly the boundary layer turbulent area outside that single layer… The turbulence plots will show the turbulent area and as we can see the turbulent area is well outside even the prism cells of the 3 layer mesh (which I think is good if we are trying to justify 1 layer as a good replacement for 3 layers in some cases)… I should add a cell grid overlay to show the extent of the prism cells on the turbulence but it gets a little messy unless very zoomed in…
I showed the U plot, it looked good, so I skipped looking at P (perhaps I should)…
Ok i was just wondering which result selection to look at is best for either turbulence identification, looking at velocity or pressure, or for separation identification. I will research the other selections soon so i know what im looking at haha.
No, you have very good questions. I wish I could answer them better, perhaps your research will add some light here…
well i love reading thesis papers hahaha
I think the solvers only work on cell centroid data (I think that is maybe the Normal data)… In the end, I think ‘node’/point data is interpolated between cell centroids out to face corners (nodes/points) and this give what appears to be higher resolution ‘node’ results
So a quick search for nut info led to this which is the wall functions description from OPENfoam. nut is basically a wall function for turbulent kinematic viscosity conditions and helps determine Y+ readings. Basically way over my head. Ill just understand it as something thats needed but at this point i wont go too deep into this.
A way to use nut/nu to look at boundary layer encapsulation (I still haven’t gotten my nut/nu plots to look anything like theirs 
). But since nu is a constant, even the nut plots should look like their Eddy Viscosity Ratio (nut/nu) plots with only a scaling factor difference…
Thanks for the article! I have uploaded a full car model and am now running the mesh using your methods. Here is the link. I have used 1 BL cell for all geometries at 3.4mm and level 9 surface refinements for wings / suspension parts and level 8 for the mono and tires. Hopefully the region refinement areas will not have too many cells.
To combat a potential memory overload problem, if the total cell count is close to 30 million, perhaps your ORSI can help determine the exact iteration zone the sim should run to. Then, I can reduce the iterations from lets say 1000 this run to whatever the ORSI says (hopefully less then 1000).
Like you said it would be great if Simscale could automatically stop the simulation when everything is in the 1% fluctuation range. Would it also work, If I am making successive runs of the same geometry, and know when the simulation should be at 1% to just set the number if iterations to this level so that I dont have to monitor it?
Yes, you have a good understanding now…
In effect once you have determined a 1% ORSI iteration for a geometry (or very close geometry) and a mesh and a sim setup, I have not found the 1% iteration to change much… Of course, any final runs should be manually stopped at 1% indicated (not the educated guess of the 1% iteration)…
Don’t worry too much about your core hours depleting, I will make sure you have enough for this amazing project… I am also pretty sure, if you ask @jousefm nicely, that you could get some more core hours, heck I think we NEED you as a PowerUser…
2 Likes
Haha those are kind words. Im not sure im at the Power user level but i already have an agreement with Jousef about core hours because im technically sponsored with Simscale for my Masters thesis. I dont plan on needing an excessive amount because my plan is to have 3 simulations to match the 3 skid pad sizes. Then maybe a bit of optimization to change / verify / improve the center of pressure for the car. The entire goal of this project is to improve our cornering speeds through controlling the center of pressure location, which is basically done through increasing or decreasing the down force levels of front or rear wing. This allows the force exerted on the tires to be even on both axles ( if this is what we actually need - only the experimental results will confirm that)
2 Likes
@dschroeder, the offer is active! Good that Dale mentions it as I wanted to contact you anyway 
If you have the time and like to tinker around (like Dale & Andrzej do) we would be happy to have you as a PowerUser!
More information here: The PowerUser Program
All the best!
Jousef