You make a very good point about the importance of published validations. Let me mention where things stand now, and ask your opinion on how to improve.

There is a decent body of literature from the last 13 years on the theoretical fundamentals and certain basic validation studies of the lattice gas & lattice Boltzmann methods. The studies include DNS of lid-driven cavity, backward facing step, circular cylinder, decaying turbulent shear layer, decaying isotropic turbulence, and 3D turbulent channel flow. Many of these appear in the journals you mention, as well as Phys. Rev. E, IJMPC, Phys. Rev. Lett., Europhys. Lett., J. Stat. Phys., and others. Naturally there has been considerable evolution of the method during this time. A recent non-Exa-related review is Chen & Doolen, Annu. Rev. Fluid Mech., 30:329-64, 1998. Here one can find reference to all of the above plus a discussion of extensions to DNS of multiphase/multicomponent flow.

However, certain additional developments done by Exa that are essential for a commercial CFD tool are not adequately dealt with in that review. The most important of these are: 1) how to efficiently handle arbitrary surface geometry without stairstepping, 2) the incorporation of turbulence models for high Re flows, and 3) the inclusion of thermal evolution. The first two are published along with a number of high Re validation studies: backstep, u-bend, various commercial HVAC duct geometries, various commercial car geometries, and more; the papers (or in some cases just the references) are available at exa.com (go to Online Access and go to the bottom for Papers). Regarding #3, a publication is in press, and this is not actually in the product yet (next release).

Dr. Jasak,

I will overlook the highly offensive and childish nature of your last message in order to address pertinent technical issues that may be of interest to readers of this forum.

1) Exa has recently (last 1-2 years) been working on a method consisting of lattice Boltzmann (LB) with a k-epsilon turbulence model. In other words, the (transient) mass, momentum, and energy (MME) transport equations of the fluid are achieved using LB, while the local dynamic viscosity is adjusted to reflect the presence of an eddy viscosity contribution, as determined by a multi-equation model of the k-epsilon variety. As reported in Chris' paper, transport (in time and space) of the scalar equations for k and epsilon is accomplished via a Lax-Wendroff-like finite-difference scheme on the same grid used for the underlying LB. So far this appears overall to be an improvement over the Smagorinsky-type algebraic turbulence model currently used in PowerFlow.

I feel obliged to mention that in my opinion, this novel and compelling effort, pioneered by Dr. Teixeira, is most undeserving of your ridicule. Furthermore, it cannot possibly consitute the basis for lies or misinformation about the nature of the method, even with regard to long past sales/marketing material, because it does not even exist yet in Exa's released product code. I also note that you failed to mention to the audience the favorable results of the validation studies presented in the papers by Dr. Teixeira and his colleagues.

2) "Efficiensies above other discretisation techniques": I assume this is a reference to considerations of grid construction, which I hear can occupy a significant portion of a CFD user's time and resources for complex geometry cases using traditional CFD methods. The incorporation of k-eps turb modeling has no effect whatsoever on the gridding process in PowerFlow, which will still be totally automatic with no user involvment (the user does get to specify the choice of grid resolution in various spatial regions, as part of case setup).

3) "Exact conservation": I assume you refer to the exact conservation of MME for the underlying LB fluid algorithm. This is in no way altered or compromised by the use of a k-eps turb model.

4) "Boundedness": I assume you refer to algorithm stability. This is a very interesting and deep issue, but I will try to be brief. The underlying LB method found in PowerFlow is highly stable and robust within a range of operating parameters, most notably sim Mach# and lattice viscosity (i.e. in native units). There is some theoretical work that provides some insights into this, and a great deal of empirical evidence. The code does not allow the simulation to run outside of the known stability envelope, and PowerFlow users have never experienced instability, with the exception of cases where the simulation Mach# became too large due to inappropriate boundary conditions.

Exa recognizes that the introduction of separate but coupled dynamical equations, for k and epsilon, introduces an additional potential source of algorithmic instability. However, due to the regular cubic grid, the time-explicit scheme with step size below the CFL limit, and the fact that the hydrodynamic (MME) equations are not being solved as PDE's, it seems reasonable to believe that there will be no significant compromise of stability. While there are no gaurantees, this has turned out to be true on every case that has been tried so far, including but not limited to the ones presented in the literature.

5) Regarding the near-wall treatment in PowerFlow, I am genuinely curious as to the nature of your objection. Can you articulate why you believe it is problematic? However, if you cannot be polite and respectful in your response, please do not bother.

P.S. Regarding matters of personal integrity, you have claimed to be independent and objective. I wonder, is it possible that your comments are motivated by some undisclosed agenda, such as an association with one of Exa's competitors?

