Dan, for the record, are you in any way associated with AEA or ASC?

I figured it might be a bit obvious by now. But for the record, yes.

Dan.

(1). There is nothing wrong about saying " code-A is better than code-B in application-C" (2). Readers definitely like to hear the comment about which code is better suitable for their applications. (3). The problem is: the forum is relatively young, and it is not established to conduct the consumer testing and validation yet. I have came across a website where photo equipments such as cameras, lenses, films etc. were reviewed by the reader. In this case, the readers identify themselves first , and fill out the positive and negative sides of their experience with the product. (4). Since the user is the ultimate customer, his opinion will in someway provide the rating. Naturally, the reviews are all subjective. (5). On the other hand, there is also a review website which provides technical test data and rating of camera lenses. This is a more scientific testing review of products. In this case, the reviewer and the test equipment remain the same. (6). I think, the review method mentioned in item-3, would be easier to do for the rating of CFD codes. This is because the user's needs are not the same. And this is done for a specific product only. (7). For the evaluation of the relative rating, the lab test type ,like the one mentioned in item-5, would be easier to conduct. (8). In any case, this is one area which is missing from the CFD related products. The products of CFD need to be reviewed in some way.

Eh, why should your affiliation be obvious? I had a vague memory that you had an asc.on.ca email address a couple of years ago, that's why I asked. Most readers don't know this though and hence have no way of knowing your affiliation with AEA.

AEA/ASC personnel plugging AEA/ASC products on other vendor-forums is not good for the forums - will just lead to a lot of semi-arguments between commercial vendors and make it difficult for normal users to exchange ideas and experiences.

Commercial marketing arguments between different vendors could quickly fill the forums and make them less usefull for the normal users. Hence, people associated with commercial vendors should really be careful about their conduct on these forums - you can easily create a bad reputation for your company.

Based on your second paragraph, I gather that your conclusions are based on your friends' use of Fluent and also discussions in the Forum. In other words you personally have not used the software Fluent yet you lambaste it routinely. How convenient (excerpt from church-lady Saturday night live).

You also wrote: There is no sound technical argument why a pressure based solver cannot work as well as a density based solver for compressible flows. People do it all the time. I'm not sure what you are trying to say.

My Response is: People do it all the time because it is convenient. The equations governing Compressible flows are hyperbolic-parabolic in nature whilst those of incompressible flow are elliptic-parabolic. Consequently, the two are different and so deserve different treatments. Hence the importance of the segregated and couple solvers in Fluent. For more discussions on this topic refer to Anderson et al. (1984), Hirsch volume 2 1991, and Ferziger and Peric 1991.

You wrote: If discussing the alternatives to Fluent in a Fluent forum does not fall into the category of "an exchange of ideas on CFD as it pertains to Fluent products", then what the heck does? You should feel free to point out the weaknesses of CFX products on the CFX forum if you so desire.

My response is: Discussing alternatives to Fluent is not the problem. Putting down fluent is the problem. Imagine if Fluent employees were to respond to you in kind. Then our whole forum would resemble the tower of Babel (state of confusion). I have no desire to talk about the weaknesses of CFX, you can extend that invitation to the Fluent employees. Finally, I personally think that both packages are good.

Yes, you are correct. I've seen Fluent in use and have know people routinely have many problems with the coupled solver. I'd say that lambasting is probably a bit of a strong word, but maybe I was a little short or something. I apologise to anyone that might be offended as that was not my intension. My intension was to point out that there are problems with the coupled solver, that it has a limited feature set, and that there is another alternative. That's all.

Coupled vs. segregated has nothing to do with pressure vs. density based. They are mutually exclusive topics.

It's no more convenient to write a density or pressure based solver. I've mostly worked on density based solver's and now that I've been working on a pressure based code for a few years I personally don't see the big difference. Both have their sets of problems that need to be overcome. Both can be made to work. In fact though, I'd venture to say pressure based solvers are more general and can be made to handle both regimes you mention.

