CFD design protocol

[hardingfv32]

The teams keep coming up with more complex aero appendages. What is the protocol for developing a change?

As an example: When using groups of turning vanes, does the designer have to propose to the program that an additional vane be tried or could the program do it automatically through some kind of optimization application?

Brian

[Zynerji]

The teams keep coming up with more complex aero appendages. What is the protocol for developing a change?

As an example: When using groups of turning vanes, does the designer have to propose to the program that an additional vane be tried or could the program do it automatically through some kind of optimization application?

Brian

We have been loosely discussing the role that machine learning has on current development.

I almost imagine a basic car shape being loaded into software, using colored paint on the model to tell it where you want high/ low pressure zones, and let the computer iterate trillions of solutions (within the legality boxes) to try and reach those flow parameters.

Parametric modeling with Tensorflow real time learning adjustments and bi-directional CFD, in my opinion, should be ubiquitous in today's modern F1.

[Just_a_fan]

Presumably the limits on the number of FLOPS the teams are allowed to use limits this type of system. I could see a road car maker using it, however.

[Vanja #66]

We are yet to see a shape on an F1 car that's not designed by a person. There are too many variables to achieve a certain pressure distribution and most of them would be illegal. Machine learning will need to come a long way before this is possible, including the removal of constant iterations required and replacing it with actual AI.

Also, before that, you'd need full FSI sorted out, not to mention 100% CFD correlation with what actually happens. No matter how good your CFD, your turbulent model or your solver is, it can still give results that don't match with reality and if engineers can't predict with 100% success if development path is right - how can they teach a machine?

[nzjrs]

The teams keep coming up with more complex aero appendages. What is the protocol for developing a change?

As an example: When using groups of turning vanes, does the designer have to propose to the program that an additional vane be tried or could the program do it automatically through some kind of optimization application?

Brian

We have been loosely discussing the role that machine learning has on current development.

I almost imagine a basic car shape being loaded into software, using colored paint on the model to tell it where you want high/ low pressure zones, and let the computer iterate trillions of solutions (within the legality boxes) to try and reach those flow parameters.

Parametric modeling with Tensorflow real time learning adjustments and bi-directional CFD, in my opinion, should be ubiquitous in today's modern F1.

I'm confident that at the large scale DL is not efficient nor practical for this task. The cost function is too expensive to compute and you could argue that its not sufficiently differentiable or smooth to allow optimization as current DL needs. Of course half the people these days say deep learning when they probably me machine learning or something old school like genetic algorithms - in which case every new aero graduate to the team in the last 15 years has probably proposed such an approach and been shot down for the reasons I outlined.

To me DL seems, at this time at the macro level, to make about sense as using blockchain to make a car fast.

[Zynerji]

The teams keep coming up with more complex aero appendages. What is the protocol for developing a change?

As an example: When using groups of turning vanes, does the designer have to propose to the program that an additional vane be tried or could the program do it automatically through some kind of optimization application?

Brian

We have been loosely discussing the role that machine learning has on current development.

I almost imagine a basic car shape being loaded into software, using colored paint on the model to tell it where you want high/ low pressure zones, and let the computer iterate trillions of solutions (within the legality boxes) to try and reach those flow parameters.

Parametric modeling with Tensorflow real time learning adjustments and bi-directional CFD, in my opinion, should be ubiquitous in today's modern F1.

I'm confident that at the large scale DL is not efficient nor practical for this task. The cost function is too expensive to compute and you could argue that its not sufficiently differentiable or smooth to allow optimization as current DL needs. Of course half the people these days say deep learning when they probably me machine learning or something old school like genetic algorithms - in which case every new aero graduate to the team in the last 15 years has probably proposed such an approach and been shot down for the reasons I outlined.

To me DL seems, at this time at the macro level, to make about sense as using blockchain to make a car fast.

When stuff like this is 2 year old tech, and every F1 design office has DOZENS of CAD machines that can each run 4-6 of them already, I do not think that we are currently unable to brute-force these types of Massive Multibox Parametric CFD numbers.

https://instinct.radeon.com/en/product/ ... inct-mi25/

PS: And blockchain is going to dominate every single computer operated thing in your life within the next 10 years, so I hope you get over it soon. Especially as a recursive state-machine block-chain is exactly how I would set up this software to take advantage of these DL cards, as it would allow them to talk to the future step-by step with near zero off-card data transfer.

[Greg Locock]

Unless you can demonstrate that a computer based development algorithm uses fewer FLOPS than a human directed one then I suspect you have completely missed the point.

In my own work I do not face such arbitrary constraints, and am quite happy to let inefficient automatic processes run for days at a time if it saves me from 4 hours of boring work. There's plenty of other stuff needs doing by me. The worst case was fitting tire data for real life limit handling. That used 8 threads (and licenses) 24/7 for 3 months. In retrospect I should have spent more time prototyping the optimising routine, but that didn't fit the priorities at the time.

[Zynerji]

Unless you can demonstrate that a computer based development algorithm uses fewer FLOPS than a human directed one then I suspect you have completely missed the point.

In my own work I do not face such arbitrary constraints, and am quite happy to let inefficient automatic processes run for days at a time if it saves me from 4 hours of boring work. There's plenty of other stuff needs doing by me. The worst case was fitting tire data for real life limit handling. That used 8 threads (and licenses) 24/7 for 3 months. In retrospect I should have spent more time prototyping the optimising routine, but that didn't fit the priorities at the time.

I didn't miss any points. If you want to find and explore the development paths of trillions of possibilities within a finite space, there is no human that can compare with the generative shape design of a brute-force algorithm. Simple things like a bounded box broken into a point cloud that runs through 100% of possible points and measures results that feeds back into the system when you request a certain outcome. Block-chain state machines can have a few billion internal "transactions" per second, and add only a single 32bit hash to the Block (stored in RAM, not HDD). If these bounded boxes are then linked to the downstream (or future) bounded boxes as a state machine array, you can direct the placement of points in the previous box to accomplish your desired output in the later box.

Someone would have to probably convert OpenFOAM to ERC721 Solidity token generation contracts or bootstrap the Nethereum C# interpreter, but running a private Ethereum chain with the individual Workstations connected through Plasma on a 10GB LAN would be the way forward, as you could drop to 1/2 precision on the individual state outputs, and use the Casper\Ethereum consensus algorithm of all the connected boxes to smooth the edges. The teams could literally deploy apps for their fans to "fish" the system without giving away any IP, and have constant generative improvement.

[Greg Locock]

You entirely missed the point. F1 teams are restricted in how much computer 'time' they can spend on aero. Stop gibbering,

[Zynerji]

You entirely missed the point. F1 teams are restricted in how much computer 'time' they can spend on aero. Stop gibbering,

Im not missing anything, you are simply lacking scope of vision. That's why it rings as idiotic to waste the limited computer time by keeping imperfect and slow humans in the loop as the primary calculator of every way to manipulate and optimize the outcome of what is "literally" a math problem, and that's not gibberish!

[Greg Locock]

So let me get this right. You personally have demonstrable knowledge of a CFD optimiser that uses fewer cpu cycles to reach an optimum design starting from an open book set of constraints than a CFD program run by an experienced aerodynamicist.

Two letters. SB. anag.

[Zynerji]

So let me get this right. You personally have demonstrable knowledge of a CFD optimiser that uses fewer cpu cycles to reach an optimum design starting from an open book set of constraints than a CFD program run by an experienced aerodynamicist.

Two letters. SB. anag.

No. What I'm saying is that the current method of relying on human beings to figure out the optimum way to shape a car to go through a fluid is the most inefficient method possible with today's technology, as the human simply can not compete with "ideas per second", and their memory of previous data is imperfect.

The fact that every car on the grid is different, mathematically it means that no one has found the perfect solution, because they are simply a group of humans using their educated best guesses, and approximated data.

The human should only need to set the expectation of the result.

[Greg Locock]

Oh, that makes more sense. Yes, if they weren't constrained by the rules they'd be running serious CFD optimisation night and day on many many processors. But they are not allowed to do that, so they don't.

[nzjrs]

Unless you can demonstrate that a computer based development algorithm uses fewer FLOPS than a human directed one then I suspect you have completely missed the point.

In my own work I do not face such arbitrary constraints, and am quite happy to let inefficient automatic processes run for days at a time if it saves me from 4 hours of boring work. There's plenty of other stuff needs doing by me. The worst case was fitting tire data for real life limit handling. That used 8 threads (and licenses) 24/7 for 3 months. In retrospect I should have spent more time prototyping the optimising routine, but that didn't fit the priorities at the time.

I didn't miss any points. If you want to find and explore the development paths of trillions of possibilities within a finite space, there is no human that can compare with the generative shape design of a brute-force algorithm. Simple things like a bounded box broken into a point cloud that runs through 100% of possible points and measures results that feeds back into the system when you request a certain outcome. Block-chain state machines can have a few billion internal "transactions" per second, and add only a single 32bit hash to the Block (stored in RAM, not HDD). If these bounded boxes are then linked to the downstream (or future) bounded boxes as a state machine array, you can direct the placement of points in the previous box to accomplish your desired output in the later box.

Someone would have to probably convert OpenFOAM to ERC721 Solidity token generation contracts or bootstrap the Nethereum C# interpreter, but running a private Ethereum chain with the individual Workstations connected through Plasma on a 10GB LAN would be the way forward, as you could drop to 1/2 precision on the individual state outputs, and use the Casper\Ethereum consensus algorithm of all the connected boxes to smooth the edges. The teams could literally deploy apps for their fans to "fish" the system without giving away any IP, and have constant generative improvement.

Well this is entertaining. Death of dimensionality didn't go away because you made a few quid on bitcoin. We are engineers which means we live in a constraint based world, and one can't afford to waste compute time on something like this *yet* (IMO).

When CFD is free and F1 teams can boil the oceans chasing rainbows with buzzwords then GA will get you somewhere. You admit this yourself having to divert the conversation and this scheme out to user computers to compute.

It's not lack of vision, its a broader view of what 'optimal' means.

[Zynerji]

Unless you can demonstrate that a computer based development algorithm uses fewer FLOPS than a human directed one then I suspect you have completely missed the point.

In my own work I do not face such arbitrary constraints, and am quite happy to let inefficient automatic processes run for days at a time if it saves me from 4 hours of boring work. There's plenty of other stuff needs doing by me. The worst case was fitting tire data for real life limit handling. That used 8 threads (and licenses) 24/7 for 3 months. In retrospect I should have spent more time prototyping the optimising routine, but that didn't fit the priorities at the time.

I didn't miss any points. If you want to find and explore the development paths of trillions of possibilities within a finite space, there is no human that can compare with the generative shape design of a brute-force algorithm. Simple things like a bounded box broken into a point cloud that runs through 100% of possible points and measures results that feeds back into the system when you request a certain outcome. Block-chain state machines can have a few billion internal "transactions" per second, and add only a single 32bit hash to the Block (stored in RAM, not HDD). If these bounded boxes are then linked to the downstream (or future) bounded boxes as a state machine array, you can direct the placement of points in the previous box to accomplish your desired output in the later box.

Someone would have to probably convert OpenFOAM to ERC721 Solidity token generation contracts or bootstrap the Nethereum C# interpreter, but running a private Ethereum chain with the individual Workstations connected through Plasma on a 10GB LAN would be the way forward, as you could drop to 1/2 precision on the individual state outputs, and use the Casper\Ethereum consensus algorithm of all the connected boxes to smooth the edges. The teams could literally deploy apps for their fans to "fish" the system without giving away any IP, and have constant generative improvement.

Well this is entertaining. Death of dimensionality didn't go away because you made a few quid on bitcoin. We are engineers which means we live in a constraint based world, and one can't afford to waste compute time on something like this *yet* (IMO).

When CFD is free and F1 teams can boil the oceans chasing rainbows with buzzwords then GA will get you somewhere. You admit this yourself having to divert the conversation and this scheme out to user computers to compute.

It's not lack of vision, its a broader view of what 'optimal' means.

You sound like everyone else, calling blockchain a fad.

You should read up on the some blockchain engineering. Once you actually understand it, and its power, you may find yourself subconsciously solving day to day problems with it.

And, honestly, you only sound like a protectionist. Trying to preserve your job in the face of AI replacing all engineers as the calculators of your field by simply stating (with zero supporting material) that it simply "cannot be done". Sounds like an engineering Dodo to me.