Wind tunnel use in 2008

[ArrowsFA1]

Just came across this news item (http://www.autosport.com/news/report.php/id/64312)from a year ago:


The FIA has introduced a series of radical cost-cutting measures for Formula One next year - which includes a limit of teams' use of wind tunnels for the first time.
At a meeting of the World Motor Sport Council in Monaco on Friday, the FIA announced the dramatic new regulations that it hopes will bring down costs in the sport.
The measures will limit teams to the use of no more than one wind tunnel, and state that devices can only be used for 15 runs per eight-hour day - and only five days per week.
The article details quite a few restrictions to be put in place for the 2008 season, but I don't remember much, if any, mention of this during the course of the year.

Probably just my memory, but were these restrictions put in place :confused:

[Mark]

It's hardly a big restriction. Only one wind tunnel and you can only use it 5 days a week?!

[Robinho]

it doesn't sound like much, but i believe some teams have had access to 2 tunnels running 24hrs a day, 7 days a week

Thats 168hrs a week per tunnel, 336 potential hrs per week,

now they'll be down to 15 runs in an 8hr day, so either 40hrs a week, unless they can still run 24hrs a day, in which case 120hrs a week,

either way thats a big potential reduction, given that they are starting from a blank sheet on the aero this year it could slow the speed of development quite a lot.

if this is in place the teams who have had the time to spend on 2009 aero during 2008 may be in the box seats if they've got it right, as others may take longer to catch up?

[ArrowsFA1]

either way thats a big potential reduction, given that they are starting from a blank sheet on the aero this year it could slow the speed of development quite a lot.
But the article was written in December 2007 and reporting that these restrictions were to be put in place for the 2008 season.

If you're right that teams have had access to 2 tunnels running 24hrs a day, 7 days a week this year then I assume that the radical cost-cutting measures proposed were never introduced :dozey:

[Andrewmcm]

That's where CFD comes in. You can do a lot of pre-testing (so to speak) on computers and then stick the models that you think will work in the tunnel. I'm sure I read that the FIA want to restrict the amount of CFD that can be done, but it will be extremely difficult to police that.

[Mark]

That's where CFD comes in. You can do a lot of pre-testing (so to speak) on computers and then stick the models that you think will work in the tunnel. I'm sure I read that the FIA want to restrict the amount of CFD that can be done, but it will be extremely difficult to police that.

The argument had traditionally been that CFD costs even more than wind tunnel testing so restricting wind tunnel use will actually push costs up.

I'm not sure that's an up to date argument with modern hardware.

[ioan]

The argument had traditionally been that CFD costs even more than wind tunnel testing so restricting wind tunnel use will actually push costs up.

I'm not sure that's an up to date argument with modern hardware.

It's not only a question of hardware development, it's also about the development of the codes used. You may considerably reduce computation times with the use of newer and better optimized codes.
But I agree, computation power is getting cheaper by the day.

[Knock-on]

The argument had traditionally been that CFD costs even more than wind tunnel testing so restricting wind tunnel use will actually push costs up.

I'm not sure that's an up to date argument with modern hardware.

It's a bit of a catch 22.

ioan is sort of along the right line with part of his post. Continued development of SW gives us more advanced code.

However, it ultimately does come down to the capability of the HW. The faster I/O calculations, the more you crunch a second.

HW always comes down in price if you remain at a static level but the high end stuff will always command a premium because of the edge it offers.

[Mark]

It's a bit of a catch 22.

ioan is sort of along the right line with part of his post. Continued development of SW gives us more advanced code.

However, it ultimately does come down to the capability of the HW. The faster I/O calculations, the more you crunch a second.

HW always comes down in price if you remain at a static level but the high end stuff will always command a premium because of the edge it offers.

ioan is certainly correct in that in such a complex system the software, either a licence or custom made is going to be by far the major cost in the equation, that and paying the experts you need to run the system. The actual hardware they are likely to use is commodity boxes, which in the scheme of things are very cheap.

[Knock-on]

ioan is certainly correct in that in such a complex system the software, either a licence or custom made is going to be by far the major cost in the equation, that and paying the experts you need to run the system. The actual hardware they are likely to use is commodity boxes, which in the scheme of things are very cheap.


:confused:

Not necessarily.

What would you need for a basic system.

3 Kva per rack with Fibre backbone and other HW
Initial 36 TB of storage such as Netapps.
Suitable processing capacity

I don't know how much the SW is but you looking at a couple of hundred grand there per year for a basic setup.

Then when something like optic or Kubit processing comes out, they will all jump again.

[ioan]

ioan is certainly correct in that in such a complex system the software, either a licence or custom made is going to be by far the major cost in the equation, that and paying the experts you need to run the system. The actual hardware they are likely to use is commodity boxes, which in the scheme of things are very cheap.

Don't get me wrong, if they buy the SW (this may or not be the case, I have no ideea) than it's certainly not more expensive than the computational power they need (and which they need to change or heavily upgrade every 2 years at least).
If they do develop they own SW (it's not at all out of question even if complicated) than they need to pay lots of money for those who do it, but certainly they will have a SW where they can do whatever they want, knowing every little bit of it and being able to develop it further and further.

What I was trying to say is that with today's technology being available to every one of them, it is rather the SW that will make the difference, and if they got the better mathematicians, engineers and programmers than the advantage they can get over the competition is way bigger than the one they get buying better HW. So IMO CFD software is more important than HW and allows for higher gains in a strictly limited and controlled environment.

You are also right about the HW being cheaper by the day as it is highly standardized and thus even if some of it needs to be adapted or personalized it still isn't as difficult and expensive as as 10 years ago.

In the end the people and the knowledge will be most expensive of all.

I hope I managed to give some sense to what I was trying to say.

It's hardly a big restriction. Only one wind tunnel and you can only use it 5 days a week?!

Feck me....I used to dream of only doing that and that was 10 years ago.

it doesn't sound like much, but i believe some teams have had access to 2 tunnels running 24hrs a day, 7 days a week

Correct, but you forgot too mention that it was for 363 days a year.

We had Christmas day & News Years Day off.

[Knock-on]

Don't get me wrong, if they buy the SW (this may or not be the case, I have no ideea) than it's certainly not more expensive than the computational power they need (and which they need to change or heavily upgrade every 2 years at least).
If they do develop they own SW (it's not at all out of question even if complicated) than they need to pay lots of money for those who do it, but certainly they will have a SW where they can do whatever they want, knowing every little bit of it and being able to develop it further and further.

What I was trying to say is that with today's technology being available to every one of them, it is rather the SW that will make the difference, and if they got the better mathematicians, engineers and programmers than the advantage they can get over the competition is way bigger than the one they get buying better HW. So IMO CFD software is more important than HW and allows for higher gains in a strictly limited and controlled environment.

You are also right about the HW being cheaper by the day as it is highly standardized and thus even if some of it needs to be adapted or personalized it still isn't as difficult and expensive as as 10 years ago.

In the end the people and the knowledge will be most expensive of all.

I hope I managed to give some sense to what I was trying to say.

:up:

Very clear and I agree.

Fluid dynam Sw has advanced greatly as has HW. You can spend millions but without the right people with relevant experience to manage it, your wasting your money. Just ask Honda and their wind tunnel :laugh:

[Andrewmcm]

The actual software used by the F1 teams perhaps isn't as big an issue as you might think. Most of the teams use Commercial Codes that no doubt they've modified to some degree. Hardware is reasonably cheap these days and you can end up with a 1024 CPU cluster for a few hundred thousand quid at most.

The key to obtaining good results from CFD is to understand the limitations of the model used and to interpret the results correctly - the failure of CFD to predict the performance of the CDG is a good example of that. That's where the teams will spend the money - getting people who can analyse the results and come to the right conclusions.

[ioan]

The actual software used by the F1 teams perhaps isn't as big an issue as you might think. Most of the teams use Commercial Codes that no doubt they've modified to some degree. Hardware is reasonably cheap these days and you can end up with a 1024 CPU cluster for a few hundred thousand quid at most.

The key to obtaining good results from CFD is to understand the limitations of the model used and to interpret the results correctly - the failure of CFD to predict the performance of the CDG is a good example of that. That's where the teams will spend the money - getting people who can analyse the results and come to the right conclusions.

IMO the first thing to get the right results and than analyze them correctly is to understand at a 100% rate how exactly the SW is working, to know what kind of mathematical model it is used, to know how to impose the right conditions and how exactly that info is processed.

If as you say they use commercial software than they need to have people who take their time to dismantle the SW and understand it perfectly, otherwise it would be only an ordinary tool available to everyone.

Given the implications I , personally, would have had a custom in-house developed SW if I was one of the team managers. A software that will do things exactly as it's needed to be done, and that I can always improve using the latest research results in the domain.

[Knock-on]

IMO the first thing to get the right results and than analyze them correctly is to understand at a 100% rate how exactly the SW is working, to know what kind of mathematical model it is used, to know how to impose the right conditions and how exactly that info is processed.

If as you say they use commercial software than they need to have people who take their time to dismantle the SW and understand it perfectly, otherwise it would be only an ordinary tool available to everyone.

Given the implications I , personally, would have had a custom in-house developed SW if I was one of the team managers. A software that will do things exactly as it's needed to be done, and that I can always improve using the latest research results in the domain.

Unless I could possibly avoid it, I would NEVER go for a bespoke development.

Why would you want to reinvent the wheel?

It makes no sense to ignore the wealth of developed code out there in favour of starting from scratch. All the modelling has been done previously, coded, tested and deployed. It will then have gone through user acceptance testing, bugs fixed and further versions developed.

I would dread to think how much money has be spent of flow dynamics by the oil companies, aviation companies, car manufacturers and the likes but I doubt that there's many models left that aren't covered.

All you need is the relevant Software, appropriate Hardware and people skilled in both using the application and interpreting / manipulating the results to produce meaningful feedback. It's nothing to do with the code or how the SW actually works.

Certainly, no team manager would decide to undertake a £million+ contract to develop a bespoke package from scratch.

Certainly, no team manager would decide to undertake a £million+ contract to develop a bespoke package from scratch.

They don't.

Just look at the 'Situations Vacant' in Autosport.

Every Aero and R&D job requests that the applicants have knowledge of Catia V5.

[Andrewmcm]

No F1 team in their right mind would develop their own code. It takes a long time (i.e. years) to extensively validate a CFD code, and it's often the case that what appear to be good numerical schemes for certain situations don't work well together. Commercial code developers use test matrices that ensure consistent results are obtained when the software is modified so it removes the doubt from the end-user. Of course the results that the CFD spits out could well be absolute nonsense, but at least it'll be consistent nonsense.

I guarantee that not many people who work for motorsport teams know exactly how their codes work; their primary interest is in testing out geometries, looking at lift/drag plots and then sticking it on the wind tunnel model to ensure that the whole process works. They simply don't have time to worry about code development.

[Knock-on]

No F1 team in their right mind would develop their own code. It takes a long time (i.e. years) to extensively validate a CFD code, and it's often the case that what appear to be good numerical schemes for certain situations don't work well together. Commercial code developers use test matrices that ensure consistent results are obtained when the software is modified so it removes the doubt from the end-user. Of course the results that the CFD spits out could well be absolute nonsense, but at least it'll be consistent nonsense.

I guarantee that not many people who work for motorsport teams know exactly how their codes work; their primary interest is in testing out geometries, looking at lift/drag plots and then sticking it on the wind tunnel model to ensure that the whole process works. They simply don't have time to worry about code development.

:up: Put a lot more suscintly than a muddler like I ever could.

It would be like designing and building a Veyron from scratch for £8M rather than buying one off Bugatti.

(Yes, I know it would cost a lot more than £8M for a single car and that the figure is what each one cost for the excercise)

[ioan]

No F1 team in their right mind would develop their own code. It takes a long time (i.e. years) to extensively validate a CFD code, and it's often the case that what appear to be good numerical schemes for certain situations don't work well together. Commercial code developers use test matrices that ensure consistent results are obtained when the software is modified so it removes the doubt from the end-user. Of course the results that the CFD spits out could well be absolute nonsense, but at least it'll be consistent nonsense.

I guarantee that not many people who work for motorsport teams know exactly how their codes work; their primary interest is in testing out geometries, looking at lift/drag plots and then sticking it on the wind tunnel model to ensure that the whole process works. They simply don't have time to worry about code development.

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.

[ioan]

Why would you want to reinvent the wheel?

It's not that simple a case.



All the modelling has been done previously, coded, tested and deployed.

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?



I would dread to think how much money has be spent of flow dynamics by the oil companies, aviation companies, car manufacturers and the likes but I doubt that there's many models left that aren't covered.

Everything is developed for specific uses, and if it isn't than it usually isn't as good as if it was developed accordingly.



Certainly, no team manager would decide to undertake a £million+ contract to develop a bespoke package from scratch.

They do spend millions to gain an advantage of a tenth of a second over the opposition, why not spend it to get even more advantage. It might be priceless on the long term.

I don't know what they use, I just know what I would do if I had the budgets they have at their disposal.

[Andrewmcm]

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

[ioan]

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.

[Andrewmcm]

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.

[Knock-on]

Thanks Andrew. I think that puts the lid on it :)

[ioan]

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. :)

[Andrewmcm]

Any time. :)

