So What Are the Parameters?
 

The Raleigh Number and the aspect ratio aren't enough information.

Do you have a complete specification that you could post? Prandtl number (or equivalently, a name for the fluid involved), temperature level, etc. In fact, a 'complete' dimensional (!) specification of the problem would be nice to see.

I don't have the $ available to buy the proceedings without a sugar daddy, but I do have a couple of 2d codes and some machine cycles available to try this problem out.

Could you help by posting the complete problem please?

Thanks

Re: This is exactly what I mean
 

In answer to your questions:

>"It converges well, fast and easily with cfx. It >doesn't with Fluent."

>Now, does that mean that the results you got from >both pakages were the same, but you had troubles >getting there with Fluent and not with CFX? So it's a >stability problem and not the accuracy of models & >solvers?

It is extremely difficult to get convergence with the models (Eulerian models and the VOF model) with Fluent. Therefore its the models and the solver ability to use them.

>"they claim to have all the models, but rarely do >they work (well)."

>Now, does this mean that both the structured (4.5) >and unstructured (5.x) versions of Fluent gave >troubles? Eulerian or Lagrangian models? DPM, VOF >etc? Or just plain troubles in every model, every >solver?

Fluent4 eulerian and vof models have the problems that I mention above. So does Fluent5 with VOF.

>Not everyone has the freedom to switch from code to >code to try and speed up convergence. A change from >one package to the other has to be based on facts and >it would be nice if this forum could provide a bit >more solid feedback backed by actual comparison >results.

You have more freedom to change than you think. Nowadays, it is pretty easy to generate a mesh with any of the packages, so its the models and the solver technologies that are important. This has chnaged fairly recently and it might well be Fluent's downfall, we will have to see.

Another point is the quality of the grids. I know its easy to get a grid out of Gambit, but what of the grid quality - leading to possible convergence problems. Further, the adaption is very clumsy, tims-consuming to set up and inflexible.

CFX5's adaption is easy to set up and flexible.....

The point I'm trying to make here is not one's codes definitely better than the other, but maybe people should look around a bit and not just believe Fluent's rheotoric that 'we are the bigger and therefore the best'.

Have a look around and maybe you'll be pleasantly surprised.

Re: So What Are the Parameters?
 

Jim,

I did not participate in the "competition", but from what I know the boundary and initial conditions are as follows: B.C.) left and right walls: T(x=0,y,t)=1/2; T(x=1,y,t)=-1/2; upper and lower walls: y=0; and y=8; qn(x,y,t)=0 (thermally insulated);

I.C.) u(x,y,t=0)=0 (at rest);

T(x,y,t=0)=0 (inconsistency in the b. and i. conditions -- some participants considered consistent initial and boundary condiitons though, thus no infinite heat fluxes were present).

Prandtl number is Pr=0.71, and Rayleigh number is Ra=340,000; all parameters are dimensionless. Seems to be everything is specified now.

Anyway, I am not saying you have to buy the proceedings -- I am not with Elsevier either -- but you may want to get a copy of these papers if you plan on running the calculations. I believe the complete set of numerical data could be obtained by contacting Mark Christon, one of the organizing committee members. His e-mail from the proceeding papers is christon@lstc.com. By the way, he might be able to provide more information on the "competition" too. Good luck.

Re: Is this the end for Fluent?
 

Please note that this is not in response to any one posting before you read below.

As most of us in CFD know, robustness does not mean much when the solutions are not accurate. Quit often, robustness comes at the expense of accuracy (due to artifical dissipation, limiters, smoothing etc.).

Forget physical models (and their mutual coupling and with the solver) for a moment. Consider simple single-phase, non-reacting, laminar, transient problems (with or without complex boundaries) and try different codes to solve them. Then one can move on to more complex problems. From what has been pointed out in couple of earlier posting, if commercial codes can not even get close to reality in cartesian geometries and not capture a stationary shock in a C-D nozzle, there isn't much sense in arguing which is better.

All this talk about robustness, accuracy, 2-phase coupling, combustion models is very vague. One should have run many different problems with different commercial codes to make statements like that. Overall, one code may be better (as you define it based on weights for accuracy and efficiency) than the other for 2-phase flows while the opposite may be true for combustion. If you are working on combustion, just make the companies put their people to work and solve a couple of sample problems (I do not know whether they charge for this). If you are convinced that the results from one are far better, go with it. You can try the same if you are working on 2-phase flows. If one code comes up on top everytime, then the debate would be over.

Anyway, talking about market shares, does any one know when each of the CFD companies started. That may have some relevance here given that lethargy in swithcing codes is inherent in most people.

Re: Is this the end for Fluent?
 

I think the myth that commercial code cannot solve cfd is simply wrong.

The problem with shocks stems from Rhie-Chow problems which is a necessary evil in implicit schemes.

Of course academic code will be run explicitly and therefore it is easier to capture shocks.

Alos if you want to compare commercial and academic code them compare them in all ways. Easy of use, time and applicability in real engineering problems.

