CFD - PERRINN F1 Car (w/ spec mods)

[jjn9128]

Does the model have flow through the sidepods? I'm guessing it doesn't as that would be a lot of work to do properly, but it would be interesting to know how the flow through the car changes the flow around the car.

We do not have through flow with this model. The internal geometry of the Perrinn is fairly rough'n'ready anyway so we chose to block the inlets using an outlet boundary condition and conserve mass to the cooling exit (which has an inlet boundary condition), which is also given a temperature parameter.

With a slightly different version of the car (he did 13 design iterations) Perrin reported a 0.9 on CzS difference between blocked and open sidepods - I don't think he used any boundaries to simulate that through flow though.

Everything makes a difference for total accuracy, but at the current mesh resolution (at least 1 order of magnitude lower than F1 teams) there are other things to focus on.

[Just_a_fan]

I didn't mean that you should focus on the through flow, as I'm aware that to do it in a meaningful way would be very time consuming. I was just interested in how the flow might change the outcome, particularly with respect to the wake.

Just guessing, but I would think that having a hot airflow mixing in to the wake will affect a following car's aero performance. After all, we do hear drivers being asked to pull out of the wake to cool the car in certain situations. So the amount of heat energy in the wake must be significant. That heat will reduce the density of the air in the wake, if only by a small amount. I'd be interested to know what, if any. meaningful effect that has on the following car. Or is the cooling of the following car solely caused by the turbulent air being less effective at cooling the following car?

I realise this is outside of the scope of your current project, but then good work does, by its nature, pose further questions and point to other areas of study.

Keep up the good work on the project. It's fascinating stuff.

[jjn9128]

I didn't think I was being all that defensive for once I think we've got less of an impact from blocking the sidepods because we're outletting the air as would enter the side pod and putting it back into the stream at the back.

This is a plot from RaceTech Mag comparing the wake of the Perrin (contours) to a more developed car (dashed lines) which shows just how underdeveloped the Perrin is - I think I've mentioned in the past it is 30-40% down on peak downforce compared to a proper car.

Just guessing, but I would think that having a hot airflow mixing in to the wake will affect a following car's aero performance. After all, we do hear drivers being asked to pull out of the wake to cool the car in certain situations. So the amount of heat energy in the wake must be significant. That heat will reduce the density of the air in the wake, if only by a small amount. I'd be interested to know what, if any. meaningful effect that has on the following car. Or is the cooling of the following car solely caused by the turbulent air being less effective at cooling the following car?

It's an interesting question, hot air is lower density than cold air, so air temperature from the exhaust and rads will directly reduce downforce produced by the car behind. I believe the effect will be smaller than the effect of the wake, which will also be reducing airflow into the cooling ducts - which is fully dependant on the flow over the nose, front wing, suspension and bargeboards - which are all impacted. I think the hot air effect is also contained closer behind the lead car.

[Just_a_fan]

It's an interesting question, hot air is lower density than cold air, so air temperature from the exhaust and rads will directly reduce downforce produced by the car behind. I believe the effect will be smaller than the effect of the wake, which will also be reducing airflow into the cooling ducts - which is fully dependant on the flow over the nose, front wing, suspension and bargeboards - which are all impacted. I think the hot air effect is also contained closer behind the lead car.

That makes sense.

[Vyssion]

Got some more "informative" gifs for you all to enjoy. All of them are from simulations performed at 50m/s w/ 4° additional side-gust

I figured it would be a good idea, off the back of our latest two articles, to generate a few more gifs showing some additional details on how the 2018 to 2019 aero changes have affected the car.

The first shows a CpZ (that is, pressure coefficient multipled by the surface normals in the z-direction = a "loose" downforce showing contour) and you can quite clearly see how well the floor is working on the baseline Perrinn despite the sidewind, and then how drastically that changes for the other two, with the sidewind showing a much more significant effect on the downforce in the leading part of the floor.

