[Agad15]

Is there any commercial CFD code (like.. FLUENT, CFX etc) to perform DNS (Direct numerical simulations)? If no, why?

[jdrch]

The main reason for this is the same reason CFD was once limited to academia: DNS in its current state is tractable for simple, idealized problems only. Most commercial packages are written to be usable by engineers with BS degrees and college level fluid dynamics knowledge. DNS doesn't fit that description (yet), which limits its commercial market.

Last I heard from ANSYS about DNS - at a conference of theirs - they have no plans to implement it in any of their products.

[Agad15]

Thanks for the reply. But if developing DNS code for a specific problem takes a considerable amount of time, atleast t some already developed versions should have been made available in the market for free .
This saves the time and there is no point in re-inventing the wheel

[jdrch]

Originally Posted by Agad15

Thanks for the reply. But if developing DNS code for a specific problem takes a considerable amount of time

DNS codes aren't written for a specific problem, the entire point of DNS is to directly solve - as opposed to model - the fluid flow. As such, DNS is really very general and can be applied to any case. Unfortunately for numerical reasons it rapidly becomes computationally intractable as the cases become even mildly complicated. For a brief discussion of why this is the case, see the literature.

I'm sure there are academic DNS codes out there, but if you're not aware of the method's limitations it might best for you to learn more about it before you try using them.

[sbaffini]

First of all, any given code can work in DNS mode, which is just no model at all. What makes the difference is the amount of grid points required by a spectral method when compared to other approaches with low accuracy. Even a first order upwind could be used, but the amount of required points would soon become proibitive even for the cases which are today routinely computed.

This roughly means that you can use Fluent to perform DNS if you know how to do it.

Having said so, Nekton, a spectral element code, was commercialized by Fluent in the 90's. Today it is open source (Nek5000) but, possibly, is what is more close to a user friendly DNS code. There are alternative options, but open and, from my point of view, with much less user friendliness and flexibility.

[pswpswpsw]

Originally Posted by sbaffini

First of all, any given code can work in DNS mode, which is just no model at all. What makes the difference is the amount of grid points required by a spectral method when compared to other approaches with low accuracy. Even a first order upwind could be used, but the amount of required points would soon become proibitive even for the cases which are today routinely computed.

This roughly means that you can use Fluent to perform DNS if you know how to do it.

Having said so, Nekton, a spectral element code, was commercialized by Fluent in the 90's. Today it is open source (Nek5000) but, possibly, is what is more close to a user friendly DNS code. There are alternative options, but open and, from my point of view, with much less user friendliness and flexibility.

Thank you for your valuable information. I agree with your opinion that DNS is actually no turbulence model inside, no modelling for Reynolds stresses. I am wondering about your opinion on how to use Fluent to do DNS simulation. Of course, it is a stupid question since no one would do that even if they are told to do DNS simualtion. Besides, I have one question below.

Q:
Can you tell me where I can find the Nekton? My Fluent does not seem to have this stuff.

Thanks,
Shawn

[sbaffini]

I actually used Fluent for DNS (pseudo-DNS, coarse-DNS or whatever is the name you like for it) and there is a growing trend in the journals in accepting such kind of works. If you want to succeed, in using Fluent for DNS you should use a grid which is at least a factor 2 finer in each direction when compared to grids used in spectral methods, and the time step set up accordingly to have a low courant number. Beside this and the fact that the viscous model has to be set as laminar, the remaining setting are those for LES (you can find several of my posts here concerning LES in Fluent).

You can find Nek5000 at http://nek5000.mcs.anl.gov/index.php/Main_Page

but, nowadays, it has nothing to do with Fluent.

[FMDenaro]

just to say that OpenFOAM as any other CFD software you can get (I remember a 3D FV code available by ftp site - from the book of Peric & Ferziger ) can produce a DNS solution simply setting laminar model. The key is that the grid resolution is so fine to resolve all the physical turbulent scale. This is also the reason why much engineering turbulent flows can not be resolved (yet).

[arjun]

While on the surface there is nothing special in DNS that commercial codes can not do (at least on paper), there are few issues.

Having written a code that was specifically designed for DNS/LES (even though having access to commercial codes) the major issues that specifically designed code would do better:

1. We are talking about large sizes of calculations, our minimum was 1 billion cells or so. In this situation data export, management , post processing of data etc could be real pain in A with commercial code. In case of code designed for specific purposes, this would be better (it was in my code compared to commercial codes).

