Dear collegues, Could you give view on StarCD and CFX 5? What's "better" and "more strongly"? Our university want to buy licence of one of those but we want to do the best choice. Our specialists and I too didn't use those CFD codes. We deal with heat exchanger tasks (especially complicated external streamline, free surface and porous solids with thermal flux). I'm impatiencing yours answers. Thanks.

It's hard to say which CFD code is "better" or "more strongly". I think we could say that it is suited to model a process or not.

I don't know well the StarCD but I always hear good words about it.

I use CFX-5 and I know Fluent. I could say that for your needs the CFX-5 is the better choice. Besides the models and multiphase flow the CFX solver is completely coupled and parallel. Thus you have results faster than others softwares. I have seen benchmarks that prove this.

This is a personal opinion but I guess CFX more friendly...

I hope it helps.

Thanks Ribeiro. I was glad to get your answer. Those were usful. And I've got some quastions. (If you don't mind) Has CFX 5.4.1 advanced post-processor? I wonder shall I use other codes as one? What duration do you spend to get result of task of average complication? What part does preparing take of the duration?

Ok, Suteh (It's really don't bore me!)

Well, a new version of CFX-5 will be released on october 2001, CFX-5.5. This version has much more features than CFX-5.4.1. The post-processor is the CFX-Post. Very very good. It is a real advance.

Of course, if you have money to spend, two or more codes are recommended. With this you can compare and take the potentialities of each code.

I have done a watergate simulation (2 phases: air and water) with more or less 300,000 cells. The setup part was really fast (without CFX knowledge would spend 1 afternoon) and the real transient simulation for 10 s take 1 night (8 to 10 hours). The same problem with CFX-4 (a seggregate solver as Fluent and Star-CD). I took 4 to 5 days.

I hope it helps.

I work(ed)with both starcd and cfx 5. To put it in a nutshell: CFX solver is superior and really fast. It is easy to get a solution quickly (automated unstructured meshing) STAR-CD is more of an expert tool. Takes longer to generate a grid but is very flexible and complete (physical modelling wise). CFX is developing rapidly to include more models (turbulence, multiphase). For our application (transonic interior flows) I like CFX 5 best.

Hi, Ribeiro Thanks you. Have you ever used nonstationary boundary condition doing any task by CFX? I've heard there's no that possibility. Is it correct?

Hi, Bart Prast, thanks.

Hi Suteh,

I am a CFX employee, so you can take my comments with the necessary grain of salt . Before coming to CFX a year ago however, I was a Star-CD user and thus have a good base for comparison.

A thorough discussion of the two codes could go on forever, and as Ribeiro has pointed out, the question is really "What code can do your job well?". I will point out some of the major differences which come to my mind.

Others may want to comment on these, and given there are many aspects to a CFD code, I will break my discussion into 3 main categories: i) Pre-processing, ii) Solver, iii) Post-processing.

Here we go...

Geometry: Pro-Star has some geometry import and creation utilities, but tools are limited.

The CFX-5 pre-processor, CFX-Build, is based on MSC-Patran. As such, it includes a complete CAD package and all the geometry import capabilities of MSC-Patran.

Units: StarCD users must take care to enter values in a consistent set of units. This is a major source for error.

Model geometry and boundary conditions may be specified in <bi>any</bi> units. All boundary conditions, fluid properties, etc. have units attached. A list of default units are provided at each dialog, but the user may specify the units by assembling them from other base units, or an expression whose results are in the correct units. This unit conversion/conservation capability is found throughout CFX-5.

Expressions: There is no facility to enter expressions for boundary conditions in StarCD, other than perhaps using a user FORTRAN routine.

In CFX-5, expressions may be specified using the CFX Expression Language (CEL) and used for boundary conditions. CEL has access to many solver variables and advanced functions. Functions include standard trig functions, exponentials, step functions and others. In CFX-5.5 it is also possible to write an expression for one boundary which is dependant on an averaged quantity from another boundary!

Meshing: StarCD includes some rudimentary meshing tools, but users typically depend on a third-party meshing tool to do the job.

CFX-5 includes an advanced advancing front mesh generator which allows generous control of meshing parameters. The CFX-5 mesher will also extrude the surface mesh for a number of layers (called inflation) to provide better discretization in boundary layers.

These would be the major differences which come to my mind. As a general comment, I find the CFX-Build pre-processor to be much more intuitive than Pro-Star. If I had to choose the most important difference, it would be the unit conversion/conservation capability.

Robin

The most significant technology of any CFD solution is the solver. Provided that a user can set up the necessary grid and boundary conditions, the solver can make or break any simulation. Here are a few differences between the CFX-5 solver and StarCD.

Fundamentals: StarCD solves finite volume based equations on a staggered grid. That is to say that the Momentum equations are solved at cell vertices and the pressure equation is solved at the cell center. There is no coupling between the equations, so although iterations do not take long, convergence will not be achieved quickly.