The second and third images showcase how the vortical structures around the car have changed from above in terms of CPo and below via Lambda2 criteria. Once again, the amount of outwash generated by the baseline Perrinn, even under the sidewind, is very noticeable when compared to the modified version, of which our own 2019 initial design manages to recover a somewhat decent amount of that outwash. You can clearly see that the wakes of the wheels are almost dead straight behind the tyres for the modified car. Which feeds into the 4th gif showing velocity streamlines and contours in the local region of the wheel wake. The twisting of the wheel wake region is a good indicator on how well the flow is being managed, with more outwash at the lower portion of the wake being ideal. Seeing how the wake at the top of the wheel also changes when compared to the baseline is also quite interesting given the cascade elements are now also gone. Overall, I think, at least with our models, the wake of the wheels have also increased in width.

Finally, the 5th and 6th showcase the FW wake which moves into the Wheel + Halo wake as well. Again, it is quite easy to see how the outwash and downwash characteristics of each car are different. I thought it was interesting to see the separation off the suspension A-arms too, as well as seeing how the inner tyre squirt + FW strake vortices interact.

Anyways, currently each simulation kicks out around 160 images which I create at least 3 standard gifs from. Then I create ones between the car models too. Please do throw me your suggestions for additional imagery which you think could be interesting to see within a single case or from case-to-case and I'll pull up the results and see what I get. I do want to look onto plotting a few different variables to see what comes out [in the] wash... hehe, get it? "out-wash" -slow clap for vyssion- (yes, I'll wait...)

[kyky-pyky]

Please do throw me your suggestions for additional imagery

First of all, thank you for your amazing work!
Could you simulate the car with "ferrari style" fw in a corner? As simple as angled wind and angled front wheels, disregarding the roll.
It seems, that this style of fw has some anti-roll function: with front wheels turned in it is "bleeding" some downforce on the outer half (to the corner) of the wing, but increasing downforce on the inner half, since the airflow is restricted by the inner wheel.
Hope my explanation is clear enough)

[Vyssion]

Please do throw me your suggestions for additional imagery

First of all, thank you for your amazing work!
Could you simulate the car with "ferrari style" fw in a corner? As simple as angled wind and angled front wheels, disregarding the roll.
It seems, that this style of fw has some anti-roll function: with front wheels turned in it is "bleeding" some downforce on the outer half (to the corner) of the wing, but increasing downforce on the inner half, since the airflow is restricted by the inner wheel.
Hope my explanation is clear enough)

TLDR, its a lot more complicated than you may think to accurately model a cornering manoeuvre... But I am aware of this difference, and I do have plans further down the line to try and at least cobble some semblance of this together for you all. I will bold the important parts in the post if you want to skim over it.

------------------------------------------------------------------------------------------------------------------------------------------------

Thankyou for complimenting the work -- it has been quite a long and arduous thing in order to develop a process which is "somewhat" reliable in execution, but I would say that the results have been worth it... Even if it does erk me to no end that I don't have the computational power to take it to the next level...

There have been a few people who have suggested this sort of thing; i.e. a cornering simulation. I wrote out a long reply to one person recently, and so I'll use that as my answer to this in order to same a bit of time rewording it all out again.

------------------------------------------------------------------------------------------------------------------------------------------------

To address your suggestion directly, it is in fact, something which we have already thought about and - at least for now - opted to not take into account. F1 teams never really CFD their cars in perfect straight on conditions, and that is why the latest batch of gifs have all been created based on imagery from the 4° sidegust cases. The reason for the straight ahead simulations was more along the lines of giving is some sort of "correlation" to what Perrinn had made publicly available in order to check whether we were in the right ballpark. As for the 4° choice specifically, it was somewhat of a "limit" before which we felt we would HAVE to change the front wheel sideslip angles to be honest. 50 m/s is quite a common speed at which F1 teams perform their CFD analysis, however, in addition to this, they also model usually a curved domain (or at least curved flow) with road camber, which is the better way to model a car going around a corner - given the cars roll under load being simulated by the road camber, and the curved flow giving some sideways component whilst taking into account the fact the car is yawing through a corner, rather than just a sidegust.