(1). I didn't know when I started reading the fine print on the canned food, on such information as the salt, sugar, fat, ...etc... (2). Most of the time, after I have read the label, I put it back on the shelf. I told myself, it is not good for my health. (3). I think, as a professional working in the CFD field, I deal mainly with numbers (most of the time in graphic forms). (4). I think, it is also true with other researchers and engineers in the CFD field. (5). The point I am trying to make is, people in this field is constantly checking the accuracy of the solutions. (6). The accuracy of the solutions naturally come from the codes and the methods used. So, the methods or codes become equivalent to the accuracy of the solutions. And people are serious about it. (7). For example, one percent in efficiency or loss can be written as 0.01. On the surface, it is small. But on the other hand, it can also be a very large number. (8). So, if the salt contents on the label is printed "very small", it is difficult to know whether it is 200 mg or 20 mg, because the product is normally measured in 8 ounces and more. 200 mg can be a small number relative to the weight of the product, but it is way too much for some buyers. (9). So, the point the company failed to recognize is that, during the first several months of promotion, it is all right to say that their products are the world best. But after that honey moon period, the company will have to speak in plain language used by the professional CFD researchers and engineers. (10). As I have said before, it is impossible to change a person. But, I also think that , it shouldn't be difficult at all to present the information on the web site, in the forum in a more accurate way, and more user-friendly way consistent with the culture of the CFD circle. (11). Basically, I get the feeling that, the company tried very hard to be outstanding and unique in image, but at the same time trying to come up with new ideas. (By the way, I don't know whether I should give it a C-. A C++ is probably acceptable.) (12). You don't try to say to the potential users or friends that you think you are right and you are the best. The customer is always "?". It is not real to most people, but it is always true.

You mentioned the automatic mesh generation.

Exa like any other automatic mesh generator needs a very smooth surface description.

Creating this normally takes most of the time to create a mesh using one of the automatic meshing tools.

There is about no advantage of using Powerflow-Meshing compared to let's say ICEM Tetra.

So cleaning a real car geometry might take a week or more using ANSA or some other tool. This includes manual work for closing gaps ...

It is really funny to see what all the vendors call "fully automatic meshing".

(1). You are right! There is no "automatic mesh generation". (2). Before, when I was using a commercial code, the 3-D automatic mesh generation always failed near the end of the process, leaving a few un-meshed. (unable to finish the volume meshing, using the available surface mesh) (3). It was very frustrated to go back to the geometry, and try to either model the geometry or the mesh in a different way. (4). Now I am checking this commercial code with template to get the mesh started. On the surface, it is an advanced concept. But, when I started using it, it divided the flow field automatically into 24 blocks in the template I had selected. (5). Now, to get a smooth grid becomes almost impossible. I had to spend 30 to 50 rounds of configuration changes to get the mesh into the right place with the right stretching. The final resultant mesh is far from smooth. (6). I didn't have this kind of problem when I was writing my own codes. (7). I think, the automatic mesh generation becomes possible only when the person writing the code is familiar with the solution and the geometry of the problem he is trying to solve. (8). If the geometry is not automatic, and the solution is unknown, it is a good idea not to use "automatic mesh generation", because sooner or later people will start using "automatic CAD design". (9). Design is "iterative", so, geometry is "iterative", and the analysis is "iterative. Therefore, the mesh also is "iterative". The mesh has to be changed based on the solution of the problem. (the mesh includes the boundary mesh and the volume mesh)

Yes, I understand it can take some effort to provide a smooth, clean surface geometry. It would be nice to have a way to make this less painful.

It also takes some effort to turn the great car design in your head into an accurately fashioned piece of clay or wood. Does this reduce the value of a well-designed wind tunnel that requires no additional fiddling around to get your experiment underway?

Once the appropriate surface description is available, with PowerFlow there are no further "meshing" issues, such as making difficult decisions regarding trade-offs between choice of mesh type, numerical diffusion/error, and chance for convergence. From what I have read on CFD-online, these can also be a cumbersome part of the CFD process.

I would also like to point out that it is not wise to run a simulation with a sloppy geometry. How can you possibly expect to get a good result using a poor representation of the true physical surface? Flow past a smooth cylinder does not have the same behavior as flow past a 20-sided polygon with a few random holes drilled into it. Certainly you would expect to have to take care to provide a good geometry if you were doing a real physical experiment.

It seems to me you are saying the following:

1) There is Method A and Method B.

2) I have tried Method A and it does not work.

3) Therefore, even though it is completely different and I have never tried it, Method B must not work either.

Caveat: the fact that you must choose the local resolution means it is still fundamentally an iterative process, because how do you know you made a good choice until you look at the solution? Maybe you cannot even afford a good choice. Nevertheless this is qualitatively different from:

