CFD Online Discussion Forums

CFD Online Discussion Forums (
-   CFX (
-   -   CFX vs. CFDesign (

narender February 26, 2010 14:12

CFX vs. CFDesign
I am working with both CFDesign and Ansys CFX tools for same geometry and both are not showing the same results.Now I am a situation which result I need to consider and up to my knowledge the CFX works based on control volume and CFDesign works on Finite element solver.
Can any one give me some idea what exactly happening and which one I need to consider.



derrek.cooper February 27, 2010 15:16

hello narender..could be a variety of reasons why the answers differ. It is often preferred to compare CFD results to a known result - like test data, rather than comparing two cfd codes to one another. Can be difficult to know which is correct.

I work for CFdesign, we'd be happy to work through some of your question. You can either shoot an email to or jump onto the Customer Portal and log a case.

narender February 27, 2010 15:49

CFX vs. CFDesign
Thanks for your reply, The geometry used for this work is a engine water-jacket and the issues we had faced are the dead spots(no flow). It is difficult get some measured data in those locations.My main concern is the CFDesign code does not maintain the steady state such as not maintain equal in and out flow rates (at inlet and outlet).Where as the Ansys CFX maintains the same flow rate as it solves maintain the equal flow rate at in and out.

Over all I would like to say CFDesign code is robust with less accurate when compared to Ansys CFX code.
If you can comment on this matter that would be great.

lukemihelcic February 27, 2010 16:19

solution from the CFdesign Customer Portal
"Solution Detail

Summary Information - The outlet mass flow differs considerably from the inlet mass flow

It is a common feature of the numerical solution that the outlet mass flow is fractionally less than the inlet mass flow.

However if it is more than 10% it may be attributable to the fact that the fluid has not developed at the outlets to the model. In this case we recommend that you extend both outlets (preferably as separate parts in order to specify a coarser mesh). We also recommend that you ensure that a converged solution is attained."


JohnParry September 3, 2010 11:57

On the need for good convergence
Hi Luke,

If the difference between the inflow and outflow is of the order of 10% then it's clear (in a steady state case) that the solution is simply not well converged. For internal flows its common for the mass imbalance to drop to below 1% very quickly, and this level of error, as an absolute error summed over all grid cells is generally considered the minimum level required for confidence in the results.

derrek.cooper September 3, 2010 12:17

John.. I agree..

But not sure you were getting Luke's point. I think he was simply stating that the problem may not be well posed. If you apply BC to close to an area of recirculation, for example, simulation results won't match what's going on in the world.

stumpy September 3, 2010 14:24

Which advection scheme did you use in CFDesign? I have a feeling it's first order (upwind) by default, is that correct? I'd never recommend a final solution based on the upwind scheme, but just as a test you could run CFX using upwind or CFDesign using a higher-order scheme (if available?)

JohnParry September 6, 2010 06:32

Hi Stumpy,
It also depends on the mesh. To use a second-order scheme you need to have enough mesh to resolve the gradients smoothly. It definitely isn't an alternative to using a fine mesh. There is also an impact from the mesh topology. For CFD, tet meshes are widely recognised as far inferior to hex or poly - there is a nice discussion about this in a couple of news items on the CD-Adapco site.

derrek.cooper September 6, 2010 08:33

Stumpy.. Always ensure you get the whole story about "far inferior".. There are some CFD codes that inherently struggle with TET meshes which makes meshing difficult when forced to use hex/poly.

There are other codes that were built from the ground up to handle TET meshes quite nicely. I will spare you the back and forth that will ensue from my statement. At the end of the day, use what we say on hear as a guide. But, the proof is in the pudding.

When choosing the appropriate CFD code- pick the one that is right for you. Does it fit into your process? Is it accurate? Is it robust? Is it easy enough to be used by you or your team? Does the org provide solid support?

You can only answer these questions by getting your hands dirty a bit and making some engineering decisions. Good luck!

JohnParry September 6, 2010 08:47

Here's a reference for you:
Aftosmis, M. J. & Berger, M. J. (2002) ‘Multilevel Error Estimation and Adaptive h-Refinement for Cartesian Meshes with Embedded Boundaries’ AIAA 2002-0863, 40th AIAA Aerospace Sciences Meeting and Exhibit, 14-17 January 2002, Reno NV.
Available on the web at
right click and save the target as a PDF. It's a very mathematical read, but take a look at Figure 3 which is a plot of the local truncation error (discetization scheme error). You will see that the error for tet is two orders of magnitude higher than Cartesian cells.
I leave it to Derrek to provide a reference that extoles the virtues of tets for CFD. I am not aware of one.

stumpy September 7, 2010 12:18

Thanks for the referrence - I'll read through it with interest. I agree that hex's are far less diffusive, but I don't see how polyhedrals provide an advantage over tet's in the context of this discussion. By this I mean a CFX tet mesh (which would have polyhedral control volumes) should be comparible to a polyhedral mesh on a cell centered code, right? There are many other factors too, of course. If you are comparing a tet mesh on a cell centered code versus a polyhedral mesh on a cell centered code, then yes, you are changing the control volume topology and there's some advantage to be had.
Yes, 2nd order may need a fine mesh to stay bounded, but I was actually thinking of bounded 2nd order schemes (which are not fully second order). For a given mesh, they should always reduce your discretization error. I know from my experience upwind/1st order is just far too diffusive to give accurate results, but I have no experience using this in CFDesign. I agree with Derrek - the best option is to try out the codes and find out which is best for your case, ideally comparing against known values. If narender cannot do that, then at least look at minimising discretization errors. One way to judge that is to half the mesh length scale in both of your models and see if the results change. Once you have mesh independent results in both codes then you can make a better comparison.

ghorrocks September 7, 2010 18:53


Once you have mesh independent results in both codes then you can make a better comparison.
Precisely. Comparing CFD codes based on the specification sheet is useless. The only way to do an objective comparison is to set the same simulation up in both codes and optimise for each case to get the accuracy you require - that may mean different meshes, numerics, convergence.

That is why objective comparisons of CFD codes is so difficult. And that is why most people end up deciding which CFD code to go with based on ease of use, price and how nice a guy the sales person is.

Stumpy's point about polyhedral meshes is important - a CFX mesh can be tetrahedral, but the underlying control volumes are polygonal. So CFX really is a polygonal solver anyway.

JohnParry September 13, 2010 04:57

I fully agree on the need to get grid independent results. My point about the mesh was a rather simple one. More cell neighbours provides better information about the gradients. Tets are particularly bad because three of the four neighbour cell centers are co-planar (by definition 3 points define a plane) so very little information is available to determine the gradient normal to that plane. This is why you need many more tets to get the same quality of solutions obtained on a hex mesh.

ghorrocks September 13, 2010 06:48

Sounds like we are in full agreement then - if the control volume is the tet element it can be hard to get good resolution, but as the control volume used by CFX is centred on the node so even though CFX can use tet meshes its control volume is polyhedral and therefore this limitation does not apply to CFX.

JohnParry September 13, 2010 07:33

The issue is the number of neighbours the control volume (in FV) or element (in FE) is connected to when its solved. Tets have 4 neighbours. This is what limits the information used to construct the pressure gradient terms needed by the flow solver. hexs are better, and polys better still, particularly in highly recirculating flows as you have cell faces normal to the flow. Having faces normal to the main flow direction is an advantage as the curvature and divergence terms are minimized, which is why people build near-wall meshes out of prisms if they can't use hexs. Carts are a special case, as the faces are aligned with the coordinate system in which you are trying to conserve quantities, i.e. x-, y- and z-directed momentum.

A tet mesh is a tet mesh. Unless CFX extends to stencil to include non-neighbour cells the mesh will limit the accuracy you get. This is not a limitation of CFX, or any CFD solver for that matter - just the mesh you have chosen to use with it. Ultimately, provided you can use enough mesh to get a mesh-independent solution it does not matter, but expect that to be a least 10 times the number of cells if you're using a tet mesh compared to hexs.

stumpy September 13, 2010 09:28


Originally Posted by JohnParry (Post 274966)
The issue is the number of neighbours the control volume (in FV) or element (in FE) is connected to when its solved. Tets have 4 neighbours.

I'm still not seeing the point here. So a tet control volume has 4 neighbours. CFX does not use tet control volumes, ever, so although this point is true it simply doesn't apply here. On a tet mesh the CFX polyhedral contol volume would be connected to >4 neighbours. It's not a FV versus FE thing either. You can have cell centered FV (e.g. Fluent), so the mesh elements and control volumes correspond to each other. The points made about polyhedral vs tet do apply in this case. Yes, a tet mesh is a tet mesh, but it's the control volumes that matter and a polyhedral control volume is a polyhedral control volume. I hope my understanding is correct!

ghorrocks September 14, 2010 02:56

Your understanding is correct stumpy. I think the point being missed here is that when CFX uses a tet mesh it then contructs polygonal control volumes around each node. These polygons are complex constructions of a section of the element. Then the fluxes are calculated on on the polygonal control volume. The CFX control volumes do not coincide with any mesh edges or faces.

That is why CFX has pretty much the same accuracy on a tet mesh as a hex mesh.

derrek.cooper September 15, 2010 22:08

What everyone is saying here has merit. Perfect world, hex meshes can give good results, but are a pain to generate. TET meshes are easy to create but require special care from solver developers to ensure accuracy.

The MORALE of the story... Glenn nailed it, you can generalize all you want..proof is in the pudding. You have to balance, ease of use, robustness, accuracy, how it fits your process, how it fits your budget, what does the support system work, what does the initial and advanced training offerings look like..

jbritton September 16, 2010 07:34

Out of curiosity what type of solver technology is cf-design based on?

narender September 20, 2010 16:44


Originally Posted by stumpy (Post 273948)
Which advection scheme did you use in CFDesign? I have a feeling it's first order (upwind) by default, is that correct? I'd never recommend a final solution based on the upwind scheme, but just as a test you could run CFX using upwind or CFDesign using a higher-order scheme (if available?)

Thanks for your reply and I tried your recomendation too but the restutls were still different.

All times are GMT -4. The time now is 14:38.