Once I talk myself into buying my new computer (its a metric shitload of money... -sigh-) I will most likely be unable to help myself from looking into implementing more "higher fidelity" capturing aspects in meshing and solving, but right now, I am limping along with a machine which has already had a RAM stick and SSD die on me already

The curved domain flow is VERY tricky to get right, and it actually is something I have never personally done before... I can "kind of" see how I could "hack" it by creating a sector of a circle large enough to have a car perhaps like 80% of the diameter out from its centre (allowing for all the 2.5x car lengths in front, side and up as well as ~6 behind - so a HUGE sector...) and then setting up a periodic boundary condition between that sector and a blank sector and then knitting those meshes together to form a huge circle mesh, and then setting that entire domain as a rotating frame of reference with soem angular velocity equivalent to 50m/s at the cars location.................................. but there has to be an easier way

As for steering angle, you're probably correct that we should at least have "some" amount of correction... perhaps something as little as 1.5° w/ 4° sidegust... but when you consider how sensitive that the aerodynamic performance of a rotating wheel actually is to the flow... How contact patch sizing, tyre squirt, tyre and rim deformation, varying amounts of those things from left to right side of the car, roll of the car, etc etc etc.... Its kind of tough to gauge whether any of it would be meaningful, beyond just saying "we thought about it and stuck it in"...

There is another component, in that I have been lazy I guess, in rebuilding the suspension of the car so that it is parametric to the wheels position in space - and then parameterising its position obviously. At the moment, the Perrinn model just a few semi-ovals with triangles at the back, which stick in and out of the wheels and chassis kind of "wherever". So I do want to, at some point, get around to rebuilding these to automatically generate based on where I stick the wheels. Once that's done, I am certain I will be implementing steering angle in the CFD model.

It is very important in that FW-FWheel-BB-FloorIntake area, for the airflow to be carefully managed in terms of downwash, outwash, feeding clean air to the floor, twisting up the wheel wake, managing the path of the Y250 and the vane vortices below the sidepod, amongst others. And doing this under cornering serves a greater purpose and ability for designing a car to be more suited for racing. Straight forward simulations only really are used for under-braking checks, and even then with how good car brakes are, that is such a small time, that it is better to focus on cornering than straight.

Once jjn and I have something that we are somewhat happy with, we will extend it to new areas -- I think Vanja was also going to be joining the "Fellowship of the Ring" ( ) team and was going to have a go at some bargeboards / floor as well.

Thanks for the thought you gave it and us - and we aren't adverse to doing "more"... you need only read the 1st article we wrote on all of this and see how I am desperate to do more - but am severely hamstrung by my PC

We are CFDing it on regular desktops and Vyssion’s “perfectionist” OCD is running rampant with the simplifications he had to…. WiiTYiihd709uah...fne8LQauic..21hjGHBkd…. No!! Stop!! Vyssion!! Its fine!! Okay? Give me the keyboard back!! They get it… Okay?? You did as good a job as you could with the tools we have…. geez… Yes, we know you’re a good little CFD boy… Go mesh something...

[Dipesh1995]

Please do throw me your suggestions for additional imagery

First of all, thank you for your amazing work!
Could you simulate the car with "ferrari style" fw in a corner? As simple as angled wind and angled front wheels, disregarding the roll.
It seems, that this style of fw has some anti-roll function: with front wheels turned in it is "bleeding" some downforce on the outer half (to the corner) of the wing, but increasing downforce on the inner half, since the airflow is restricted by the inner wheel.
Hope my explanation is clear enough)

