CFD of F1T Modified PERRINN F1 Car

Here are our CFD links and discussions about aerodynamics, suspension, driver safety and tyres. Please stick to F1 on this forum.
Vyssion
150
User avatar
Joined: Sun Jun 10, 2012 1:40 pm

CFD of F1T Modified PERRINN F1 Car

Post by Vyssion » Sun Feb 10, 2019 1:02 pm

Hi all,

Recently, I decided it would be a nice idea to take the Perrinn F1 Car model which jjn9128 and I used for some of our halo and regulation articles, and build a CFD process around it to spit out some useful images that we may or may not use in the future for technical pieces. I have taken a few images from my post-processing script and put them here for you guys to enjoy and see what sorts of things this new CFD process can do.

A few things on the "quality" of the data...
  • I am using my home PC for the meshing and solving of this model and so my RAM and CPU power is quite limited in terms of what I am able to do
  • Domain was not split into a symmetry; it was solved as a full domain with 4 car lengths upstream, 7 downstream and 2.5 either side of (and above) the model itself
  • The mesh is only around 7.1 million elements and you will notice that some of the LEs are quite bad quality as a result of this... trying to mesh the entire model in a reasonable amount of time without cell count blowing right up was tricky, and yes, rest assured, I will locally refine from here... (I did actually cause my computer to crash quite a few times trying to just eek out a little more global refinement... so it will require manual attention and controls to really get it better). The wake region is "okay" close to the vehicle, however, it will require substantial refinement as evidenced by the "mushrooming" breakdown due to lack of grid resolution
  • Despite the limitations, and for those of you who understand meshing jargon, maximum skewness of cells was 0.94 which is not ideal, but is technically below the recommended 0.98 absolute maximum. Orthogonality and aspect ratio were also within the typical maximum guidelines, however, quite close to it
  • Some of you more keen eyed viewers may notice that there doesn't appear to be a contact patch... And you would be correct - the reason for this was that I wanted to get "something" working first from which I can then go back and improve - I will be fixing this
  • Wheels are all rotating in unison with the moving ground, which is fine, and camber and toe are taken into account for their rotation axis
  • The engine and sidepods are simplified by an outlet boundary condition whilst the exhausts of the engine and sidepods are simplified by an inlet coundary condition - exhaust was set at 600°C whilst the sidepods were set at 90° - I felt these numbers would be somewhat representable, however, they will probably be revised at some point... finally, mass is not currently conserved between the two boundaries, and so I do need to fix that
  • It was solved using the k-omega SST model with wall functions and an average y+ of around 60-80 depending on components (again, due to cell count limitations) and it was solved with mostly second order discretization schemes with the occasional first order when required for total energy equations
  • The CAD has been simplified from the original Perrinn model, again in the interest of efficiency
  • Lastly, there is no LIC as the post-processor couldnt do it and so the best I could muster were some tightly controlled surface streamlines; theres also something called an X-Ray plot that I have seen Total Sim use which sort of is a composite image of downforce and drag through multiple slices in a picture, thus showing you hot spots for lift/downforce and drag/thrust across a 2D image projection of the whole car... I need to see if this is something that I can create with the post processor or not as well
From this, with all these simplifications and a few more, the results showed somewhat comparable CzS and CxS numbers to the original creator Nic Perrin's results. I have no idea the specifics of his simulation, however, with all of the simplifications and the like going on, a CzS of -3.27 and CxS of 1.15 were within 5-10% depending on whose report that you look at of his model. I will refine this before quoting any numbers specifically, however, in terms of the actual use that we intend for this model, flow structures and the ability to capture reasonable quality of fluid flow will allow us to, if nothing else, use the images as examples to illustrate particular changes or features present in a flow; albeit simplified and perhaps not as "strong" as the real thing.

All in all, I am pleased that my little PC was able to handle it, and although it really pains my professional "CFD Engineer" OCD to be limited so much in what I can do with it, I do think as a first parse through, it did the job. I will do my best from here on to work on the surface mesh as much as I can, and bring it up to the same standard that I normally work to for my career; or at least, as close as my little workhorse can handle...

But for now, please do enjoy the images and ask any questions you may have to myself, jjn9128 or turbof1.

Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Last edited by Vyssion on Sun Feb 10, 2019 7:32 pm, edited 3 times in total.
"And here you will stay, Gandalf the Grey, and rest from journeys. For I am Saruman the Wise, Saruman the Ring-maker, Saruman of Many Colours!"

#aerosaruman

Just_a_fan
381
Joined: Sun Jan 31, 2010 7:37 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by Just_a_fan » Sun Feb 10, 2019 5:42 pm

Excellent post and great work. Well done! =D> =D>

Looking forward to this being developed as this is going to be very educational.
Turbo says "Dumpster sounds so much more classy. It's the diamond of the cesspools."

e36jon
39
Joined: Mon Apr 25, 2016 1:22 am
Location: California, USA

Re: CFD of F1T Modified PERRINN F1 Car

Post by e36jon » Sun Feb 10, 2019 7:08 pm

Really great to see the results along with the full list of ingredients. Can you please give a description of the machine you ran this on, your 'little workhorse'?