1) a meshing process that "fails" before you have even started the simulation

2) a simulation that never achieves "convergence"

3) a simulation that requires enormous artificial (numerical) dissipation to achieve convergence

(1). I am somewhat tired of this strange behavior of CFD forum, CFD codes, etc... (2). So, I will be spending my time more wisely in reading books in the future. (2). As I said before, CFD is not a code. And no one will say that fluid dynamics is a wind tunnel also. That is why companies using a code to do CFD are all having problems. Car companies have wind tunnels, have they solved fluid dynamics problems? Most had problems long before using a code, so, it is not hard to understand why. (3). So, even if one fills the NASA's wind tunnel test sections with cars, I don't think the efficiency will improve when the car comes out of the wind tunnel test section. (4). Over the years, most results from CFD codes were not good enough, and most people would say it was because the turbulence models were not accurate. Such conversation and exercise is ideal for the research institutions. (5). So, you can all talk about the codes, and at the same time, I will be doing more reading, about the 3-D computer graphics and computer games. It is better than talking to a wind tunnel. (if you think a wind tunnel can solve your fluid dynamics problems, then you must be out of your mind. See, CFD is about the mind activities, not about a wind tunnel or a code. )

Well stated Dave. In addition, it is important to have a broader vision of the arena in which CFD and CAD/CAE is being applied. If it were just a ping pong match between academics there would be no application to the real world and those of us with the AE and ME degrees in fluids would be driving around broke in our K-cars, gremlins, and pintos or looking for financial aid for our next degree.

So we must look at the entire process from an engineering perspective when developing CFD tools. In terms of CAD, we have progressed from line models, to surface models, to the state of the art solid models. In terms of compute resources we have increasingly faster chip speeds, parallel processors, etc. In terms of CFD, we had panel methods, steady state solutions, and cartesian grids. Now we have body fitted grids, multi-equation turbulence models, and parallel, transient, time-accurate solvers. All three disciplines are being driven by the end-user community with a common goal of predicting reality a-priori through design, engineering and analysis.

So a CFD code that can automatically discretize ANY CAD model and simulation volume that is representing reality accurately is simply one step ahead of where CAD is today in its ability to give the CFD community a discretized surface. In other words, it won't be long before the CAD community will provide us with clean geometry, all the time, so why not have the CFD process in place when it arrives as we do now.

At the same time, I'm sure the CAD community continues to cringe every time we ask for a chunkified (facetized) version of their nice smooth cubic spline surfaces.

Perhaps a goal would be for the CFD codes to interpret the CAD geometry directly from the smooth surfaces of solid. Will we have "arrived" in terms of automatic meshing? Now are we CAD people or CFD people, or both?

Dear David,

I shall try to offer a polite answer to the person asking a polite question:

The "law of the wall", which is the basis of the wall function treatment prescribes the level of the MEAN wall shear stress for a turbulent attached boundary layer as a function of the MEAN velocity:

Tau_w^bar = f(log(U^bar))

In Powerflow, just as in LES simulations (see references I have provided by E-mail to one of your co-workers), we could only apply wall functions if we have the U^bar available (this needs time or ensemble averaging during the calculation!). What Powerflow does is:

Tau_w = f(log(U)) instantenous!

As log(U^bar) is NOT the same as (log(U))^bar, this treatment will recover the WRONG mean drag, just like the LES equivalent.

Now, for the dirty bits: (please feel free to stop reading here)

1) What Exa sells is not a Lattice-Boltzmann CFD solver 2) All operations in the solver are NOT integer-based 3) Numerical method used on decoupled equations is antiquated (only used in undergraduate numerics courses!). However I do realize the need to decouple the turbulence from the pressure-velocity solver; for un-initiated, the only real problem is COST OF COMPUTATION, which is curiously absent from any published material. 4) The method requires a turbulence model; I wonder how you'll implement a decent one, which doesn't just vary the effective viscosity(!) 5) The turbulence (k-epsilon) equations are not satisfied to the criterion you claim (i.e. exactly)! 6) Natural bounds on k and epsilon (e.g. k>0) are not present in the numerical solution, thus further reducing the accuracy of the numerics 7) Mach = 0.4 is in reality an incompressible flow. It is a bit rich to advertise a "compressible flow solver" with a limitation of Ma < 0.4!

I also appreciate the "meshing" comments other users have mentioned below - it is nice to hear that Exa is not immune to the "real world" CFD problems.

Finally, I am grateful to you for the statement on finite difference discretisation, as dr. Texeira goes to considerable trouble to exclude this statement from his publication and tries to hide it in academic slang, which I personally consider an insult to my inteligence.

Happy New Year,

Hrvoje Jasak