The main issue with writing density based solver is that many of the poPOST http://www.cfd-online.com:80/Forum/fluent.cgi?post HTTP/1.0 Content-length: 1838 Content-type: application/x-www-form-urlencoded Cookie: CFX User Forum

(1). I think, the confusion about which code or which method is better for what applications comes mainly from the labeling of the commercial CFD software product itself. (2). Strictly speaking, CFX-TASCflow is not CFX. It was ASC-TASCflow. (3). And CFX-5 is definitely not CFX-4. This is also hard to believe. CFX-5 is not a version of CFX-4. (4). The same is true for Fluent. Fluent/UNS is not Fluent. (5). And Fluent/Rampant is not Fluent/UNS, which is not Fluent. Very funny!!! (6). Now there is Fluent/coupled, Fluent/segregated. So, where is Fluent/UNS and Fluent/Rampant? (7). What a mess. How many codes are we talking about? Do we really need so many codes in order to solve a problem? For turbomachinery applications, I think, (turgogrid + CFX-TASCflow) is better than (CFX-4, CFX-5, Fluent, Fluent/UNS, Fluent/Rampant, Fluent/coupled, Fluent/segregated) (8). But that does not mean that (turgogrid + CFX-TASCflow) will always produce satisfactory results. It still depends on the particular type of turbomachinery problem to be solved. As a matter of fact (turbogrid) can handle only the mesh around a blade. And we all know that turbomachinery is not just a collection of blades only. (9). It is very important for all readers to understand the difference between the codes even under the same company label. If they are all good, our problems would be solved long time ago.

The only thing John missed is that CFX-5 uses the same coupled flow solver numerics as CFX-TASCflow. Obviously some things have changed in order to use unstructured meshes, but the foundations are the same.

I suppose that with the other postings I had made in the past, that the readers of this group, who are obviously smart people, might have figured it out.

I guess if someone (or you) feels that I'm making AEA/ASC look bad by pointing out competitors weaknesses, and suggesting that someone try a CFX package instead, then so be it and I'll stop, especially if you feel that it does not constructively contribute to the discussions. Note that other contributors have done this in the Fluent forum before (John Chien being one of them).

I'm not really here to get into longwinded commercial arguments. I'm only trying to point out an alternative which is possibly better in some specific cases.

Dan.

(1). I did not use CFX-5, but I have received a brief introduction to it. (2). I think, it is all right to say anything you like to say, "as long as you think the message contains useful information for the forum readers". (3). To say that "I don't like you" or "my method is better than yours" does not improve the reader's knowledge when they are spending their "time" reading the message. (4). The readers of this forum, definitely would like to know the bad part of the vendor's code. So, the insider's information about the bad part of the code is highly welcome here. This will save the reader from repeating the same mistake when running the code, (does not matter whether it is vendor-A's code or his competitor's codes.)

(1). I have helped a company (over 50 years old) a couple of years ago. They used commercial CFD codes, and in the last two years, the company changed the name twice. The code they used is Fluent. (2). I also helped another company (over one hundred years old) for ove a couple of years. They changed the name once. They used TASCflow, Fluent,Star-CD, and ICEM. (3). The issue is: the real problem is so complex that a few commercial CFD codes are not going to have any impact on the design. It can only make the company look better for a very short time only.(4). If you are doing a research project in an academic institution, it is a completely different story. The main interest there is to publish the results. (5). It is not the fault of a commercial CFD code, it is because they simply do not understand the definition of CFD at all. (I am in the process of writing an introductory CFD FAQ book on CD. And I hope it will provide some essential information about CFD to those who do not have time to get a PhD. degree in CFD. ) (6). AS I have said many times before, a commercial CFD code is basically a group of modules, libraries and functions, which are invisible to the users. There is no simple ways to get the right answers. Well, even if you follow the tutorial examples, there is no guarantee that the solutions of the tutorials are accurate solutions. It is still better to find an experienced CFD engineer, instead of looking for an ideal CFD code.