For those of us of a certain age we see results like this and think 'Supercomputer!' My how times change. In a couple of years we'll have a CFD app on our iphones…

Again, bravo, really spectacular to see these results. Thanks for sharing.

Jon

Vyssion
150
User avatar
Joined: Sun Jun 10, 2012 1:40 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by Vyssion » Sun Feb 10, 2019 7:26 pm

e36jon wrote:
Sun Feb 10, 2019 7:08 pm
Really great to see the results along with the full list of ingredients. Can you please give a description of the machine you ran this on, your 'little workhorse'?

For those of us of a certain age we see results like this and think 'Supercomputer!' My how times change. In a couple of years we'll have a CFD app on our iphones…

Again, bravo, really spectacular to see these results. Thanks for sharing.

Jon
3.8GHz Intel i7 quad-core with 16Gb RAM and a 1060 NVidia 3Gb GPU... Unfortunately hyper-threading doesn't really benefit CFD and so I was kinda restricted on running to only 4 cores. The GPU maxed out its VRAM whilst I was running the script to produce all the images since they were in 4k, and theres over 100 produced each run... I mean, what I have is no "potato", but compared to the beast I have at work, it leaves quite a lot to be desired........

As for the CFD app on your phone? Well... There is already one that was produced by Numeca (a meshing, CFD and FEA software company): https://www.algorizk.com/ (the bottom one is the one I have). It isn't "strict" CFD, but it is 2D simplified and solved in real time if i remember correctly.... It allows you to draw shapes with your meat hooks and let it run... You can vary Re and a few other parameters or load up some of their pre-drawn shapes like a motorbike or something. Its more a sort of thing I use when people ask what I do and just showing them a picture or two like above doesn't quite cut it.
"And here you will stay, Gandalf the Grey, and rest from journeys. For I am Saruman the Wise, Saruman the Ring-maker, Saruman of Many Colours!"

#aerosaruman

Callum
7
User avatar
Joined: Sun Jan 18, 2009 2:03 pm
Location: Edinburgh, Scotland

Re: CFD of F1T Modified PERRINN F1 Car

Post by Callum » Mon Feb 11, 2019 2:01 pm

Can you explain why symmetry was not used?

jjn9128
142
User avatar
Joined: Tue May 02, 2017 10:53 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by jjn9128 » Mon Feb 11, 2019 2:31 pm

Callum wrote:
Mon Feb 11, 2019 2:01 pm
Can you explain why symmetry was not used?
It allows for future study of yawed cases using the same mesh. Generally symmetry isn't great even though you can save some cells - the aero wont necessarily be symmetric so you get deltas to full car cases unless you use big averages.
#aerogandalf

Vyssion
150
User avatar
Joined: Sun Jun 10, 2012 1:40 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by Vyssion » Mon Feb 11, 2019 2:49 pm

Callum wrote:
Mon Feb 11, 2019 2:01 pm
Can you explain why symmetry was not used?
This is a teeny bit due to my "perfectionist" OCD seeping into my methods setup, but also due to future cases we intend to run. In general, the symmetry condition forces a few different contraints on the boundary, and any geometry which touches it:
  • The fluxes across a symmetry are zero
  • The normal components of velocity are set to zero
  • The normal components of all other variables are set to zero
Given that the most interesting fluid behaviour is transient (and therefore not necessarily symmetrical) in nature, imposing a symmetry condition at the centreline which "forces" all flux and normal components of vairables to zero would result in inaccuracies with the result.

I tend to steer clear of symmetry planes, if I can help it, because they also (sometimes) can produce non-physicallities in the flow results right up close to the interface depending on a few different reasons. I do use them for quick and dirty simulations, however, as I am not chasing accuracy there.

Now, of course, this model here is a very coarse sim, and to be fair, one could quite rightly argue that the inaccuracy brought in by the symmetry boundary condition would be inconsequential compared to the other approximations and assumptions made. However, we do intend to do some yaw cases in the future, and so in preparation for that (and to check that my machine can actually handle it) the entire domain was meshed to preserve comparability and "ease" when it comes time to do those studies as you cannot do those types of simulations with a half-model domain.
"And here you will stay, Gandalf the Grey, and rest from journeys. For I am Saruman the Wise, Saruman the Ring-maker, Saruman of Many Colours!"

#aerosaruman

variante
89
User avatar
Joined: Mon Apr 09, 2012 10:36 am
Location: Monza

Re: CFD of F1T Modified PERRINN F1 Car

Post by variante » Fri Feb 15, 2019 3:04 am

Super cool! Hope you are planning to run a modified version of the car...it would be fun to analyse the differences.

As for the mesh, this is the exact comment i wanted to make:
Vyssion wrote:
Mon Feb 11, 2019 2:49 pm
Now, of course, this model here is a very coarse sim, and to be fair, one could quite rightly argue that the inaccuracy brought in by the symmetry boundary condition would be inconsequential compared to the other approximations and assumptions made.
And I still think that is a valid argument, despite the yaw scenario you are planning (being RAM limited, i would deal with yaw separately). The quality you are getting from those 7 million cells is surprisingly good on those surfaces, but i'm still not convinced. In fact, i did run an F1 model a while ago, and the details that i was losing with a coarse mesh were a bit too many. I ended up running the simulation with a simmetry and 14 million cells in order to achieve a very satisfying result. Something less would be good too, anyway. Not sure how Ansys deals with RAM, but 16 GB might be enough.

