[wouterremmerie]

Hi all,

I would like to have comments of technical people on an article we've recently launched on the new Tesla Semi:
https://www.airshaper.com/media/tesla_semi.pdf

It is mainly aimed at non-technical people but of course we will get (sceptical?) comments from the technical corner as well.

Therefore, I would like to get warmed up and receive your most uncensored & honest comments possible!

PS:
I'm a technical guy too, so it may hurt me a little, but go ahead

Regards,

Wouter Remmerie
CEO
AirShaper NV
wouter@airshaper.com
+32 486 89 87 86

[FMDenaro]

In my opinion there is nothing really surprising... high speed railway trains have now similar aerodynamic shape to reduce drag and their velocity is higher than tracks.

[Martin Hegedus]

I gather you are making a comparison of the Tesla truck to a European truck and not a U.S. truck. U.S. and European trucks are significantly different for a reason. Not sure exactly why, but I believe it's due to regulation.

My two cents in regards to drag, there is drag due to the forebody, base, undercarriage, and skin friction. I believe a substantial amount of the drag comes from the base. And base, along with undercarriage, drag is challenging to capture. If I were in the audience I would expect to be shown that, at a minimum, one can reasonably capture base drag with the analysis method they are using. By looking at your streamlines I gather you used a RANS method. RANS, in general, does poorly on the base.

[wouterremmerie]

Hi all,

thanks for the feedback!
Indeed, we use RANS to perform our simulations and it has more difficulties to capture separation then for example LES or Lattice Boltzmann. But for our target audience, designers & engineers that want to rapidly gain insight during the design stage, RANS can still be quite useful (and accurate if mesh is fine enough).

Thanks for the comments, I'm armed better now

Regards, and if there are any questions, just shoot!

Wouter.

[Martin Hegedus]

1) For this case, RANS can capture the separation occurring at the sharp edges of the base accurately.
2) The inaccuracy of RANS is a result of the high levels of eddy viscosity that smooths out the unsteady aspects of the wake and thus affects the pressure distribution on the base, or other backward facing surfaces. Refining the grid will not improve that aspect of inaccuracy.

[FMDenaro]

I agree, the magnitude of the turbulence model in RANS exceeds that of the local truncation error you can reduce by a very fine grid.

[wouterremmerie]

Hi all,

thanks again for the feedback!
We're looking at unsteady sims as well (LES perhaps) for the future.
Although this might sky-rocket computer cost

Does anyone have a (very rough) estimation on how the calculation time would increase from RANS to LES for an identical mesh (I know, this question is full of holes, like the mesh might be different between both, depends on LES settings etc, but still !)

Thanks

Wouter.

[FMDenaro]

Originally Posted by wouterremmerie

Hi all,

thanks again for the feedback!
We're looking at unsteady sims as well (LES perhaps) for the future.
Although this might sky-rocket computer cost

Does anyone have a (very rough) estimation on how the calculation time would increase from RANS to LES for an identical mesh (I know, this question is full of holes, like the mesh might be different between both, depends on LES settings etc, but still !)

Thanks

Wouter.

As you wrote, the mesh sizes used in LES and in URANS can be quite different. The computational cost for LES increases because you need to go over in your run after that the solution is fully correlated to sample the data to be post-processed.
Then, the cost in LES increases if you adopt the dynamic SGS model.

[arjun]

Originally Posted by wouterremmerie

Hi all,

thanks again for the feedback!
We're looking at unsteady sims as well (LES perhaps) for the future.
Although this might sky-rocket computer cost

Does anyone have a (very rough) estimation on how the calculation time would increase from RANS to LES for an identical mesh (I know, this question is full of holes, like the mesh might be different between both, depends on LES settings etc, but still !)

Thanks

Wouter.

I am working on this exact issue for one company (Can't name). They now do LES with roughly 1.5 billion cells and calculation takes almost like 2 to 3 months to finish due to transient nature. They also calculate drag and lift.

What we are trying is to have third order solver and then reducing the model size by 7 to 10 times while trying keep cost per time step not much more than second order solver.

If this is what is bugging you it would be nice if you kept eyes on Wildkatze3O solver. I intend to make it public in march start.
(currently tests planned on super computing facilities here and until testing is finished it won't be public).

[wouterremmerie]

Dear Arjun,

1.5billion cells, that is impressive!
I can't imagine that this is for the automotive industry, so my money is on aviation (I don't expect any reply on this one!).

That solver, is it for OpenFOAM or a standalone solver?

By trading mesh resolution for a higher order scheme, are you worried you loose some of the geometry detail? Or is it already so detailed that it does not matter much anymore?

And is it not quite difficult to get a third order scheme stable?

Very interesting!

Wouter.

[FMDenaro]

Computing viscous drag in LES requires to solve the BL and the grid reaches easily the order of 10^9 nodes. High order schemes do not change the final resolution dictated by the grid size but acts to gives to the SGS model a more accurate filtered field. What is the shape of this filtered field is a different issue....

[LuckyTran]

Originally Posted by wouterremmerie

Does anyone have a (very rough) estimation on how the calculation time would increase from RANS to LES for an identical mesh (I know, this question is full of holes, like the mesh might be different between both, depends on LES settings etc, but still !)

For an identical mesh it is somewhat plausible to make this estimate. From my wall bounded flows experience:

Let's say you have been using whatever software to do steady RANS (on a really fine mesh with y+ ~ 1 or less already) and now you naively just switch to transient LES and let it run. It is quite comparable to switching from RANS to URANS (but of course with super tiny time-steps for your LES).

I would generally estimate it as 1 order of magnitude from switch from RANS to transient. And the number of time-steps is on the order of 100k-1million. So that I would say the LES is roughly 100x more expensive than RANS. That number is subjective because it depends on your typical RANS, do you normally achieve convergence within 1000, 10000, or 100000 iterations? i.e do you consider convergence as residuals of 1e-03,1e-06, etc. So maybe 1000x?

[arjun]

Originally Posted by wouterremmerie

Dear Arjun,

1.5billion cells, that is impressive!
I can't imagine that this is for the automotive industry, so my money is on aviation (I don't expect any reply on this one!).

