There are a number of things that bug me about using the Fluent package, just from an operational point of view.

1. Having to run hummingbird at the same time 2. Having to do mesh generation in a separate package. 3. C programming 4. The documentation

How do the other big packages stack up in comparison( eg. ACE, star CD etc.)

Dear John,

Have you contacted ANSYS, and ask for information about ANSYS CFX?

1 - It does not need Hummingbird to run on Windows.

2 - If you work within the Workbench enviroment, it does not need a separate package for meshing

3 - Depending of how complex is your model, you may not need any programming at all. However, if you do, it will be via Fortran..

4 - Well.. Not sure about that since I do not know your metric.

Good luck in your search,

Opaque.

how about star-ccm+, you will find the environment really familiar, its all in one (including meshing) , it uses java and doesn't need user code

It really comes down to what you want to do. There are some jobs for which Fluent would be my first choice, for some jobs it wouldn't really matter and for some others I would rather not have Fluent.

1. Having to run Hummingbird/Exceed for Gambit is a very minor inconvenience, and if it really bugs you, just use Linux or some other supported Unix. But really, it should be the least of your concerns.

2. This rather depends on the type of meshing you need. If the quality of solution is dependent on an intricate mesh (which is often the case), you will need a separate meshing program anyway.

3. OK, this is a minor pain. In CFX, for example, you can use the expression language to specify boundary condition profiles, instead of user coding as required in Fluent. But then again, if you do need user coding, Fluent has the advantage that you can do much with interpreted C, so you don't always need a separate compiler. With CFX, for example, if you need user-coding you have to find Compaq Fortran.

4. I don't think the Fluent documentation is that bad.

All of these codes have their advantages and disadvantages over each other. I would say that Fluent's interfaces look a bit old-fashioned when compared to CFX or Ace, and even older when compared to Star-CCM. But there are far more important things to worry about in CFD than the interface ... If you are still agonising over the interface (even the old grotty ones), perhaps you you should start thinking more about the fluid dynamics!

At cd-adapco the codes and training course are ok but the problem is that you might be visited by some of the new directors who likes to travel but do not know what they are talking about.

The answer to this is to specifically ask to be visited by people who uses the code on an everyday basis or have a deep knowledge of the software tools.

In US, you can also try SC/Tetra, a japanese code which is pretty good. I think cfdrc does a good job as well.

Good luck,

Paul

Have a google on SC/Tetra, cfdrc, www.newmerical.com (J-FLO)

good luck

happy new year

Paul

I guess that is getting to the heart of my question.

Are the computational advantages of using FLUENT sufficiently great that the clunky interface can be tolerated?

Also I should have stated that I am teaching a grad class in CFD and, at the introductory level, a simple interface has distinct advantages. On the other hand, however, one does not want students to invest too much time in learning a CFD package with a nice interface but which has severe computational limitations.

If your CFD problem is simple, any code will do. If it is complex, the clunky interface is the least of your worries. Don't select a code based on the interface .... I was taken aback a little by Fluent's clunky interface when I first started using it, because it is nowhere near as friendly as the interfaces used by CFD-Ace or CFX (which is close to market-leading in this respect). However, when it becamee necessary to batch large jobs on a remote parallel machine, it was much easier to forget about the interface altogether and learn to work with journal files.

When it comes to teaching a graduate class about CFD, you really do need to steer away from the "CFD for non-experts" codes. They may be great for real world design, but at educational level you really don't want to hide the guts of the method, physics and numerics from the students. There is a very powerful argument at this level in favour of source code access. I would suggest that even Fluent is inappropriate at this level. When your graduates get out in the real world, they can then pick up any commercial code and they should then be able to use them quickly with confidence, because they understand the core science of CFD properly. The nice interfaces come into their own when setting up complex new problems, but at teaching level you would be working with relatively simple problems, focusing rather on the physics and numerics, so once again, interfaces should be relatively unimportant.

Hi,

I am CFX user and do like its strong solver, very convienient expression language, and nice interface. But if I am a teacher, I may consider Fluent. Simply because Fluent owns almost 60% CFD market and the student may be benificial from learning Fluent when they start looking for a job.

Regards,

John

Hi, I feel Fluent is the software which has right mix of operational efficiency and Solver capability and Robustness.

1. If you are worried about starting Hummingbird for Gambit, you can have a batch file, which will have commands to start hummingbird and then Gambit.

2. Meshing you have to always use the mesher, Whether it may be CFX(ICEM-CFD), StarCD(ProStar/ProAM) or Fluent( Gambit). But I accept, no one will like to do mesh using Gambit, if they have some other option.

3. About programming, it is better to learn C programming. Because even StarCCM + may come only with C interface in future. And learning is first step towards Java... Java is going to be the future of CAE software interfaces( GUI + interaction with CAD + interaction with post processor + cuztamization)

My choice for Meshing ICEM-CFD (Un-beatable), Solver Fluent for simple physics(day to day work) and StarCD for complicated physics.

However, when it becamee necessary to batch large jobs on a remote parallel machine, it was much easier to forget about the interface altogether and learn to work with journal files.

You are correct, I also do almost all my work with journals on Fluent. Almost every thing for me is now automatic. I worked with CFX for 3 months and I felt it was just pain in arse. I do not want to work with it again.

I agree with what you say.

One good practice that I want to instill in my students is the need to perform mesh refinement studies.

Imagine my surprise then when I discovered that there is no way to read in a new mesh to fluent without wiping out the boundary conditions.

I realize this can be done with journal files, but previous versions of fluent had a command

>file reread-grid

that would read in a new grid but leave everything else intact. Why are we going bacwards? This is another reason that I am looking for another code

I haven't used Fluent for a year but when I used it last there was a text-commande to write (write-bc) and read (read-bc) boundary conditions. So you would normally just have to read a new grid and then read in your old boundary conditions. Problems might occur if your grid need some alterations (creating interfaces etc.), but usually it works.

Thanks Jonas,

The answer seems to be

file write-bc grid zone replace (not "read case" as this deletes properties and solver parameters file read-bc

So, three commands to replace the single command file reread-grid

That's what I call progress

So, you got the same answer on this forum as you got on the Fluent forum.

Are still talking about the "reread-grid" command from version 4 of Fluent? Again, I'm not sure that any of the unstructured grid versions of Fluent ever had a "reread-grid" command.

Have you actually tried the write/read-bc steps? There are lots of things to complain about in Fluent, but I'm happy to have the better stability and capability of the newer versions of Fluent even if it means a few more steps.

yes we noticed that recently. Avoid visit from pseudo-directors...

Yes, re-read grid existed in the unstructured versions of fluent (until recently). Like many commands, it never made it into the GUI and was text only.

Ease of use is just as important as efficiency (which are both right behind correctness), because both are about valuing the user's time to get a solution.

I would recommend STAR-CCM+ for your purpose - the models and solvers are exposed clearly in the simulation tree and make it very useful for teaching purposes.

Venkatesh wrote: 3. About programming, it is better to learn C programming. Because even StarCCM + may come only with C interface in future. And learning is first step towards Java... Java is going to be the future of CAE software interfaces( GUI + interaction with CAD + interaction with post processor + cuztamization) --

STAR-CCM+ user coding is by shared libraries (DLLs on Windows), which can be coded in any language. There are examples in C/C++ and Fortran, but any language could be used as long as C functions can be called from it.

Java is used for the client and macro language in STAR-CCM+, similar in use to the journal files in Fluent (but with the power of a full programming language).

have you tried write-bc to filename.bc then load new grid then read-bc filename.bc

Works for me! Hugo.