This was the model i used, with LIC visualization to complete the array of images that you kindly provided:
Image

jjn9128
142
User avatar
Joined: Tue May 02, 2017 10:53 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by jjn9128 » Fri Feb 15, 2019 10:05 am

variante wrote:
Fri Feb 15, 2019 3:04 am
Super cool! Hope you are planning to run a modified version of the car...it would be fun to analyse the differences.
There may be plans afoot to put some 2019 wings on it.... sorry Vyssion :wink:

It depends on timing and how it can fit around other commitments - this model has been a hassle to get working in CFX at all - loads of surfaces to fix and low quality surfaces to contend with e.g the rear wing gurney flap wasn't actually attached along the flap trailing edge, how it was made also meant there were load of tiny elements we had to try and remove, also there were no splits at the leading edges of the elements to finesse the mesh quality.

Image
Gurney flap at the slot gap separator on the centre of the wing.
#aerogandalf

Vyssion
150
User avatar
Joined: Sun Jun 10, 2012 1:40 pm

Re: CFD of F1T Modified PERRINN F1 Car

Post by Vyssion » Fri Feb 15, 2019 11:58 am

jjn9128 wrote:
Fri Feb 15, 2019 10:05 am
variante wrote:
Fri Feb 15, 2019 3:04 am
Super cool! Hope you are planning to run a modified version of the car...it would be fun to analyse the differences.
There may be plans afoot to put some 2019 wings on it.... sorry Vyssion :wink:

It depends on timing and how it can fit around other commitments - this model has been a hassle to get working in CFX at all - loads of surfaces to fix and low quality surfaces to contend with e.g the rear wing gurney flap wasn't actually attached along the flap trailing edge, how it was made also meant there were load of tiny elements we had to try and remove, also there were no splits at the leading edges of the elements to finesse the mesh quality.

Gurney flap at the slot gap separator on the centre of the wing.
Pretty much sums up the future plans and what had to be done with it. Suffice to say, once I realized the "level" of CAD quality that I would need for it vs. what was exported out of OnShape, I spent around 6-8 hours patching up errors like this, and preparing surfaces to be meshed easier (i.e. removal of spikes, slivers, etc.). I'm a firm believer of "if you put --- in, you'll get --- out". And so, I felt it was well worth the effort, despite the frustrations and annoyances at the descovery of yet another issue to be corrected...




variante wrote:
Fri Feb 15, 2019 3:04 am
And I still think that is a valid argument, despite the yaw scenario you are planning (being RAM limited, i would deal with yaw separately). The quality you are getting from those 7 million cells is surprisingly good on those surfaces, but i'm still not convinced. In fact, i did run an F1 model a while ago, and the details that i was losing with a coarse mesh were a bit too many. I ended up running the simulation with a simmetry and 14 million cells in order to achieve a very satisfying result. Something less would be good too, anyway. Not sure how Ansys deals with RAM, but 16 GB might be enough.
Just on this point, again, there were lots of CAD operations to "help" the mesher along which meant I could get away with quite a few less cells than I started with simply by the geometry no longer needing to refine down levels to capture the discontinuities in the surfaces etc. The removal of the DRS flap as well as brack ducts and the internal geometry (replaced with BCs for intake and exhaust) meant that there is quite a decent chunk of cells that I could just cut out completely.

I definitely agree with you that there are a lot of the flow structures and regimes that are numerically diffused out through lack of resolution, however, I have a plan for local refinements and other meshign changes which I am hoping to impliment this weekend, assuming I get time for it. The surprising accuracy was exactly that: surprising, to me. However, with how much CAD and Surface Mesh refinements I have done to this model, I was expecting somewhere in the region of 10% for Cz and maybe 15-20% for Cx, given the difficulties of Cx calculation vs. Cz. I am not above admitting that there is potential here in the convergence of it being simply a "fluke", however, we shall see how it goes with the new changes I'm looking to add, and yes, the cell count will rise.

I bought new RAM for my PC to take it to 32Gb the other day, and so I am expecting meshes in the realms of 15-20 million not out of reach (though still not fully resolving to y+ = 0.5). Assuming that does not take an exorbitent about of time, given ANSYS innate mesher is a serial only function... -sigh-.... In a lot of ways, I miss working with OpenFOAM given you have so much more control and authority over how the CFD method executes. Having said that, robustness of a commercial code is nice at times :D

The use case for this is kinda suited tothe 90-10 rule: 90% of what we are looking to do, can be achieved with about 10% of the effort. Of course, if I was required to chase to the nth degree for performance or correlations etc, then it would have to be 99-100 rule :lol:
"And here you will stay, Gandalf the Grey, and rest from journeys. For I am Saruman the Wise, Saruman the Ring-maker, Saruman of Many Colours!"

#aerosaruman