2. Efficiency. A typical DNS codes that is used in univ etc uses direct solvers that are much more faster than AMG that one uses in commercial codes. Many times commercial codes are 10 to 20 times slower than specifically designed code. (I estimated my codes was at least 30 times faster than fluent for same mesh sizes).


Also note that if you are doing laminar flows and if your mesh is DNS fine, I would prefer lattice boltzman based methods for their efficiency. They might be much more efficient here.

[cfdnewbie]

Originally Posted by sbaffini

in using Fluent for DNS you should use a grid which is at least a factor 2 finer in each direction when compared to grids used in spectral methods

I would say at least a factor of 6 or so. From dissipation / dispersion analysis, I seem to remember that O1 or O2 FV schemes took somewhere between 10 and 20 cells to resolve a wave properly, where spectral codes need 2....
We are running spectral element codes with high N (8th order and above), and with that you can get down to 4 PPW, so that would be a factor of 2 compared to spectral. Low order FV is a totally different game....

[cfdnewbie]

Originally Posted by arjun

1. We are talking about large sizes of calculations, our minimum was 1 billion cells or so. In this situation data export, management , post processing of data etc could be real pain in A with commercial code. In case of code designed for specific purposes, this would be better (it was in my code compared to commercial codes).

I would like to add to that and raise the question of parallel performance of commercial codes. I know that older versions of CFX only scale up to 128 cores (which is way to low for DNS of turbulence) , but maybe they scale to higher numbers now....

Still, you need a highly efficient parallelization of both the code and the postprocessing...

[FMDenaro]

yes, in principle, the linear modified wavenumber analysis shows that a second order scheme compared to spectral scheme requires a much more refined grid...
However:

- in DNS the smoothing of the energy content caused by FV discretization is quite acceptable if the grid is enough fine to superimpose this effect to the physical dissipation of the energy spectrum. The problem is much more relevant for LES where the cut of the grid filter lies in the inertial range.
- In practice, the spectral method acts on the product (ui uj) causing aliasing. Any technique for de-aliasing causes the resolution fo the spectral method to be much more than the linear wavenumber analysis prescribe ...

[cfdnewbie]

Originally Posted by FMDenaro

yes, in principle, the linear modified wavenumber analysis shows that a second order scheme compared to spectral scheme requires a much more refined grid...
However:

- in DNS the smoothing of the energy content caused by FV discretization is quite acceptable if the grid is enough fine to superimpose this effect to the physical dissipation of the energy spectrum. The problem is much more relevant for LES where the cut of the grid filter lies in the inertial range.

Ok, I understand your point. But still, you would have to push the resolution into that range with FV, and that will be costly. Also, it is a - somewhat - "unclean" DNS, when you do that, as by definition the errors should be scale separated from the physics in a DNS. I know that this is almost impossible in practical applications, and I don't say that my DNS are "real" DNS in that sense

- In practice, the spectral method acts on the product (ui uj) causing aliasing. Any technique for de-aliasing causes the resolution fo the spectral method to be much more than the linear wavenumber analysis prescribe ...

I know exactly what you are saying, but I disagree slightly. Yes, with spectral methods, de-aliasing becomes an issue. There are some different ways to do that, but what does not change is how many PPW (grid points) you need to represent a wave. What does change is that you might need some different grid or filtering inbetween, when evaluating the non-linear terms, that's true. But in terms of degrees of freedom your solution is represented on, no, the number doesn't change.

What does change is the work you have to do per grid point, and that's of course where FV is usually way more efficient - unless you do WENO on unstructured grids or so.... but for a DNS, I haven't seen a comparison of FV vs spectral where FV gets close to Spectral in terms of efficiency....please correct me if I'm wrong! I like FV, it just needs a good inner-cell polynomial connected to it

[FMDenaro]

We experienced some comparisons for DNS with FV/SM, if you want have a look here
http://link.springer.com/article/10....162-010-0202-x

[FMDenaro]

Originally Posted by cfdnewbie

Ok, I understand your point. But still, you would have to push the resolution into that range with FV, and that will be costly. Also, it is a - somewhat - "unclean" DNS, when you do that, as by definition the errors should be scale separated from the physics in a DNS. I know that this is almost impossible in practical applications, and I don't say that my DNS are "real" DNS in that sense

I know exactly what you are saying, but I disagree slightly. Yes, with spectral methods, de-aliasing becomes an issue. There are some different ways to do that, but what does not change is how many PPW (grid points) you need to represent a wave. What does change is that you might need some different grid or filtering inbetween, when evaluating the non-linear terms, that's true. But in terms of degrees of freedom your solution is represented on, no, the number doesn't change.