The curved domain flow is VERY tricky to get right, and it actually is something I have never personally done before... I can "kind of" see how I could "hack" it by creating a sector of a circle large enough to have a car perhaps like 80% of the diameter out from its centre (allowing for all the 2.5x car lengths in front, side and up as well as ~6 behind - so a HUGE sector...) and then setting up a periodic boundary condition between that sector and a blank sector and then knitting those meshes together to form a huge circle mesh, and then setting that entire domain as a rotating frame of reference with soem angular velocity equivalent to 50m/s at the cars location.................................. but there has to be an easier way

Have you considered using a standard cuboid domain instead of a curved domain and just setting boundary conditions of each side wall as appropriate as shown by the image below. You can then use rotating frame of reference to set an angular velocity of the domain like you said.


The advantages of such are that it’s easier to construct (obv) and you can use the same mesh for different cornering radii and just change the location of the centre of rotation i.e corner radius coordinate system. The second advantage goes out the window if you’re planning to change the steer angle for different corner radii but I think keeping the steer angle constant (for now) just to get the cornering simulation working properly probably isn’t a bad shout.

James Keogh has done some work on cornering for his PhD and his lit review and methodology sections goes into some detail about how to go about setting up cornering simulations (link: https://drive.google.com/file/d/1NBUa1I ... drive_open)

Additionally, he’s published a further paper on the aero of a single element wing when cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail) and also published a paper on experimental and numerical methods for cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail).

Let me know if you need further clarification on such as I’m also doing a PhD that includes the numerical simulation of true cornering conditions.

[Vyssion]

Have you considered using a standard cuboid domain instead of a curved domain and just setting boundary conditions of each side wall as appropriate as shown by the image below. You can then use rotating frame of reference to set an angular velocity of the domain like you said.
https://www.simscale.com/forum/uploads/ ... 410328.png

The advantages of such are that it’s easier to construct (obv) and you can use the same mesh for different cornering radii and just change the location of the centre of rotation i.e corner radius coordinate system. The second advantage goes out the window if you’re planning to change the steer angle for different corner radii but I think keeping the steer angle constant (for now) just to get the cornering simulation working properly probably isn’t a bad shout.

James Keogh has done some work on cornering for his PhD and his lit review and methodology sections goes into some detail about how to go about setting up cornering simulations (link: https://drive.google.com/file/d/1NBUa1I ... drive_open)

Additionally, he’s published a further paper on the aero of a single element wing when cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail) and also published a paper on experimental and numerical methods for cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail).

Let me know if you need further clarification on such as I’m also doing a PhD that includes the numerical simulation of true cornering conditions.

Firstly, and most importantly... 195 Mb for a .pdf ????????????????????????????????????????????????????????

Now that's out the way...

I was aware that this sort of thing existed and that it was an option, however, as I said I had never personally done it, and I think subconsciously I had lumped it in with the "really hard so I'll do it later" sort of opinion But that aside - I will have a read through the papers you sent when I get some time, but my only initial thoughts on the cuboid domain as you showed in the image is that of the point where the edge of the inlet and outlet come together... I wonder what sort of "thing" the solver is going to do in that situation...? Reverse flow to me sounds likely, and if so, Fluent or CFX will most likely place an artificial wall over those cells to cope with it... To be honest, I don't even know if the way I think I know how to set up a rotating inlet condition from a point outside of a domain would even work without multiple reference frames (which I have done a lot of work with)

If it is just a sort of "playing the game" of having cartesian velocity components at the inlets corresponding to an approximate speed and angle of flow for the given turn radius, then wouldn't we just be doing an elaborate "triangle with a fillet" type of flow?

I am sort of mind dumping right now as, obviously, I haven't had any time to study it yet, but those are my initial thoughts on it -- I definitely think that perhaps an alternative to a "true" cornering simulation wouldn't be that much of a stretch for me to learn and implement, but yeah: any and all synopsis and / or explanations on the matter you know are welcomed - and the more technical, the better too please!! I prefer to learn something to the extreme point where I could explain it to a child and they would be able to follow the conversation.

[jjn9128]

Have you considered using a standard cuboid domain instead of a curved domain and just setting boundary conditions of each side wall as appropriate as shown by the image below. You can then use rotating frame of reference to set an angular velocity of the domain like you said.

