CFX vs. CFDesign
Hello,
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. Thanks Narender 
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 support@cfdesign.com or jump onto the Customer Portal and log a case. 
CFX vs. CFDesign
Thanks for your reply, The geometry used for this work is a engine waterjacket 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. 
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." http://customerportal.cfdesign.com/S...merPortal.aspx luke 
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. 
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. 
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 higherorder scheme (if available?)

Hi Stumpy,
It also depends on the mesh. To use a secondorder 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 CDAdapco site. 
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! 
Stumpy, Here's a reference for you: Aftosmis, M. J. & Berger, M. J. (2002) ‘Multilevel Error Estimation and Adaptive hRefinement for Cartesian Meshes with Embedded Boundaries’ AIAA 20020863, 40th AIAA Aerospace Sciences Meeting and Exhibit, 1417 January 2002, Reno NV. Available on the web at http://www.google.co.uk/url?sa=t&sou...U1cUzDjTCf5_xQ 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. 
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. 
Quote:
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. 
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 coplanar (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.

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.

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 nearwall 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 zdirected momentum.
A tet mesh is a tet mesh. Unless CFX extends to stencil to include nonneighbour 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 meshindependent 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. 
Quote:
Thanks 
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. 
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.. 
Out of curiosity what type of solver technology is cfdesign based on?

Quote:

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