Look at that and then re-compare.

Re: Is this the end for Fluent?
 

When applying CFD in the real world the aim is to achieve an acceptable balance between high accuracy, short time and not much money. Academic CFD achieves high accuracy (low cost?) but in long times. Accurate results could be achieved in a short time but only by spending lots of money on experts conducting the work.

Commercial CFD codes attempt to provide balance which, by its very nature, will leave people with the perception that, in one of the 3 ways, they are difficient.

Fred.

Re: Is this the end for Fluent?
 

> Forget physical models (and their mutual coupling and with the solver) for a moment. Consider simple single-phase, non-reacting,laminar, transient problems (with or without complex boundaries) and try different codes to solve them. Then one can move on to more complex problems. From what has been pointed out in couple of earlier posting, if commercial codes can not even get close to reality in cartesian geometries and not capture a stationary shock in a C-D nozzle, there isn't much sense in arguing which is better.

Kalyan, I agree with your thought process and logic 100%. Unfortunately, that is not the way alot of people think and that is truly disappointing (to me as a scientist). I had a discussion with the manager of a major aerospace corporation a few months back regarding this point exactly. They wanted to see my code do what it could not do at the time before they would give it the light of the day. I offered as a counter-example the simulation of flow over a 2-D cylinder, say at Re=3000 through 40000. The answer was, this is too simple a problem and not relevant to our interests. My response was, even if this is a simple problem (which it isn't) let's see whether your code can do at least as good as mine. If for such a "simple" problem your methods cannot come even close to mine (in terms of detailed accuracy) then how can you trust any other result in the more complex cases. There really was no answer except that they were "happy" with what they were getting.

I have had similar discussions with others ever since, and the response is usually similar. First response is that their code can do what they want it to do, but then when you dig deep you realize that it is only because they have lowered their expectations. That is, when you offer them an alternative they ask whether your code can solve the most difficult problems imaginable (of course the answer would be no), but when you ask them whether they can do the same problem themselves you realize that they are not even remotely close.

Bottom line, there is a lot of psychology involved in using a code. People don't usually want to admit that they have been wrong or they have problems with a methodology (since their jobs may depend on it too)

Adrin Gharakhani

Re: Is this the end for Fluent?
 

I agree with your views on MS. Perhaps market share was not a good way to illustrate my point. What I was trying to say is that engineers need a tool that can turn around a reasonable CFD simulation in a short period of time. Most of the time thay are looking for trends and not for absolute numbers. Sure, there are many academic codes that might predict the solution very accurately but they would take several months to set up and run. We're talking about real world engineering cases here, not academic problems. If Fluent could not do this better than others, do you think Ferrari's Formula 1 team would use Fluent for all its CFD work? I think not. This is why more engineering companies choose Fluent and this is why Fluent has the largest market share.

In the end, Fluent has proven to be a very reliable, easy to use CFD tool for the analysis of real world engineering porblems. All the other codes mentioned in this discussion can also solve the problems that Fluent can but Fluent just happens to be the easiest to use and the most usefull. There are certain areas like rotating machinery where other codes liek Tascflow are better and Fluent is behind but for most situations Fluent is the best.

Thank you,

Captain Soriyappa

Re: Is this the end for Fluent?
 

Shiva, you must a have Fluent shares... Remember, is MS the best overall OS? Yet it the one used by the majority of people!

Commercial codes are tested against simple cases during development and validation. I'm sure your vendor should be able to provide you with such document provided they are not confidential. But, they are developed for a variety of applications, and some are more advanded in external flows (e.g. Star) other better at internal flow, multiphase or chemistry (e.g. CFX) because of their background or dominant market. Yet these codes are a lot better to use for companies because they are robust, able to tackle a variety of problem, have good technical support and brief available.

Additionally some commercial codes can really be pushed a long way for customers with the help of the technical people either through open sub-routines or by joint development in the source code if required. These codes are maybe the family cars, if you want, that can still be customised to become fast touring cars. Academic codes are more like F1 cars, very rigid and good at few things, are not necessarliy developed to be used by a wider audience or to be further developed. This is not generally what most industry people can (drive) use or even need since they do tackle several types of problems, and they require qualities that are lacking in academic products.

Re: Is this the end for Fluent?
 

This may have been correct, it is no longer so.

Watch this space.

Re: Is this the end for Fluent?
 

This refers to shiva's claims about Fluent:

This may have been correct, it is no longer so.

Watch this space.

Re: Is this the end for Fluent?
 

Herve...you said exacly what I said! Fluent is a general purpose code (a family car) that most engineers can use. You can solve a wide variety of problems without having to be a expert in CFD. That is my whole point. Do not compare Fluent with academic codes developed to solve a certain class of problems. If Fluent and an academic code were used to solve a real world engineering problem, say flow through a HVAC system with fans etc, Fluent would provide very usefull results in 2 days while it would take weeks to do the same with the academic code. That is all I am trying to say. For pure research or academic problems, use an academic code but for everyday real world engineering problems, use Fluent.

Daddy Masood

Re: Is this the end for Fluent?
 

If you are not an expert in CFD and you use Fluent, then in couple of days you would get a bunch of color plots representing pretty much virtual reality existing only on your hard drive.

Re: Is this the end for Fluent?
 

Ken,

I did not imply that commercial codes can not solve CFD problems accurately. I never said anything about comparing commercial and academic codes either. I was merely pointing out a procedure that can be used to gauge/compare the performance of the commercial codes.

Some postings here have pointed out a couple of problems (shock capturing and Rayleigh number parameterization) with commercial codes. My point was, in light of these postings (I do believe that they are true), it does not help to have arguments with very general assertions.

One needs to have tested two codes on several problems (say for 2-phase flows) to assert that one is better than the other for 2-phase flows. If some one has done it, they could perhaps be kind enough to list the problems they solved with a brief summary of accuracy, efficiency (and ease in usage) in case of each code (or atleast point us to some references like COBOK did).

Could you shed some light on "Rhie-Chow" problems with regards to shock capturing. I have never thought of the R-C correction in the context of shocks.

Re: Is this the end for Fluent?
 

Adrin,

Thank you for pointing out yet another simple problem (flow aroung a cylinder at various Re) yet challenging. However, this is a problem that can give even academic folk a tough time.

Re: Is this the end for Fluent?
 

Why would people buy something which is not good? People buy things because they have money and they like it. It is likely that their boss think that it is good for them. This discussion is not scientific at all.

Re: Is this the end for Fluent?
 

I hardley agree with you !!!

Actually after benchmarking the package with several flow and geometries, I can say it is CFD for Dummies.

Have a good day

Re: Is this the end for Fluent?
 

Neat response Fred!

Frank

Re: Is this the end for Fluent?
 

Here's a few points of clarification.

1. The MIT special session dedicated to the 8:1 thermal cavity was motivated by a technical problem at Lawrence Livermore National Laboratory. The special session was organized by myself, Phil Gresho now retired from Lawrence Livermore, and Steve Sutton at Lawrence Livermore. Although invited to participate, no parties from Los Alamos were involved.

2. The original call for papers and contributed solutions may be found at http://www.me.unm.edu/~christon/mit_convection

The specifics of the problem definition may be found at the site.

3. If you want to see the complete set of contributed solution data and the errors based on the baseline solution provided by LeQuere and Xin, you can find the summary. in PDF at http://www.me.unm.edu/~christon/mit_convection/summary

4. We (the organizers) had no intention to embarass anyone. Instead, the goal was simply to find the best solution we could and identify the methods that could deliver such a solution.

Re: Is this the end for Fluent?
 

In response to the comment by Cobok who posted the following:

"Two commercial codes were utilized, namely LS-DYNA and FIDAP. The former was initially developed for solids/structures and recently extended for fluids at Livermore (I might be wrong here -- please correct me if I am). The latter is now marketed by Fluent, however, the people who did run analyses were not affiliated with FIDAP, rather, with the "organizing committee". That could be a reason that these codes were not too off. Tuning sometimes might help a lot."

To the best of my knowledge there was no parameter tuning beyond varying time-step size and the error control on the time-integrator associated with either LS-DYNA or FIDAP. However, this problem is a rigorous test of good numerics -- both formulation and implementation. At the MIT meeting, more than one author commented on finding bugs that prevented their solvers from functioning properly on this problem. Perhaps finding and fixing bugs fits your definition of parameter tuning?

FIDAP is an "honest" Galerkin Finite Element code, and to the best of my knowledge was exercised as such. Testing with both FIDAP and LS-DYNA showed that upwinding damps the very instabilities that make the flow transient.

In the case of LS-DYNA 3 algorithms were applied to the problem -- each in essentially a generic form. The result showed that the algorithm with the "typical CFD cheats" failed to perform reliably unless extreme mesh resolution was applied to the problem. The basic Galerkin Finite Element formulation performed the best making use of the non-disspative skew-symmetric advection operators, and a neutrally dissipative time-integrator. The only parameters adjusted were time-step, the error threshold on the local-time truncation error, and the convergence criteria on the iterative solvers.

As for the possiblity of tuning a solution, the original call for contributed papers identified readily available technical literature that provided adequate guidance on the periodic and time-dependent nature of the flow. All authors that contributed solutions were free to peruse the same literature that we the organizers used to understand the flow problem and to write the call for papers.

Perhaps you should be asking why other commercial vendors did not participate in the round-robin. In fact, the organizers approached ALL of the leading commercial CFD vendors in an effort to gain their participation. FLUENT/FIDAP, LSTC, and ADINA were the only companies to put forward their solutions.

STAR-CD, EXA, etc. all made it clear that such exercises are not aligned with their business interests and we were essentially met with a "stiff-arm at the door".

I for one applaud the efforts of all the commercial CFD vencdors that contributed to the MIT special. My only regret is that more were not willing to participate.