CFX-5's is a <u>coupled</u> element based finite volume method. The Pressure and Momentum equations are coupled and solved at the same location.

Solver: StarCD employs an iterative solver. By iterative I mean that the solver sweeps through the entire grid at each iteration. As a consequence, the solution time will increase exponentially with grid size.

CFX-5 employs an unstructured multigrid solver. Between each timestep, the multigrid solver agglomerates cells into successively coarser grids, solving an error equation at each level until at the coarsest level a direct solver may be used. This results in rapid convergence and a constant solution time per node (ie double the grid size and the solution only takes twice as long, not 2^4).

Execution: The StarCD solver must be compiled for every new grid. Not only does this require that you have the necessary compiler to run StarCD.

CFX-5 does not. Enough said!

Extension: If a StarCD user wishes to introduce a source term, or solve any additional equations in the course of a run, they must modify a User Fortran routine and recompile.

CFX-5 provides the CFX Expression Language (CEL) and CFX Command Language (CCL) to extend the capability of the code. Within the pre-processor, or from the definition file, a user may write an expression (with units of course to be evaluated in the course of a run. This expression may interact with momentum, energy, pressure equations as desired. Prior to CFX-5.5 (which introduces combustion among other features), combustion equations could be entered and solved by CCL. If a user must perform complicated logic, the CCL provides a junction-box capability to link to pre-compiled shared libraries prepared by the user (CFX-5.5).

Parillelization: StarCD runs in parallel, but the set up is painful and is next to impossible to run on multiple platforms.

CFX-5's parillelization has been implemented at a highly abstracted level (developer speak. The parallel performance is superb, in some cases providing super-linear performance! Parallel setup is very simple; users simply click on a button and select the systems they wish to run on (mix and match Irix, Sun, NT, Linux...). Memory overhead is also very small in parallel, thus x processors results in 1/x the serial memory requirement for each processor.

Discretization: StarCD is very difficult to converge using a second order scheme and next to impossible to start 2nd order without a good initial guess. UDS is generally the desired scheme, particularly when a tetrahedral mesh is used.

CFX-5 features a 2nd order high resolution discretization (basically a bounded second order scheme). The solver can be started from scratch using this scheme and performs beautifully. We do not recommend converging solutions using UDS as first order results will be unreliable

I could go on, but I'll be lucky if you read this far. Suffice it to say that the solver is very accurate, robust and fast.

Robin

So you set up your problem and ran it to convergence, what about the results? A post-processor is vital for extracting the results of your solution.

I won't go far here. Having used Pro-Star, I can confidently say that Ensight and Fieldview's bread and butter is StarCD users. Pro-Star is poor at best; graphic objects are difficult to create and manipulate, quantitative post processing is ridiculous. Only single operations may be performed at a time, therefore to evaluate a simple expression, the user must break that expression into a sequence of +'s /'s *'s and so on. I've seen machine language which is more readable (well not really, but close

CFX-5's old post-processor, Visualize, had excellent graphic capabilities but was poor when it came to quantitative results (though still much better than Pro-Star). CFX-Post, the next-generation post-processor for CFX-5 is unbelievable! As with the rest of CFX-5, units are obeyed. Users can create whatever expressions they wish, and units are calculated automatically. Expressions are entered in the same CEL used elsewhere in CFX-5 (pre, solver, post).

Macros for CFX-Post (known as session files) can be created automatically by recording the users actions. The standard language is CCL and CEL, but programming structures in macros may be added by using PERL launguage constructs (why re-invent the wheel, Eh?).

(Oh yeah, I forgot to mention that these PERL constructs (known as Power Syntax) can also be used in the solver definition file to execute PERL commands from the solver!)

Well I think that is plenty for now. If any of you have more questions or comments, I encourage you to respond.

Best regards, Robin

Being an CFX 5 user (and former STAR-CD user) I agree with 90% of your story. However, the fact that STAR-CD relied on user FORTRAN was a BIG plus for me. To be able to write your own subroutines outside the CFD package is very good (and will be in CFX 5). I'm not quite convinced that CEL is very convinient if you have large and complex source terms f.i.

But the solver is superb!

Hi Bart,

You're absolutely right. The lack of user fortran up until 5.5 has been a hinderance. However, other than doing very complicated logic (beyond step functions), there is little one needs user fortran for.

Robin

Hi, Robin Steed I'm sorry my answer is belated. Thank you for detailed and very interesting answer. It has helped me seriously to recommend to my chief to choose CFX (undoubtedly). Besides we've had talks with CFX distributor. They gave me and my colleagues useful information. Best regards.

Hi Suteh,

Glad I could help.

Best regards, Robin

Hi, Suteh

What you mean nonstationary boundary? The boundary properties vary with time or it has a velocity?

regards

Ribeiro

Robin, very through comparison. Thanks.

Can you comment in the same manner about CFX and Fluent. My university in "thinking" about Fluent however I thing it is very weak solver. What do you think?

Pop

Mr. Steed,
As a new user in CFX-5, I would like to discuss some aspects about your comments. . .
In Pre-Processing, at least the way I've been building my solids, I still could not obtain an inflated layer near the walls (prisms elements) and I still don't know its reasons. So I have been running my cases only with tetraedral elements, which is generated inside the geometry given a Maximum Edge Length (BUILD 5). Yes, I can run hexaedral meshes too, I also have been greatly solving CFX-4 meshes in CFX-5, but sometimes your geometry cannot be broken in several blocks to have a structured mesh using BUILD-4. Now, we're acquiring CFX-HEXA hoping that those issues will be gone and also hoping that this pre-processor will be as useful as BUILD (4 or 5) are to us.

In the discretization aspect, unfortunately the 2nd order scheme cannot always be started from the scratch. We work here with an specific problem which we must start the 2nd order discretization from a 1st order results file.
To finalize, I would like to discuss one more thing. When I work with CFX-4, segregated solver, imagine that I spend 'n' days to achieve a converged solution, a transient turbulent flow in a mesh containing 50k cells (a good number of cells to my problem). We had migrated to CFX-5, due its coupled solver which is much more faster thant the segregated one and due a lot of features, etc... Also imagine that I built a tetraedral mesh with 70k cells, which I classify a coarse grid to this case, and I run in paralel (2 jobs in the same computer).
So, if I submit these two jobs in two computers (PC with about 800MHz and 512Mb RAM each). In one computer, running CFX-4, the same case and mesh commented above, I spend 'n' days to solve it, and in another computer, a dual pc, running CFX-5 paralel (2 jobs), solving the same case but in a tetraedral mesh. I can say that, in my short experience time as CFX-5 user, I spend '2n' days to solve the same case in this code. Why two times more than CFX-4 and running in paralel mode?
I agree with you when the coupled solver is much more faster than the segregated, but is the coupled solver more stable? This case mentioned, in CFX-4 I use 10^-2 as timestep, whereas I must use timesteps in order of 10^-4 to converge the solution in CFX-5, that's why it costs much more days to me. If you ask me if I performed a benchmark, given the same mesh (hexaedral), comparing CFX 4 against 5, in terms of computational efforts, I still not had time to do it.
Well, I guess I'll be going now... Please, let's expand on this... Regards,
cfd guy

> In the discretization aspect, unfortunately the 2nd
: order scheme cannot always be started from the
: scratch. We work here with an specific problem which
: we must start the 2nd order discretization from a
: 1st order results file.

Odd, I'm not sure what you might be doing to have this problem. Maybe your timestep is too large? With the second order scheme it's not a good idea to use more than 1/5th of the characteristic L/V scale for your problem. Additionally, if you are running incompressible flows, try a fixed blend factor of 0.75 instead. The monotone scheme really only matters for compressible flows, and occasionally the "switchiness" of the non-linear limiter can create convergence problems, allthough it's rare.

As far as your comparison with CFX-4 goes it sounds to me like your comparing apples and oranges. You really need to take the exact same grid in both codes and solve both problems using the same convergence criteria. CFX-4 will be faster per iteration, but how you define convergence and select your timestep will affect time to convergence.

CFX-5 should be able to handle timesteps which are on the order of 1/5th to 1/3rd of the characterisPOST http://www.cfd-online.com:80/Forum/cfx.cgi?post HTTP/1.0 Content-length: 1645 Content-type: application/x-www-form-urlencoded Cookie: CFX User Forum

> In the discretization aspect, unfortunately the 2nd
: order scheme cannot always be started from the
: scratch. We work here with an specific problem which
: we must start the 2nd order discretization from a
: 1st order results file.

Odd, I'm not sure what you might be doing to have this problem. Maybe your timestep is too large? With the second order scheme it's not a good idea to use more than 1/5th of the characteristic L/V scale for your problem. Additionally, if you are running incompressible flows, try a fixed blend factor of 0.75 instead. The monotone scheme really only matters for compressible flows, and occasionally the "switchiness" of the non-linear limiter can create convergence problems, allthough it's rare.

As far as your comparison with CFX-4 goes it sounds to me like your comparing apples and oranges. You really need to take the exact same grid in both codes and solve both problems using the same convergence criteria. CFX-4 will be faster per iteration, but how you define convergence and select your timestep will affect time to convergence. Keep in mind that the two codes use completly different approaches to numerics (CFX-4 being cell-centred and segPOST http://www.cfd-online.com:80/Forum/cfx.cgi?post HTTP/1.0 Content-length: 1772 Content-type: application/x-www-form-urlencoded Cookie: CFX User Forum