What does change is the work you have to do per grid point, and that's of course where FV is usually way more efficient - unless you do WENO on unstructured grids or so.... but for a DNS, I haven't seen a comparison of FV vs spectral where FV gets close to Spectral in terms of efficiency....please correct me if I'm wrong! I like FV, it just needs a good inner-cell polynomial connected to it

I wanted to say that on a grid size h, the SM linear analysis predicts spectral resolution until to kc=pi/h but when the de-alaising is used, the last 1/3 of the range would be affected (similarly to a smoothing in FV) and in practice you are forced to work on a grid h_f = h/r (r>1) to re-obtain the spectral resolution up to kc.

[cfdnewbie]

Yes, I understand your point, I agree that if you do classical (Orszag) de-aliasing in a spectral setting, 1/3 (even 1/2 for compressible) of the "nodes" would be filtered / cut off.
But on a grid of size h, a spectral method can resolve kc/pi/h accurately, if the dealiasing is done on a grid of size 2/3*h.

In my opinion, de-aliasing does not change the grid spacing of the solution, it is just a method of removing numerical errors. The non-linear terms are just evaluated in a different way, it is not an actual change of the grid or the resolution. Yes, the best way to do de-aliasing is by interpolating to a finer grid, doing the non-linear evaluations there and projecting back, but that is not a grid change / resolution change.

On a grid of spacing h, the waves that can be represented are kc=pi/h. The solution of the PDE is represented on this grid, and only the modes on this grid are filled.
The de-aliasing might be done on an intermediate fine grid, but it is - in my opinion - not a fair comparison to count the intermediate grid as the solution grid.

What you are saying is that the de-aliasing increases the degrees of freedom one needs to resolve a wave. I disagree. The de-aliasing needs additional information do to its job, I agree. But e.g. a simple second order reconstruction ALSO introduces new DOF (and WENO even more) that you need to get the properties of your scheme.

In that sense I could argue that a higher order FV also creates additional DOF (the slopes, or the WENO weights) during its process, so the total number of DOF to represent a wave would not only be the centroids, but the reconstruction DOF as well.

This might be bit of a philosophical discussion, but let's be fair to spectral methods

[FMDenaro]

To tell the truth, I am not sure about your observation.... how do you manage the de-aliasing if you want that all components until kc=pi/h are cleared but without affecting them by the de-aliasing? This is particular relevant for LES when the SGS model has "as input" the resolved field...

[huangxianbei]

Originally Posted by sbaffini

First of all, any given code can work in DNS mode, which is just no model at all. What makes the difference is the amount of grid points required by a spectral method when compared to other approaches with low accuracy. Even a first order upwind could be used, but the amount of required points would soon become proibitive even for the cases which are today routinely computed.

This roughly means that you can use Fluent to perform DNS if you know how to do it.

Having said so, Nekton, a spectral element code, was commercialized by Fluent in the 90's. Today it is open source (Nek5000) but, possibly, is what is more close to a user friendly DNS code. There are alternative options, but open and, from my point of view, with much less user friendliness and flexibility.

Thank you. Btw, is there any open-source pesudo-spectral DNS code? I want to build a database of channel flow.

[huangxianbei]

Originally Posted by sbaffini

I actually used Fluent for DNS (pseudo-DNS, coarse-DNS or whatever is the name you like for it) and there is a growing trend in the journals in accepting such kind of works. If you want to succeed, in using Fluent for DNS you should use a grid which is at least a factor 2 finer in each direction when compared to grids used in spectral methods, and the time step set up accordingly to have a low courant number. Beside this and the fact that the viscous model has to be set as laminar, the remaining setting are those for LES (you can find several of my posts here concerning LES in Fluent).

You can find Nek5000 at http://nek5000.mcs.anl.gov/index.php/Main_Page

but, nowadays, it has nothing to do with Fluent.

My god, the memory require in Nek5000 is too high to reach, as introduced in the help, the memory require is E*(N+1)^3*400*8, for a channel flow 192*129*160 as Moin(1987),the memory should be 6000GB!!

Ummm,sorry for the wrong calculation. E is not equals to 192*129*160,but should divided by 7^3,so the memory should be about 18 GB

[sbaffini]

Dear Huang,

a very rough estimate for your case leads me to 14 GBytes of memory required when using the typical number N=16 for the local polynomial degree (or number of points, i don't remember now but it is ininfluential). Indeed, roughly speaking:

N=16 -> E = (192/16)*(128/16)*(160/16)

you have to compare the same case with the same number of degrees of freedom.