hello, further to this:

http://www.cfdreview.com/articles/08.../1933248.shtml

one question is: is this really useful for design changes?

with 100 millions cells you resolve flow features < 1mm look at your ruler what is 1mm.

with 1 billion cells, could you be wasting 170 hours of computation for 1 run to resolve flow pattern of the size of a hairpin, whereas 17 runs with 10 times less cells at different speed or design you give you a better understanding of the thingy you are looking at.

especially for a boat which need to run under infinite conditions of wind/wave/sail choice.

Turbulence structures can be much smaller than 1 mm and may be very important for very accurate predictions of drag. Without knowing the details, it is impossible to say if 1 billion cells was overkill or not.

Would anyone bother to resolve the minute details of a wave breaking onto a shoreline, or would instead, it be simpler to concentrate on the global nature of the wave solution?

The concept of trying for fine & finer resolution, with billions of cells, to try & understand the turbulence phenomenon, is in my experience, impractical. Better to step a few paces back & observe the global nature of the flow solution.

If a momentum wave paradigm is used to understand flows, 2D simulations in the order 7.2Gb RAM, can be completed in around 2.5 days. No flow stabilisation techniques, or tricks, are used, nor are they necessary.

mw...

<www.adthermtech.com/wordpress3>

""Our research indicates that this is among the world's first applied engineering simulations using a single mesh of more than 1 billion cells performed with commercial software,""

This statement is wrong. More than that i am not allowed to say.

Would anyone bother to resolve the minute details of a wave breaking onto a shoreline, or would instead, it be simpler to concentrate on the global nature of the wave solution?

The concept of trying for fine & finer resolution, with billions of cells, to try & understand the turbulence phenomenon, is in my experience, impractical. Better to step a few paces back & observe the global nature of the flow solution.

If a momentum wave paradigm is used to understand flows, 2D simulations in the order 7.2Gb RAM, can be completed in around 2.5 days. No flow stabilisation techniques, or tricks, are used, nor are they necessary.

mw...

<www.adthermtech.com/wordpress3>

i briefly looked at your work related to momentum waves. I find it interesting. But could not understand one thing (sorry if this is really silly question). Usually we solve poisson equation to get pressure. In the method you have mentioned do we solve poisson equation to get pressure.

Second , what about solution of air flow around bluff bodies with higher reynolds number. Is it applicable there too. I mean most of flow that i encounter are high reynolds number flows. This is why i am asking this.

question wrote:

i briefly looked at your work related to momentum waves. I find it interesting. But could not understand one thing (sorry if this is really silly question). Usually we solve poisson equation to get pressure. In the method you have mentioned do we solve poisson equation to get pressure.

mw relies:

The penalty-based solver uses a weak variational formulation, which solves for u-velocity, v-velocity & pressure in one algorithm. Take a look at the FreeFem++ website, & pages 171 - 174 of their manual, for an explanation of the method.

question wrote:

Second , what about solution of air flow around bluff bodies with higher reynolds number. Is it applicable there too. I mean most of flow that i encounter are high reynolds number flows. This is why i am asking this.

mw replies:

My simulations are currently running around Re~1200 based on body characteristic dimension. This is currently at a velocity of around 120 m/s, for air - rather close to the incompressible limit for the incompressible NS equations.

I hope that helps.

mw...

<www.adthermtech.com/wordpress3>

thank you for the reply.

I looked at the manual, and it seems they also solve a linear set of equations using conjugate gradient type of solver.

Which is what i want to avoid. (I know i can eschew this though).

Question wrote:

I looked at the manual, and it seems they also solve a linear set of equations using conjugate gradient type of solver. Which is what i want to avoid. (I know i can eschew this though).

mw replies:

On page 227 of the manual, a number of different solvers are mentioned - CG is one of them. FreeFem++ also allows other sparse solvers to be used.

mw...

www.adthermtech.com/wordpress3

Of course it's misleading/incorrect. That statement is nothing more than PR spin to make CFX sound like a good CFD solver. Funny how they don't show any figures or animations from their simulation.....

Hi Sarah

How many prcoessors did you use to resolve the flow with one billion cells?

you asking me.

I think i miswrote, i missed the commercial solver part in the statement. With commercial solvers like Fluent CFX etc yes it might be the first such run.

But if the talk is only about 1 billion cells, i have results of our simulation with me for about 1 year now. So 1 billion thing is already done.

I can not write more detail than this.

Its not even the first...http://www.deskeng.com/articles/aaafsg.htm

actually you are correct. And I was under the same impression this is why it was never a big thing.

I am currently working some code that shall handle large cases like 500 million or bigger, because we need efficient methods for our calculations.

I am think with current technology this large meshes is no biggy.

So you work in motorsport or aerospace then I presume?

You did not answer my question Sarah?

An oddity found by a German research group (FeatFlow) is that with some of the legacy solvers (FVM - no names), the high mesh-density simulations often end up producing large solution errors - the smaller the mesh size, the larger the error.

So, even if a huge mesh exists, the solution mechanism can produce rubbish.

mw...

www.adthermtech.com/wordpress3

That sounds like a solver which is not consistent (aka broken). I know nothing about the study, but a possible source of error is that the conditioning of the system decays as <code>1/h^2</code> for <code>h</code>-refinement and <code>1/p^4</code> for <code>p</code>-refinement. So increasing the resolution means that algebraic tolerances must be increased in order for computed results to show the improved truncation error.

As for <code>10^9</code>, implicit solvers for non-Newtonian flows with AMR and more than <code>10^10</code> elements is news. Explicit solvers have been doing this for years. The press release that started this thread lacks technical details and is clearly marketing fluff.

But why would one billion cells produce rubbish results. If we use smagorinsky's model or no model at all with one billion cells, it should give us excellent results. How many processors we would require to run such a job though?

You make a very significant assumption there - what kind of model is being used in their calculation.

Motorsport firms regularly use upwards of 500 million cells in their CFD of cars, but this is largely due to the complexity of the geometry involved, and I'd guess that much the same is true of the boat that was mentioned earlier. You can guarantee that the modelling used in these calculations will be RANS-based.

Using 1 billion cells on, say, a flow around an aerofoil with a RANS model should produce an extremely poor result - a significant proportion of the energy cascade will be resolved and the RANS won't be able to smear out the flow, leading to an oscillatory and essentially unconverged solution. Using LES or DNS on this case should of course produce good results, but the timescale involved to perform the simulation will be huge. You'd need upwards of 1024 processors to do the simulation as well.

Returning to the original point - is 1 billion cells useful in a design context - if the geometry needs that many cells then yes it is, but only for Reynolds-Averaged methods. Using a time-dependent method would probably result in a simulation time longer than the design cycle of the object of interest.