The advantages of such are that it’s easier to construct (obv) and you can use the same mesh for different cornering radii and just change the location of the centre of rotation i.e corner radius coordinate system. The second advantage goes out the window if you’re planning to change the steer angle for different corner radii but I think keeping the steer angle constant (for now) just to get the cornering simulation working properly probably isn’t a bad shout.

James Keogh has done some work on cornering for his PhD and his lit review and methodology sections goes into some detail about how to go about setting up cornering simulations (link: https://drive.google.com/file/d/1NBUa1I ... drive_open)

I'm of the opinion that creating a curved flow-field would not be an insurmountable task - so much so that 2 columns in our CFD output excel file are 'corner radius' and 'steer angle'... not that it's a simple job to create a steer angle with this model, but that's another matter relating to the quality of the CAD which I don't want to bash too much because it's still a great resource to have free use of.

Just sticking the car in a curved flow field isn't wholly accurate anyway and tyres are (as always) a massive issue to solve. An F1 car can exceed 10kN of sideforce at the contact patch in cornering which can shift the sidewall by some 20mm, and the tyre squash from the downforce can drop the axle height by as much as 50mm with these massive sidewalled tyres. Accurately modelling the tyre sidewall deflection when loaded has a significant impact on the car's total downforce performance (in the order of 5-10%) and the direction of the tyres wake. Then you have to consider how much roll to put on the car.

I'm not wanting to just shoot down suggestions, but these are things we've already thought about and deemed to be a step too far for us right now.

[Dipesh1995]

Have you considered using a standard cuboid domain instead of a curved domain and just setting boundary conditions of each side wall as appropriate as shown by the image below. You can then use rotating frame of reference to set an angular velocity of the domain like you said.
https://www.simscale.com/forum/uploads/ ... 410328.png

The advantages of such are that it’s easier to construct (obv) and you can use the same mesh for different cornering radii and just change the location of the centre of rotation i.e corner radius coordinate system. The second advantage goes out the window if you’re planning to change the steer angle for different corner radii but I think keeping the steer angle constant (for now) just to get the cornering simulation working properly probably isn’t a bad shout.

James Keogh has done some work on cornering for his PhD and his lit review and methodology sections goes into some detail about how to go about setting up cornering simulations (link: https://drive.google.com/file/d/1NBUa1I ... drive_open)

Additionally, he’s published a further paper on the aero of a single element wing when cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail) and also published a paper on experimental and numerical methods for cornering (link:https://www.researchgate.net/profile/Sa ... ion_detail).

Let me know if you need further clarification on such as I’m also doing a PhD that includes the numerical simulation of true cornering conditions.

Firstly, and most importantly... 195 Mb for a .pdf ????????????????????????????????????????????????????????

Now that's out the way...

I was aware that this sort of thing existed and that it was an option, however, as I said I had never personally done it, and I think subconsciously I had lumped it in with the "really hard so I'll do it later" sort of opinion But that aside - I will have a read through the papers you sent when I get some time, but my only initial thoughts on the cuboid domain as you showed in the image is that of the point where the edge of the inlet and outlet come together... I wonder what sort of "thing" the solver is going to do in that situation...? Reverse flow to me sounds likely, and if so, Fluent or CFX will most likely place an artificial wall over those cells to cope with it... To be honest, I don't even know if the way I think I know how to set up a rotating inlet condition from a point outside of a domain would even work without multiple reference frames (which I have done a lot of work with)

If it is just a sort of "playing the game" of having cartesian velocity components at the inlets corresponding to an approximate speed and angle of flow for the given turn radius, then wouldn't we just be doing an elaborate "triangle with a fillet" type of flow?

I am sort of mind dumping right now as, obviously, I haven't had any time to study it yet, but those are my initial thoughts on it -- I definitely think that perhaps an alternative to a "true" cornering simulation wouldn't be that much of a stretch for me to learn and implement, but yeah: any and all synopsis and / or explanations on the matter you know are welcomed - and the more technical, the better too please!! I prefer to learn something to the extreme point where I could explain it to a child and they would be able to follow the conversation.

I thought that it would be perhaps more intuitive to post a 10 min video of me creating and running an empty cuboid domain with curved flow (link: http://sendvid.com/gjyqr9xa?secret=b5d3 ... 00b81b87e0) and post notes to go along with the video which I think would make it easier to follow and understand. I don't know whether this method would work on Fluent or CFX as I've only ever used STAR CCM+.

So referring to time-scale 0-3 mins, I’m creating a domain with the target dimensions of 15m x 5m x 5m. In order to be able to split the side boundaries into inlets and outlets, I created the domain via two halves and then joined them together. Around at 2:25, I unite the two halves together which removes the boundary “Block Surface” which initially separated the two halves. This resulted in a single cuboid domain with the sides split into inlets and outlets as appropriate i.e referring to the image I posted in my earlier post. A further point to note is that I’ve created the domain such that the reference “laboratory” coordinate system is located at the centroid of the domain; you don’t have to do this but it makes it easier to position to the “Global” coordinate system (which is does later on) which is used as the point for the centre of rotation. Once I united the two halves together, I set the boundary conditions i.e inlet, outlet, wall as appropriate.

Beyond 3 mins, I create a coarse mesh with properties that allowed the domain to be meshed quickly. At 4:30 mins, I set the velocity inlet value to 0m/s. This is crucial for this to work properly in the way I’ve done it. Essentially, you are modelling the domain moving through stationary air rather than air moving through a stationary domain therefore the angular velocity of the domain that you set later will sort the velocity out through the domain i.e you do not need to the play with the Cartesian velocity components.

At 5 mins, I create the Global coordinate system where I aim initially rotate the domain around a constant radius of 30m i.e 30m radius corner and subsequently set the angular velocity to 1.5 rad/s such that the tangential velocity at the centroid of the domain will be 45 m/s. That reminds me, when you put the car into the domain, the car’s centre of mass location ideally should align with the x-dimension point at which the boundary condition of the inside plane of the domain switches from an inlet to an outlet i.e I’m referring to the side that is most clearly visible in the video (red face to orange face). So in this case, it would be 7.5m from Inlet 1 of the domain.

At 6 mins, I set the motion specification in the region to rotating and set the roof and ground planes to slip walls. If you want to use a moving ground plane, you would have to set the ground plane with an angular velocity about the Global coordinate system.

Finally, I run the simulation and the flow is curved with the correct velocity distribution. I then change the corner radius via modifying the position of the Global coordinate to demonstrate that the same domain and mesh can be used for different corner radii. Like I said before, if you’re planning to use a different steer angle for different corner radii, the same mesh cannot be used.

Edit: I've just read jjn's post and I appreciate that the tyre deformation, roll etc need to be considered for a truly accurate simulation but like you said, this is just a suggestion that in my view would be produce a "there or thereabouts" accurate result. Obviously, it is entirely up to you and Vyssion on whether to try true cornering simulations or not and if you feel its a step too far then that is something that I respect.

[Vyssion]

I thought that it would be perhaps more intuitive to post a 10 min video of me creating and running an empty cuboid domain with curved flow (link: http://sendvid.com/gjyqr9xa?secret=b5d3 ... 00b81b87e0) and post notes to go along with the video which I think would make it easier to follow and understand. I don't know whether this method would work on Fluent or CFX as I've only ever used STAR CCM+.

. . .

Finally, I run the simulation and the flow is curved with the correct velocity distribution. I then change the corner radius via modifying the position of the Global coordinate to demonstrate that the same domain and mesh can be used for different corner radii. Like I said before, if you’re planning to use a different steer angle for different corner radii, the same mesh cannot be used.

Firstly, thankyou for the "personal tutorial" you did for me. Having watched your video, I now can see how and what you meant by what you said. I used StarCCM through my MSc and so I am familiar with it (and could therefore follow even though context menus weren't appearing on the video). I know exactly how to emulate that within the CFX and Fluent environment, and I am actually quite keen to try it out and see how it goes. It basically was the exact same as I was thinking it would need to be done, however, I didn't remember that the coordinate system prescribing the motion of a flow could be placed outside of your domain (for some reason...), hence why I was of the impression it would need to be a sector in shape. But yeah, what you showed makes sense, clearly "works" in creating curved flow within a rectangular domain, and so I want to try it.

I probably wont have time to do so till the weekend, however, what I will do is this:

• Modify my rectangular domain to be larger in the ground plane axis

• Increase the distance upstream from the car centroid to the inlet, to be the same as that of the downstream distance from the centroid to the outlet

• Dig up my notes on typical F1 corner radii and set a tangential speed about the cars centroid (based on contact patches)

• Split up the domain faces in order to be able to set the inlet / outlet combinations correctly - I "may" need to figure out how to define the inlet condition itself given its inlet mass flow rate is defined based on the rotational domain itself... thats the only thing off the top of my head that may need some thinking cross-platform, but I'm sure I can figure it out

• Define a coordinate system outside of the domain about which to rotate the flow

• Rebuild the suspension geometry of the F1 car CAD and slightly turn the wheels to give it a modest amount of steering angle for the chosen corner radius

• In order to split the surfaces of the boundaries as they are currently defined, ANSYS mesher will force a re-mesh to do so, hence why changing the steering angle at the same time is not too much extra work (CAD only)

• Push it through my CFD method and see how things go

Once that finishes... I suppose it wouldnt be too difficult to perhaps impliment a small amount of roll to the car too via rotating it about its longitudinal axis by some fraction of a degree, and then remeshing and solving that too.

In any case, going forward, I want the setup chosen, 50m/s, 4° tangential cornering angle, curved flow domain, etc etc, to remain constant across all simulations going forward, and so since this is now something I feel I can achieve, it makes sense to go ahead and make those changes now before we continue our own 2019 design.

[hollus]

Gandalf said no, but Saruman said yes (maybe).
Phew!
I didn't know who to ask next

Since I am already off-topic and to put your calculation detail into perspective: How do you think your detail and computing capabilities for this project compares to what Manor (Virgin) had available in 2010?
9 years is a lot of time for computers. Can it be comparable to 2005 F1 team capabilities? Year 2000 CFD capabilities?

[Dipesh1995]

I thought that it would be perhaps more intuitive to post a 10 min video of me creating and running an empty cuboid domain with curved flow (link: http://sendvid.com/gjyqr9xa?secret=b5d3 ... 00b81b87e0) and post notes to go along with the video which I think would make it easier to follow and understand. I don't know whether this method would work on Fluent or CFX as I've only ever used STAR CCM+.

. . .

Finally, I run the simulation and the flow is curved with the correct velocity distribution. I then change the corner radius via modifying the position of the Global coordinate to demonstrate that the same domain and mesh can be used for different corner radii. Like I said before, if you’re planning to use a different steer angle for different corner radii, the same mesh cannot be used.

(and could therefore follow even though context menus weren't appearing on the video).

Yeah, my screen recorder didn't manage to capture any sub-menus via my right clicks rather annoyingly. Apologies.

Otherwise, sounds good, I think it will yield some really interesting results.

[Vyssion]

Otherwise, sounds good, I think it will yield some really interesting results.

Alrighty, I've built the CFD method up now, so I will document the exact values etc. that I used for each of the frame references and boundary conditions (100m corner radius @ 50m/s), and then give it a shot at implementing it over the weekend with some CAD updates... again, depending on my free time

Took me a couple hours to figure out the correct reference frames and BCs to use in the ANSYS environment, but hey - I made a rainbow

Thanks heaps for the tip mate, really cool to add this to my tool belt of things I can do