CFD design protocol

[nzjrs]

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.

FWIW my job is working with AI daily, well outside of the F1 sphere, and I've made a decent amount of money playing the cryptocurrency game - I understand that too quite well.

But I work in the problem solving business, which means efficiency and scale.

[Zynerji]

Sweet. I solve problems for a living as well. The largest problem I solve is inefficiency. Blockchain technology is helping me, and it is far more than "coins". It's the economic theory that drives the whole concept that is the true power of the tech.

[nzjrs]

Sweet. I solve problems for a living as well. The largest problem I solve is inefficiency. Blockchain technology is helping me, and it is far more than "coins". It's the economic theory that drives the whole concept that is the true power of the tech.

Well let's agree to disagree then.

[Zynerji]

Sweet. I solve problems for a living as well. The largest problem I solve is inefficiency. Blockchain technology is helping me, and it is far more than "coins". It's the economic theory that drives the whole concept that is the true power of the tech.

Well let's agree to disagree then.

Of course. The history of the stock market is littered with tales of people making and losing money this way. I'm diversified in such a manner that I win either way on this.

[TankMarvin]

I thought the FLOPS limitation was on the CFD solver phase specifically...

All pre and post processing is not limited. Historically it wouldn't need to be as it would be trivial in comparison to the solver. But if the DL/ML phase was "pre/post-processing" (outside of the solver) then teams could do what they like ?

[Zynerji]

I thought the FLOPS limitation was on the CFD solver phase specifically...

All pre and post processing is not limited. Historically it wouldn't need to be as it would be trivial in comparison to the solver. But if the DL/ML phase was "pre/post-processing" (outside of the solver) then teams could do what they like ?

This was rather my point.

[nzjrs]

I thought the FLOPS limitation was on the CFD solver phase specifically...

All pre and post processing is not limited. Historically it wouldn't need to be as it would be trivial in comparison to the solver. But if the DL/ML phase was "pre/post-processing" (outside of the solver) then teams could do what they like ?

This was rather my point.

Oh right, I assumed you were suggesting the slightly more plausible (constraints being irrelevant) thing of letting DL/ML/AI/GA partition the problem space, farm computation out to CFD solvers somewhere, use some consensus/work scheduling/distribution tricks to not waste egregious amounts of resources, get back the results, scale the gradient, iterate, repeat and converge.

Are you really suggesting replacing CFD with DL? i.e replacing the CFD solving step?

If so, you should drop your crypto playtime, because you've just become a billionaire.

[Zynerji]

I thought the FLOPS limitation was on the CFD solver phase specifically...

All pre and post processing is not limited. Historically it wouldn't need to be as it would be trivial in comparison to the solver. But if the DL/ML phase was "pre/post-processing" (outside of the solver) then teams could do what they like ?

This was rather my point.

Oh right, I assumed you were suggesting the slightly more plausible (constraints being irrelevant) thing of letting DL/ML/AI/GA partition the problem space, farm computation out to CFD solvers somewhere, use some consensus/work scheduling/distribution tricks to not waste egregious amounts of resources, get back the results, scale the gradient, iterate, repeat and converge.

Are you really suggesting replacing CFD with DL? i.e replacing the CFD solving step?

If so, you should drop your crypto playtime, because you've just become a billionaire.

I am not a crypto billionaire, and own zero coins. Im currently using a private Ethereum blockchain as a means of a business management software that allows for real time payouts to employees (daily paychecks), inventory control, sales, human resource and customer data management. Its simply trusted accounting and accountability in real time for any profit producing business. This project currently has 12 on site "nodes" (office computers) and an Amazon EC2 instance as an off site node to preserve the chain for the 200 mobile (IOS) thin clients if the office has a power outage.

In the F1 case, I'm suggesting to remove the human from the loop pre-cfd, but it would use CFD solving during the software's design step to train the system.

Once you have the cause/effect database that is generated by the training, it would just no longer need to CFD solve during generative shape design, just as a check at the end of that process to correlate.

[roon]

...in the face of AI replacing all engineers as the calculators of your field...

I don't think it will be quite so clear-cut, but I have found it interesting that automation tends to be discussed as a threat to blue collar jobs, when it may be that white collar jobs are at more of a risk. So the factory worker inherits the company because their job was the most psychosomatically difficult to accomplish, misunderstood, or undervalued by management. Engineers and executives replaced by evermore sophisticated CAE/D, finance, and enterprise software.

[Greg Locock]

In practice the number of engineers need to design and develop a car has skyrocketed in the past 30 years, although I'd happily admit that many of those jobs are rather tedious specialisations. I used to do NVH on every aspect of the car (except windnoise as it happens), now we have silos.

And to get back to the point, would you rather muck around in a windtunnel or write input cards for CFD runs?

[Cold Fussion]

In the F1 case, I'm suggesting to remove the human from the loop pre-cfd, but it would use CFD solving during the software's design step to train the system.

Once you have the cause/effect database that is generated by the training, it would just no longer need to CFD solve during generative shape design, just as a check at the end of that process to correlate.

And how do you propose to generate that output space in the trillions of possible configurations with a measly 30 TFlops of compute power? Maybe I am completely ignorant but as far as I'm aware machine learning is solving y=f(x) to find f when you have a set of y and x's. In CFD you already have f, which is your chosen discretisation of the navier-stokes equations and turbulence model (albeit solved implicitly). What you're suggesting sounds awfully like using CFD to generate an enormous amount of output space for input geometries and then using machine learning to get yourself some 'fuzzy' explicit solution to the navier-stokes equations.

[Greg Locock]

I think GA would probably be a better way of describing the problem than NN, for a machine without insight. The problem is quite different to say structural optimisation, primarily because in structures local details don't affect the distant load paths (St Venants theorem), whereas in aero if you upset the front wing it will affect the rear wing (etc, crudely). A fairly successful route to optimizing a structure to carry the maximum load set for a given mass of a structural material is to run an FEA, beef up the red bits, get rid of the blue bits. Rinse and repeat. This may only lead to a local optimum, but it is damn quick and usually quite helpful. I doubt there is any such simple rule for aero.

The problem with GA is defining the genes. Once you've done that the rest is easy and robust.

However the point of all ML approaches is that they inherently use more FLOPS than a CFD program doing one run at a time with a skilled aero guy running them. And flops is the constraint in F1.

[graham.reeds]

A few years ago I read a thesis where the graduate wrote a GA for hull design on boats. Basically it was given free reign within boundaries of the boundaries of the current hull and several variations of boats were considered. The GA came close too, but never surpassed the hand optimised hull planes for all the hulls they tested.

This is a fairly simplistic arena when compared to F1 - no neural network or genetic algorithm will come close to what a designer will come up.

[Cold Fussion]

The problem I see with genetic algorithms for fluid mechanics is how computationally expensive it is. We can't currently run the most 'accurate' CFD models on anything other simple geometries without a super computer. We'll probably need far beyond exascale computing before we can expect good optimisation on something as complex as an F1 car.

[keroro.90]

The problem I see with genetic algorithms for fluid mechanics is how computationally expensive it is. We can't currently run the most 'accurate' CFD models on anything other simple geometries without a super computer. We'll probably need far beyond exascale computing before we can expect good optimisation on something as complex as an F1 car.

Yes, I think this is the point....rerun every time the solver to optimise won't be a good solution, and perhaps something better can be done using a more accurate turbulence modelling instead of plenty of optimised run with a low accuracy model.