[Andrewmcm]

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

[ioan]

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

Thanks for the link, very interesting read. :up:

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

[Knock-on]

Thanks for the link, very interesting read. :up:

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.'

[ioan]

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. ;)

[Knock-on]

Just in case you missed it:



They are refining the CFD SOFTWARE not the models. ;)

The software is being refined. Who disagrees :confused:

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.

[Andrewmcm]

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!

[ioan]

The software is being refined. Who disagrees :confused:

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.

[ioan]

The software is being refined. Who disagrees :confused:

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.

[Knock-on]

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.

[Knock-on]

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. ;)

[ioan]

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.

[ioan]

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. ;)

:laugh:

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

[Knock-on]

:laugh:

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

So, not a code slinger then? For once, I believe you. in fact, in a binary world, you are not the Neo :laugh:

http://www.williamgibsonbooks.com/

Start with the Neuromancer. It will double your knowledge of the subject :D

[Bagwan]

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 .

[ioan]

So, not a code slinger then? For once, I believe you. in fact, in a binary world, you are not the Neo :laugh:

http://www.williamgibsonbooks.com/

Start with the Neuromancer. It will double your knowledge of the subject :D

:rolleyes: Good to have another proof of your intellectual level ("0-"). :D

[ioan]

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.

[Andrewmcm]

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.....

[Andrewmcm]

Boink.

For those of you who have access to such things, there is an article on race-car aerodynamics that you may find enlightening. Its citation information is:

Aerodynamics of race cars, J. Katz, Annual Review of Fluid Mechanics, Vol. 38: 27-63.

If you can't get a hold if it I'm sure someone round here has a .pdf of it stored somewhere. *cough*