Re:FLUENT vs. CFX for RANS solution--your comments
 

hi, there,

if i want to solve RANS(Reynolds-averaged Navier-Stokes) equations for time-dependent, compressible, turbulent flows past 2-D and 3-D problems( relatively complex congigeration), which cormercial code,i.e. FLUENT and CFX, is the most suitable for my objectives?

hope to get your important comments from the following some aspects:

1) grid generation( pre-processing) 2) numerical methods/schemes 3) turbulence model 4) results output format( refer to data file)

and built-in results display(post-precessing)

thanx in advance

Re:FLUENT vs. CFX for RANS solution--your comments
 

(1). It depends on the particular problem you are trying to solve, and the user. (2). I have used Fluent/UNS, Fluent/Rampant, with prebfc, CFX-TASCFLOW with Turbogrid, CFX-TASCFLOW with ICEM/ddn, ICEM/hexa. And friends around here are using ICEM with Fluent. (3). Sooner or later, the main issue will become " Is it possible to get good converged solution for this particular problem using this particular sequence of codes?" (4). If you can't get the correct solution, you are likely to try some other codes or combinations of codes. (5). The suggestion is still very simple: define your problem, find out whether the vendor can solve it, then decide which code to use. (6). I'll give you a simple example. I was able to get coarse grid solution for problem a, using code sequence b. But when I refine the mesh using the same sequence of codes, I am still having trouble in getting a converged fine mesh solution for the problem a. (7). So, no one knows whether you will be able to get a solution at all. (8). If you like to run cfd codes, just start anywhere with any codes.

Re:FLUENT vs. CFX for RANS solution--your comments
 

John, from a convergence point of view have you found that compressible flow solutions are easier with CFX (time iterative solver) or Fluent (pressure based solver). by easier I mean which takes less manipulation of solution controls particularly on a fine mesh. also doesn't CFX also have a multigrid accelerator? have you used this? and is it effective?

Re:FLUENT vs. CFX for RANS solution--your comments
 

Hi to all

I have spent nearly 2 decades on code development using published and to a lesser extent my own algorithms, and have always felt that a CFD solution is correct only if known to be so! ( To quote Sukumar Chakravarthy more than 10 years back:" we present only the correct results!") I do not mean that there are surprises all the time (god forbid, if that were true!) but even with so called validated codes doubts do arise concerning computed solutions especially if consistency checks (such as grid convergence, use of different schemes or orders of accuracy) do not match anticipated behavior. In such situations one has to look for validation by other means (experiment if possible, other published rsults perhaps)

I have no experience whatsoever with commercial codes, and though not surprised , perhaps disappointed or comforted(?) , the present discussion for a relatively well defined problem seems to suggest that the situation here is not very different. Surely CFD algorithm development has matured much more than what has been made available to users by the commercial code developers? Perhaps we need a taxonomy of problems and related VVC (Verification, Validation and Certification) set out as a medium term goal. Surely this is possible with hundreds of users of commercial CFD software distributed throughout the world working on a wide varitey of problems!

Ravichandran

Re:FLUENT vs. CFX for RANS solution--your comments
 

(1). I must say that the problems I am trying to solve have been very complicated. So, I am not talking about simple problems. (2). For simple problems, I would say that most commercial codes can handle them easily, with not big trouble in convergence. (3). The complicated 3-D problems include flow field separations, possible flow separation at the exit plane, 3-D complex geometry, and very simple initial flow field guess. (4). The compex geometry tends to make the mesh generation very hard to create. And even if I have successfully created one, it is difficult form me to make sure that the mesh is everywhere smooth. So, In most cases, I just use the mesh generated by the code with some global parameters. And I konw that somewhere in the domain, the mesh transition between zones is not smooth, that is large mesh size ratio between two neighboring cells. You can spend a lot of time to control the mesh distribution, if you can afford it. (5). This definitely will have some impact on the convergence or accuracy, or even the turbulence modeling. (6), And if the geometry is complex, then the initial guess will have to be very simple. The consequence is frequent divergence of the process. (7). So, don't interpret my comments as the across the board issue, it is an issue only when one is trying to solve very complicated flow field. (8). We don't use the commercial codes to solve simple problems. It is kind of mis-match between the problem and the young commercial codes. But that's life. (with my own codes, I have full control of it. But this is not the case with a commercial code. This is exactly the reason why the user of a commercial code must define his problem clearly first, (I have no idea of the complexity of the problem) and make sure that the vendor using his code can solve the problem first.(before bringing the code on board) (9). But if you are paid to use existing commercial codes, then any solution is a good solution, unless, you are research oriented.