Should the 2022 cars be moved to 2023?

[PlatinumZealot]

I used ray tracing in early 2000s. 3D graphics. It took a long time to render a scene with ray tracing. And you had to put in real physical properities manually! Now it is done in real-time video games but with trade of in quality of course. And nowada CAD programs does it in a few clicks and presets now.

I think ray tracing strength lie in keeping accurate large numbers of vectors shot at a surface/ through an object. The angles of each ray coming towards the viewer is measured and off of every surface the ray bounces /goes thru and then those angles are inputed into whatever characteristic function u have for the ray. (it can be a light ray, a sound "ray" or some other physical thing) to tell it what the resulting colour is, or refraction, or sound or whatevever.

Hard to see how it will have use in CFD...
So u have to enlighten me on that one.

CFD already uses stream-lines instead of rays... Unless u mean the method of calculation in ray tracing is somehow adopted in CFD or something.

[Andres125sx]

I've given it a chance in the past... Several times.

The more restricted the budget, the more likely one team finds a solution that the others can't copy and we get 20 walk-off races.

That's my 2022 bet currently. I just don't know what team yet..

Maybe, but that team can be any team, contrary to current scenario where only the big teams have a chance to find a solution others can´t copy. To me that´s a huge step forward as it´s a competition where all participants have a chance to win, as any competition should be.

[DChemTech]

Bi-directional ray tracing with a turbulence model allows you to determine the start and end points of the Ray. Using BiRT, you can "paint" the high and low pressure spots on the car, and how you WANT the flow-fields to look, and let the algorithm define the necessary shape to manufacture it.

Does a bidirectional ray tracing with turbulence model exist? Ray tracing traces light rays, does it not? Clue's in the name. How does that help with airflow modelling? And why is it better than CFD? The thing that is actually designed from the start to model air flow.

We're ot. I'll pm you

It is OT, but I do find it quite interesting. I wouldn't mind if you'd share it here.

As for quantum-in-CFD, I am also curious as to how it will contribute. I know there are some prospective speedups in linear solvers on quantum hardware, but as far as I know, it will still need significant interaction with conventional computing - and I wonder how well small quantum systems will compare to massively parallelized conventional hardware, and at what point (and when) quantum will get an edge. To my knowledge, the prospectively revolutionary impact of quantum computing is mainly related to solving quantum(like) problems. And classical CFD seems to be a bit distant from that.

[nzjrs]

Massively OT: There is a joke going around amongst NVIDIA engineers that they memed realtime raytracing into existence because as crypto mining on GPUs gets less profitable and more politically problematic they need another reason to make the gamers buy new GPUs now that gaming technology has been otherwise stagnant or only sub linearly improving for the last 5 years.

There is some truth to that joke IMO.

[hUirEYExbN]

Bi-directional ray tracing with a turbulence model allows you to determine the start and end points of the Ray. Using BiRT, you can "paint" the high and low pressure spots on the car, and how you WANT the flow-fields to look, and let the algorithm define the necessary shape to manufacture it.

Does a bidirectional ray tracing with turbulence model exist? Ray tracing traces light rays, does it not? Clue's in the name. How does that help with airflow modelling? And why is it better than CFD? The thing that is actually designed from the start to model air flow.

We're ot. I'll pm you

It is interesting enough to start a thread.

[DChemTech]

Massively OT: There is a joke going around amongst NVIDIA engineers that they memed realtime raytracing into existence because as crypto mining on GPUs gets less profitable and more politically problematic they need another reason to make the gamers buy new GPUs now that gaming technology has been otherwise stagnant or only sub linearly improving for the last 5 years.

There is some truth to that joke IMO.

At least Lattice-Boltzmann CFD also reaps some of the benefits.

[Zynerji]

Just going to copypasta the PM I sent JaF here since there's interest.

Back in 2009 I was into the OpenCL, GPU crunching scene very deeply. I was doing RC5 hash cracking and Raytrace (LuxRender, or at the time, SmallLuxGPU) Turns out that I would be a Billionaire today if I was mining Bitcoin instead, but that's a sob for another day..

Anyways, when we were tuning the software backend with testing, Dade (lead programmer) was sharing code snippets explaining how he was harnessing the GPU power. Part of that code showed a "behavior model", like whan angle to reflect on various surface checks. I asked him if it could be done with a more sophisticated bounce model, IE Navier Stokes turbulence models, he assured me that it could with more horsepower to crunch the numbers. He also speculated that with the piggyback of raytracing code that the NS solvers may converge almost instantly as the recursiveness is handled by the Bi-directional ray caster, so you already have the answers in the software.

I then speculated that one could plot a flow field of desire, and generativly create shapes until it matches the requested outcome. He said that the nature of the model would work best with an iterative design, or a ML tool chain (omg, 2009!) that could tomographically construct the model from the pressure map areas. Like X shape creates Y effect.

