[h0ldem]

Just out of interest, have you ever worked in the field of CFD ioan?

Not really, I'm working in thermo-mechanical (thermo-elasto-plasticity) simulation using FEM. However I believe that the phylosophy and the maths behind them are very similar.

[Zdfjpbth]

And what use does consistent nonsense have?
And not knowing how the code they use works means they will get in Honda like situations.
It might be cheap but it certainly isn't top drawer approach, IMO.
It might take time to extensively test and validate the code, but once it's done it's done and it's working as you wish.

I agree that I look to it from the POV of ultimate accuracy and performance, and maybe F1 teams aren't that much interested about this.

I use the word nonsense as it is very easy to believe what CFD tells you if you naively take the results at face value. A lot of engineers can be misled by results as they may not have fully considered the consequences of their modelling technique, as in the CDG. I make the distinction between the model used and its numerical implementation - you can have many combinations of numerical schemes that satisfy the governing equations for a given modelling technique. Obviously numerical schemes can make a difference but you can bet that industrial best practice outlines a certain set to be used, and these will always be a constant in the simulations.

CFD is comparatively cheap. It certainly saves the manufacture of a lot of components that may be of no use when the analysis is done in the wind tunnel. But it comes at a price of reliability; developing an in-house code from scratch that requires a) taking a CAD geometry, b) meshing it to give a high quality computational grid, c) solving the governing equations on that grid to a good degree of accuracy and d) post-processing the results is not the work of a moment. As I said above it takes years (and I'm not kidding either) to do this. No F1 team has that kind of time to burn so buying in commercial codes is clearly the best plan. In addition to the availability of commercial codes (such as Fluent, Star-CD, CFX etc.) the numerical models in those packages are more than adequate for the speed and efficiency of simulations required for industrial CFD. The general rule of thumb is that flow solutions on complex geometries should take no longer than 24 hours to be produced from point a) to point d). That's a pretty big challenge even with today's computer power hence they buy those ridiculously big computers to do the runs.

The point about accuracy is that you can do a fully time-dependent simulation of a F1 car now if you want - you'll only need the biggest supercomputer in the world and about 50 years to run the simulation. Evidently that's impractical so shortcuts must be made through modelling assumptions. The levels of accuracy of these models in CFD are as follows:

1. Euler solutions: Viscosity is assumed to be zero hence boundary layers do not form near solid surfaces. Very crude but useful for high speed flows like that around aircraft. Produces a steady-state (i.e. average) solution. Runs on a coarse grid and very cheap to compute.

2. Reynolds-Averaged Navier-Stokes (RANS): Effects of viscosity included, hence an improvement over Euler methods. Again produces an average flow solution - many physical processes are smeared out. Needs a finer grid than Euler and is more expensive.

3. Large Eddy Simulation (LES): Time-dependent method where the Navier-Stokes equations are solved exactly above some filter width (usually defined by the computational grid). Below this filter width the scales of motion are modelled using an algebraic function. Needs a much better-resolved grid than RANS and is significantly more expensive. However the results obtained from LES have a much better basis in physical reality than the above two methods.

4. Direct Numerical Simulation (DNS): Navier-Stokes equations are solved for all scales of motion. Grid spacing must resolve the smallest turbulent scales in the flow, typically around a micrometer in size. Stupendously expensive. Very accurate.

Academics perform simulations using 4. on simple things like flows in a pipe, turbulence behind a wire grid, simple boundary layers over a flat plate and so on. It's used to study fundamental turbulence and is of absolutely no interest to industry for the next 20-30 years (at least). Technique 3. is just starting to creep into industry as it costs a hell of a lot less than 4. and offers a reasonable prediction of the real flow physics, although industrial engineers mistakenly think there is little benefit in 3. over technique 2. RANS is now almost standard in industry, with 1. being used mainly in aerospace design for "quick-and-dirty" calculations. The point I'm trying to make here is that accuracy and computational turn-around time are very much interwoven. F1 can't afford to do the highly accurate, time-dependent simulations that 3. and 4. could give them, hence they turn to more crude modelling (mainly 2.), but implicit in those modelling assumptions are things than can be misleading if their effects on the flow are not fully appreciated. This is why no CFD code in existence can be trusted implicitly and the results from CFD must be complemented by wind tunnel test results.

Back to the point of the topic and why I raised CFD in the first place; restricting wind tunnel testing will make teams use CFD more, but for the moment there is no substitute for tunnel testing and if it is limited then it will affect their rate of development.

I doubt it, honestly. There are new theories and models being developed each and every day, that will only be implemented in an industrial code in the next years. What if you could have it a few months before the competition has it too?

New models are developed in academic circles, validated for generic cases and then possibly attract the interest of commercial CFD developers if enough of their customer-base wants it included in the package. Industry is notoriously set in its ways when it comes to CFD models so anything new needs to be pretty hot to make them budge.

[ImapFidaarram]

Thanks Andrew. I think that puts the lid on it

[h0ldem]

I use the word nonsense as it is very easy to believe what CFD tells you if you naively take the results at face value. A lot of engineers can be misled by results as they may not have fully considered the consequences of their modelling technique, as in the CDG. I make the distinction between the model used and its numerical implementation - you can have many combinations of numerical schemes that satisfy the governing equations for a given modelling technique. Obviously numerical schemes can make a difference but you can bet that industrial best practice outlines a certain set to be used, and these will always be a constant in the simulations.

CFD is comparatively cheap. It certainly saves the manufacture of a lot of components that may be of no use when the analysis is done in the wind tunnel. But it comes at a price of reliability; developing an in-house code from scratch that requires a) taking a CAD geometry, b) meshing it to give a high quality computational grid, c) solving the governing equations on that grid to a good degree of accuracy and d) post-processing the results is not the work of a moment. As I said above it takes years (and I'm not kidding either) to do this. No F1 team has that kind of time to burn so buying in commercial codes is clearly the best plan. In addition to the availability of commercial codes (such as Fluent, Star-CD, CFX etc.) the numerical models in those packages are more than adequate for the speed and efficiency of simulations required for industrial CFD. The general rule of thumb is that flow solutions on complex geometries should take no longer than 24 hours to be produced from point a) to point d). That's a pretty big challenge even with today's computer power hence they buy those ridiculously big computers to do the runs.

The point about accuracy is that you can do a fully time-dependent simulation of a F1 car now if you want - you'll only need the biggest supercomputer in the world and about 50 years to run the simulation. Evidently that's impractical so shortcuts must be made through modelling assumptions. The levels of accuracy of these models in CFD are as follows:

1. Euler solutions: Viscosity is assumed to be zero hence boundary layers do not form near solid surfaces. Very crude but useful for high speed flows like that around aircraft. Produces a steady-state (i.e. average) solution. Runs on a coarse grid and very cheap to compute.

2. Reynolds-Averaged Navier-Stokes (RANS): Effects of viscosity included, hence an improvement over Euler methods. Again produces an average flow solution - many physical processes are smeared out. Needs a finer grid than Euler and is more expensive.

3. Large Eddy Simulation (LES): Time-dependent method where the Navier-Stokes equations are solved exactly above some filter width (usually defined by the computational grid). Below this filter width the scales of motion are modelled using an algebraic function. Needs a much better-resolved grid than RANS and is significantly more expensive. However the results obtained from LES have a much better basis in physical reality than the above two methods.

4. Direct Numerical Simulation (DNS): Navier-Stokes equations are solved for all scales of motion. Grid spacing must resolve the smallest turbulent scales in the flow, typically around a micrometer in size. Stupendously expensive. Very accurate.

Academics perform simulations using 4. on simple things like flows in a pipe, turbulence behind a wire grid, simple boundary layers over a flat plate and so on. It's used to study fundamental turbulence and is of absolutely no interest to industry for the next 20-30 years (at least). Technique 3. is just starting to creep into industry as it costs a hell of a lot less than 4. and offers a reasonable prediction of the real flow physics, although industrial engineers mistakenly think there is little benefit in 3. over technique 2. RANS is now almost standard in industry, with 1. being used mainly in aerospace design for "quick-and-dirty" calculations. The point I'm trying to make here is that accuracy and computational turn-around time are very much interwoven. F1 can't afford to do the highly accurate, time-dependent simulations that 3. and 4. could give them, hence they turn to more crude modelling (mainly 2.), but implicit in those modelling assumptions are things than can be misleading if their effects on the flow are not fully appreciated. This is why no CFD code in existence can be trusted implicitly and the results from CFD must be complemented by wind tunnel test results.

Back to the point of the topic and why I raised CFD in the first place; restricting wind tunnel testing will make teams use CFD more, but for the moment there is no substitute for tunnel testing and if it is limited then it will affect their rate of development.

New models are developed in academic circles, validated for generic cases and then possibly attract the interest of commercial CFD developers if enough of their customer-base wants it included in the package. Industry is notoriously set in its ways when it comes to CFD models so anything new needs to be pretty hot to make them budge.

Thanks a lot for the detailed info. I'm more at home with methods applied in the solid materials mechanics, but your explanation confirms a few of my suppositions.

I guess I was looking to it purely from an academic POV and this might not be financially effective for an F1 team.

Even now I would use 1 and 2 to get a general idea about all the aero solutions, scrap the solutions that are useless or with minimal benefit and than go with 3 and 4 to refine the useful ones, but I realize that this approach isn't best suited to an F1 team.

Thanks again.

[Zdfjpbth]

Any time.

[Zdfjpbth]

http://www.theengineer.co.uk/Article...ticleID=309263 - interesting stuff indeed. Renault and Boeing developing a code.....

[h0ldem]

http://www.theengineer.co.uk/Article...ticleID=309263 - interesting stuff indeed. Renault and Boeing developing a code.....

Thanks for the link, very interesting read.

PS: It seems I'm not alone anymore, when thinking about an "in house" developed code.

[ImapFidaarram]

Thanks for the link, very interesting read.

PS: It seems I'm not alone anymore, when thinking about an "in house" developed code.

No, you're still alone in a universe of "1" ioan

Renault are not developing a CFD application from scratch but are working with Boeing to refine their models which is what Andrew and I were suggesting.

No F1 team would develop an application from scratch but partnering with one of the largest Aeronautical corporations out there is entirely logical.

Hoffman said: 'The joint Boeing/RF1 team has improved the efficiency of Boeing's CFD software in large part due to the massive size of the RF1 full car model. The size of these car models required refinement of the Boeing CFD software that has resulted in faster run times on Boeing projects. Faster run times allow more iterations and improved designs.

'There are many similarities in the technologies required to develop world-class racing cars and aerospace products. Boeing and RF1 are keen to learn from our respective industry experience so that we can incorporate this knowledge into our overall company efforts to become more lean and efficient.'

[h0ldem]

No, you're still alone in a universe of "1" ioan

Renault are not developing a CFD application from scratch but are working with Boeing to refine their models which is what Andrew and I were suggesting.

No F1 team would develop an application from scratch but partnering with one of the largest Aeronautical corporations out there is entirely logical.

Just in case you missed it:

The size of these car models required refinement of the Boeing CFD software that has resulted in faster run times on Boeing projects. Faster run times allow more iterations and improved designs. They are refining the CFD SOFTWARE not the models.

[ImapFidaarram]

Just in case you missed it:



They are refining the CFD SOFTWARE not the models.

The software is being refined. Who disagrees

Personally, I would assume that the Boeing developers are refining the code as it would make no sense whatsoever for them to allow Renault to mess about with it.

Boeing have their own processes and expertise that will need to be followed for development. In fact, I think one of my colleagues in Irvine sold them their CM software a decade ago that they could possibly still be using

You don't understand SW development projects ioan. Boeing will have invested $millions on their source code and might very well work with Renault. Renault will have a high quality tool that they can manipulate to their specific requirements very cost effectively.

Please don't think that they are building this from scratch though as they are just developing a branch tuned to Renaults requirements.

[Zdfjpbth]

Yeah it will be the software that is being refined of course. Parallel implementation and efficiency are the most likely areas of development, as splitting up a ~500 million cell grid effectively and having all the CPUs talking to each other with as little overhead as possible is very difficult indeed. The key points are:

"Mistral is expected to increase the CFD capability of the group at one-quarter of the cost of a wind tunnel. The Renault F1 team have reduced full car simulation turnaround time by a factor of three, and increased CFD computational output by a factor of 20."

"Hoffman said: 'The joint Boeing/RF1 team has improved the efficiency of Boeing's CFD software in large part due to the massive size of the RF1 full car model. The size of these car models required refinement of the Boeing CFD software that has resulted in faster run times on Boeing projects. Faster run times allow more iterations and improved designs."

They certainly won't be writing a code from scratch, it'll be optimisation of existing architecture. As for who out of the two are doing the developing, I wouldn't like to guess. There are several areas of licensing and Intellectual Property that are a minefield in collaborative efforts like this - I'm sure they have it all worked out though!

[h0ldem]

The software is being refined. Who disagrees

Personally, I would assume that the Boeing developers are refining the code as it would make no sense whatsoever for them to allow Renault to mess about with it.

Boeing have their own processes and expertise that will need to be followed for development. In fact, I think one of my colleagues in Irvine sold them their CM software a decade ago that they could possibly still be using

You don't understand SW development projects ioan. Boeing will have invested $millions on their source code and might very well work with Renault. Renault will have a high quality tool that they can manipulate to their specific requirements very cost effectively.

Please don't think that they are building this from scratch though as they are just developing a branch tuned to Renaults requirements.

Renault have people who are as good or better than the Boeing ones, don't fool yourself.

As for SW development knowledge, FYI I am developing FEM codes for thermo-mechanical processes, so let's say I know way more than you might be able to guess about this area.

Next time, don't tell others what they know and what they don't before you don't know squat about them, that's a friendly advice.

[h0ldem]

The software is being refined. Who disagrees

Let's see what you said in your previous post:

Renault are not developing a CFD application from scratch but are working with Boeing to refine their models which is what Andrew and I were suggesting.

Which IMO is not right. The SW is being improved in order to be able to deal with the highly refined modeling that Renault requires, which in turn allows for much higher speeds on the simpler Boeing models.

IMO the code is being changed/improved, not the models.

But hey, each to his own domain, in my case numerical methods development and implementation, in your case "?".

Personally, I would assume that the Boeing developers are refining the code as it would make no sense whatsoever for them to allow Renault to mess about with it.

You must be kidding. You are talking like the guys at Renault are complete idiots or something. The fact that the Boeing code isn't good enough to deal in a competitive manner with Renault's requirements indicates that what the Renault engineers are doing is way more complicated than what the Boeing guys are used to do.

I'm pretty sure that the guys at Renault are the ones further developing the Boeing code and Boeing are ripping the rewards, as it would make no sense whatsoever for Boeing to develop their own code for Renault while they are not willing to get into F1 anytime soon.

[ImapFidaarram]

They certainly won't be writing a code from scratch, it'll be optimisation of existing architecture. As for who out of the two are doing the developing, I wouldn't like to guess. There are several areas of licensing and Intellectual Property that are a minefield in collaborative efforts like this - I'm sure they have it all worked out though!

I've worked on a few of these in the past, the largest being the material control on a $4billion capital project.

The model on that occasion was for the key contractor to protect their application and have a 2nd slave system controlling the transfer of information from sub contractors, suppliers, fabricators and main contractors. In this instance, no IP was shared apart from basic interface linking.

I doubt that this is the case in this instance.

What I would assume is that a few Boeing developers working in conjunction
with Renault engineers will create a branch development. What basically happens is that 99% of the standard code is used. However, when code needs altering, it's checked out, altered and checked back in. What this means is that you have two parallel editions of the code with exactly the same backbone but different version numbers. These can be developed as 2 different products but at any time, the branched versions can be deleted or incorporated into the master code to maintain a single enhanced version.

The advantages are that any changes do not effect existing customers codes when upgrading live versions, any enhancements can benefit the core product when fully tested and Renault can have a very cost effective tailored version adapted to their needs and no IP leaves Boeing's systems.

[ImapFidaarram]

Renault have people who are as good or better than the Boeing ones, don't fool yourself.

As for SW development knowledge, FYI I am developing FEM codes for thermo-mechanical processes, so let's say I know way more than you might be able to guess about this area.

Next time, don't tell others what they know and what they don't before you don't know squat about them, that's a friendly advice.

I'm sorry ioan, you have demonstrated you have no clue whatsoever about SW development projects.

You may be able to mess about chucking a few bits of code together but are completely out of your depth.

It's not a problem. I haven't a clue what FEM entails and wouldn't dream of contradicting you. Perhaps that's because I know my limitations.

[h0ldem]

I've worked on a few of these in the past, the largest being the material control on a $4billion capital project.

The model on that occasion was for the key contractor to protect their application and have a 2nd slave system controlling the transfer of information from sub contractors, suppliers, fabricators and main contractors. In this instance, no IP was shared apart from basic interface linking.

I doubt that this is the case in this instance.

What I would assume is that a few Boeing developers working in conjunction
with Renault engineers will create a branch development. What basically happens is that 99% of the standard code is used. However, when code needs altering, it's checked out, altered and checked back in. What this means is that you have two parallel editions of the code with exactly the same backbone but different version numbers. These can be developed as 2 different products but at any time, the branched versions can be deleted or incorporated into the master code to maintain a single enhanced version.

The advantages are that any changes do not effect existing customers codes when upgrading live versions, any enhancements can benefit the core product when fully tested and Renault can have a very cost effective tailored version adapted to their needs and no IP leaves Boeing's systems.

I understand your view of it, but I don't see it like that.

According to the quotes from the above article, the code is being improved to make it efficient for Renault's use and this will be also used by Boeing as it gives them a much better performance than the previous version.
As I see it, the new version can do everything the older could and more and also faster.

As for intellectual property implications, I bet they found a way to agree about the use of the said code.

[h0ldem]

I'm sorry ioan, you have demonstrated you have no clue whatsoever about SW development projects.

You may be able to mess about chucking a few bits of code together but are completely out of your depth.

It's not a problem. I haven't a clue what FEM entails and wouldn't dream of contradicting you. Perhaps that's because I know my limitations.

Be it as you wish, I'm not going lose my time arguing with someone who doesn't understand the basics of the software we are discussing here.

You might be good at packaging software (or bits of code as you call them) together and talking about intellectual property, but when it comes to CFD or FEM implementations I won't hold my breath with you.

FYI I'm writing writing the codes, not chucking them together.

Cheers

[Justlovemy]

Can you guys talk about the issue , rather than engage in this peeing contest , please ?

Seems to me they are using the same base codes , to mutual benefit .

Seems like , since Boeing sounds like they have been using the code for a while , likely longer in the tunnel , have shared thier software , and now are reaping the benefit of that association .
F1's high speed development has the simulations running faster , and both parties are happy .

Faster simulations mean tweaking the tunnel software to relay reliable info faster as well , and with tunnel restrictions , I should think it's where a lot of work is being done , at all the teams .

[h0ldem]

Can you guys talk about the issue , rather than engage in this peeing contest , please ?

Seems to me they are using the same base codes , to mutual benefit .

Seems like , since Boeing sounds like they have been using the code for a while , likely longer in the tunnel , have shared thier software , and now are reaping the benefit of that association .
F1's high speed development has the simulations running faster , and both parties are happy .

Faster simulations mean tweaking the tunnel software to relay reliable info faster as well , and with tunnel restrictions , I should think it's where a lot of work is being done , at all the teams .

Yep along those lines, only that it's not the tunnel software but the so called "simulation" software, used to analyze the new parts straight after design and before they are built and tried out in the tunnel.

It seems that the models used for the F1 simulation are much more fine and complex and thus they had to improve code in order to get shorter computation times, which benefits Boeing who at their turn will be able to have much shorter computation times with their less complex models.

Not knowing exactly what approach the other F1 teams take I don't know if Renault will have an advantage or not, but it certainly seems they are doing everything to get in that position.

PS: Sorry for the off topic posts, but someone seems to only feel good when he can prove how good he is and how others know nothing when in fact he has no in depth knowledge whatsoever about the discussed topic.

[Zdfjpbth]

Yeah but like I said above, Boeing might only be using modelling technique 1 and maybe 2 at the most. Renaults will definitely be using RANS so speeding up the parallel implementation of Boeing's code is of mutual benefit.....