That solver, is it for OpenFOAM or a standalone solver?

By trading mesh resolution for a higher order scheme, are you worried you loose some of the geometry detail? Or is it already so detailed that it does not matter much anymore?

And is it not quite difficult to get a third order scheme stable?

Very interesting!

Wouter.

This company is a sports equipment company.
We are still in process of validating and seeing if we really gaining on efficiency or not. It will take some time to make valid conclusions.

What is for sure though is that for the same mesh you do get more accurate results. So even for finer meshes using higher order is not bad idea.

The solver is something I wrote (so far I am only one person developing it). Here is a preview of current version.

https://youtu.be/v8yLx8AvRYw

Note that this GUI is not yet available to public as this java based gui is just been developed. Current public version has Qt based GUI so that does not show next iteration of this solver.

[arjun]

Originally Posted by FMDenaro

Computing viscous drag in LES requires to solve the BL and the grid reaches easily the order of 10^9 nodes. High order schemes do not change the final resolution dictated by the grid size but acts to gives to the SGS model a more accurate filtered field. What is the shape of this filtered field is a different issue....

There are lots of interesting things came out of this exercise. So far the cost increase in third order solver is roughly 60 to 70 percent per iteration. What it means is that if early it took 10 seconds then for same mesh now it would be 16 to 17 seconds. But accuracy increase is much higher.

So one of the major things that I amm thinking is that even for same mesh size it would make sense to do higher order CFD just for accuracy purposes and this could be viable alternative to second order solver.

[wouterremmerie]

Hi Arjun,

that looks impressive, your solver!
Nice work.

Thanks for all the input, it is very helpful.
It counters a bit the feedback I often get to stick to first order schemes for stability reasons (which is still a valid remark I think, but I did not realise the moderate penalty on iteration time for switching to higher order schemes).

Good luck with the software!!

[FMDenaro]

Originally Posted by arjun

There are lots of interesting things came out of this exercise. So far the cost increase in third order solver is roughly 60 to 70 percent per iteration. What it means is that if early it took 10 seconds then for same mesh now it would be 16 to 17 seconds. But accuracy increase is much higher.

So one of the major things that I amm thinking is that even for same mesh size it would make sense to do higher order CFD just for accuracy purposes and this could be viable alternative to second order solver.

The issue is quite more complex... In LES, the accuracy order must be associated to the shape of the filter one expects in the simulation (I mean about implicit filtering). If you are using FV method, you can increase the flux reconstruction to higher order but the resolved (filtered) field is still second order in space compared to the "ideal" DNS field, according to the meaning of the top-hat filter. Conversely, if you use FD, the higher order discretization of the derivatives affects directly the implicit filtering. Theoretically, the more the accuracy of FD the more the filter tends towards a spectral resolution.
Therefore, the choice of the accuracy is somehow a parameter in the "project" of the filter one want to be in effect. And that affects the characteristic filter width one has to prescribe in the SGS model.

[arjun]

Originally Posted by wouterremmerie

Hi Arjun,

that looks impressive, your solver!
Nice work.

Thanks for all the input, it is very helpful.
It counters a bit the feedback I often get to stick to first order schemes for stability reasons (which is still a valid remark I think, but I did not realise the moderate penalty on iteration time for switching to higher order schemes).

Good luck with the software!!

Thats the challenge part that the solver shall be stable for industrial applications while maintaining accuracy. It is not easy but we try.

[arjun]

Originally Posted by FMDenaro

The issue is quite more complex... In LES, the accuracy order must be associated to the shape of the filter one expects in the simulation (I mean about implicit filtering). If you are using FV method, you can increase the flux reconstruction to higher order but the resolved (filtered) field is still second order in space compared to the "ideal" DNS field, according to the meaning of the top-hat filter. Conversely, if you use FD, the higher order discretization of the derivatives affects directly the implicit filtering. Theoretically, the more the accuracy of FD the more the filter tends towards a spectral resolution.
Therefore, the choice of the accuracy is somehow a parameter in the "project" of the filter one want to be in effect. And that affects the characteristic filter width one has to prescribe in the SGS model.

Also facing another issue of viscous term that hardly provide better than second order.
Over all it has been tough business with third order solver.

[FMDenaro]

Originally Posted by arjun

Also facing another issue of viscous term that hardly provide better than second order.
Over all it has been tough business with third order solver.

This issue could be relevanto for the dynamic eddy viscosity model. However, in this case the test-filtering will be a further operation where accuracy can be relevant... they appears as nested problems...