I just figured that the teams have been doing this for years anyway. Just no one talks about it.

[langedweil]

Interesting ... all chinese to me though.

[PlatinumZealot]

Just going to copypasta the PM I sent JaF here since there's interest.

Back in 2009 I was into the OpenCL, GPU crunching scene very deeply. I was doing RC5 hash cracking and Raytrace (LuxRender, or at the time, SmallLuxGPU) Turns out that I would be a Billionaire today if I was mining Bitcoin instead, but that's a sob for another day..

Anyways, when we were tuning the software backend with testing, Dade (lead programmer) was sharing code snippets explaining how he was harnessing the GPU power. Part of that code showed a "behavior model", like whan angle to reflect on various surface checks. I asked him if it could be done with a more sophisticated bounce model, IE Navier Stokes turbulence models, he assured me that it could with more horsepower to crunch the numbers. He also speculated that with the piggyback of raytracing code that the NS solvers may converge almost instantly as the recursiveness is handled by the Bi-directional ray caster, so you already have the answers in the software.

I then speculated that one could plot a flow field of desire, and generativly create shapes until it matches the requested outcome. He said that the nature of the model would work best with an iterative design, or a ML tool chain (omg, 2009!) that could tomographically construct the model from the pressure map areas. Like X shape creates Y effect.

I just figured that the teams have been doing this for years anyway. Just no one talks about it.

How does that tie into the CFD mesh?
Because the mesh nodes are what are culcated.

And as rays are straight lines how does that work say around a curve? Like the curves of the car?

Hard to see how that works for F1 CFD.

Two different techniques. Im not a programmer but I was a user of ray-tracing and CFD. So this is interesting but you have to explain this one.

[Zynerji]

Just going to copypasta the PM I sent JaF here since there's interest.

Back in 2009 I was into the OpenCL, GPU crunching scene very deeply. I was doing RC5 hash cracking and Raytrace (LuxRender, or at the time, SmallLuxGPU) Turns out that I would be a Billionaire today if I was mining Bitcoin instead, but that's a sob for another day..

Anyways, when we were tuning the software backend with testing, Dade (lead programmer) was sharing code snippets explaining how he was harnessing the GPU power. Part of that code showed a "behavior model", like whan angle to reflect on various surface checks. I asked him if it could be done with a more sophisticated bounce model, IE Navier Stokes turbulence models, he assured me that it could with more horsepower to crunch the numbers. He also speculated that with the piggyback of raytracing code that the NS solvers may converge almost instantly as the recursiveness is handled by the Bi-directional ray caster, so you already have the answers in the software.

I then speculated that one could plot a flow field of desire, and generativly create shapes until it matches the requested outcome. He said that the nature of the model would work best with an iterative design, or a ML tool chain (omg, 2009!) that could tomographically construct the model from the pressure map areas. Like X shape creates Y effect.

I just figured that the teams have been doing this for years anyway. Just no one talks about it.

How does that tie into the CFD mesh?
Because the mesh nodes are what are culcated.

And as rays are straight lines how does that work say around a curve? Like the curves of the car?

Hard to see how that works for F1 CFD.

Two different techniques. Im not a programmer but I was a user of ray-tracing and CFD. So this is interesting but you have to explain this one.

It is point cloud, so no mesh. The conjecture was to use the rays to "erode" the point cloud and leave shapes behind that generate the desired flow-fields around the object.

The "bounce behavior" can be turbulent (curved) with added ray collision detection. The horsepower to calculate was the only issue. The bi-directional nature of the ray caster allowed you to pick where you want any ray to start and end. That was what gave this generative modeling concept power, as you could use the BiRT to bundle the rays by density, and generate a model to run in an actual CFD software to correlate.

He/we never explored much past that conversation, so I'm sure there are more devils in the details. It just seemed reasonable to speculate that someone has done this by now with the huge computing power available in a multi-GPU desktops and super-computers.

[nzjrs]

It is point cloud, so no mesh.

The "bounce behavior" can be turbulent (curved). The horsepower to calculate was the only issue.

He/we never explored much past that conversation, so I'm sure there are more devils in the details. It just seemed reasonable to speculate that someone has done this by now with the huge computing power available in a multi-GPU desktops and super-computers.

It's not *just* compute - it convergence or the ability to converge. The whole engineering art and the bounds on usefullness of most of these approaches is differentiability of the transform and the implied smoothness or shape of the energy/parameter space to be explored.

(at least as you describe what is almost a complete target -> design reverse optimization problem)

So describing these things as click and go makes assumptions about the shape of the optimization landscape and not *only* the compute cost to explore it. The best these things will be is a minor optimization for the last x% to refine the draft given by a designer - because any other case the convergence will be sketchy as a generalized tool.

There are first principles in play here that in general can't be ignored or brute forced around.

A centering example I communicate to beginners is something like; ML of the 2000s (generative, evolutionary, etc) used to surprisingly often not dramatically better than just randomly exploring the parameter space, in the same way that many of the complex optimizers or DL solutions today are often not much better than just exhaustive linear regression. Compute made gradient descent cheaper, that's it, basically. It means you can be wrong about the gradient more often, but thats not changing the fundementals.

There is way more subtlety here, and I'm not going to claim to know the properties of the CFD optimization landscape. My intuition is that irrespective of the shape of the CFD landscape, because the cost to explore it will be higher than (my field, visual DL), the confidence in which you can say a tool just works 'converges somewhat globally optimally' is much lower.

[PlatinumZealot]

Machine learning is used to a limited extent in F1. Amazon is actually leading the way with the AWS as much as fans like to laugh at them. But its a good exposure to bring teams into taking advantage of machine learning / AI. Machine learning and AI requires huge computing. It's application in F1 in think should be limited, because if it is allowed we would too much convergence in solutions. F1 would be almost a spec series if everybody knows the optimal solutions to things.

[nzjrs]

Machine learning is used to a limited extent in F1. Amazon is actually leading the way with the AWS as much as fans like to laugh at them. But its a good exposure to bring teams into taking advantage of machine learning / AI. Machine learning and AI requires huge computing. It's application in F1 in think should be limited, because if it is allowed we would too much convergence in solutions. F1 would be almost a spec series if everybody knows the optimal solutions to things.

I would say Machine learning is used to an enormous extent in F1, because that term includes almost everything. As a term, It's also imprecise to the degree of being worthless. I mean any laptime simulation or error detection is going to be able to be called ML. You could push it and say monte-carlo is ML probably.

For a 10000 foot view here is a map of flavours of ML problems/solutions at least

https://docs.microsoft.com/en-us/azure/ ... heat-sheet

I would argue DL and the convolutional approaches should get their own sheet, and another for optimzation strategies per DL arch, but thats not needed now.

[Stu]

Just going to copypasta the PM I sent JaF here since there's interest.

Back in 2009 I was into the OpenCL, GPU crunching scene very deeply. I was doing RC5 hash cracking and Raytrace (LuxRender, or at the time, SmallLuxGPU) Turns out that I would be a Billionaire today if I was mining Bitcoin instead, but that's a sob for another day..

Anyways, when we were tuning the software backend with testing, Dade (lead programmer) was sharing code snippets explaining how he was harnessing the GPU power. Part of that code showed a "behavior model", like whan angle to reflect on various surface checks. I asked him if it could be done with a more sophisticated bounce model, IE Navier Stokes turbulence models, he assured me that it could with more horsepower to crunch the numbers. He also speculated that with the piggyback of raytracing code that the NS solvers may converge almost instantly as the recursiveness is handled by the Bi-directional ray caster, so you already have the answers in the software.

I then speculated that one could plot a flow field of desire, and generativly create shapes until it matches the requested outcome. He said that the nature of the model would work best with an iterative design, or a ML tool chain (omg, 2009!) that could tomographically construct the model from the pressure map areas. Like X shape creates Y effect.

I just figured that the teams have been doing this for years anyway. Just no one talks about it.

Love this sort of technology (although I don’t like the idea of this kind of AI iterative tech in F1 - Luddite!!); this sounds like a very similar idea to some of the iterative FEA/stress analysis software currently in use?

[Zynerji]

Just going to copypasta the PM I sent JaF here since there's interest.

Back in 2009 I was into the OpenCL, GPU crunching scene very deeply. I was doing RC5 hash cracking and Raytrace (LuxRender, or at the time, SmallLuxGPU) Turns out that I would be a Billionaire today if I was mining Bitcoin instead, but that's a sob for another day..

Anyways, when we were tuning the software backend with testing, Dade (lead programmer) was sharing code snippets explaining how he was harnessing the GPU power. Part of that code showed a "behavior model", like whan angle to reflect on various surface checks. I asked him if it could be done with a more sophisticated bounce model, IE Navier Stokes turbulence models, he assured me that it could with more horsepower to crunch the numbers. He also speculated that with the piggyback of raytracing code that the NS solvers may converge almost instantly as the recursiveness is handled by the Bi-directional ray caster, so you already have the answers in the software.

I then speculated that one could plot a flow field of desire, and generativly create shapes until it matches the requested outcome. He said that the nature of the model would work best with an iterative design, or a ML tool chain (omg, 2009!) that could tomographically construct the model from the pressure map areas. Like X shape creates Y effect.

I just figured that the teams have been doing this for years anyway. Just no one talks about it.

Love this sort of technology (although I don’t like the idea of this kind of AI iterative tech in F1 - Luddite!!); this sounds like a very similar idea to some of the iterative FEA/stress analysis software currently in use?

I wouldn't doubt it. It seems that lots of things that were impossible before 10TFLOP processing power GPU's became mainstream are now within reason.