|
[Sponsors] |
February 26, 2010, 14:12 |
CFX vs. CFDesign
|
#1 |
New Member
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16 |
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 |
|
February 27, 2010, 15:16 |
|
#2 |
New Member
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17 |
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. |
|
February 27, 2010, 15:49 |
CFX vs. CFDesign
|
#3 |
New Member
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16 |
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. |
|
February 27, 2010, 16:19 |
solution from the CFdesign Customer Portal
|
#4 |
New Member
luke mihelcic
Join Date: Feb 2010
Posts: 2
Rep Power: 0 |
"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 |
|
September 3, 2010, 12:57 |
On the need for good convergence
|
#5 |
New Member
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16 |
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.
__________________
Dr John Parry, CEng CITP Electronics Industy Manager Mecahnical Analysis Division Mentor Graphics Corporation |
|
September 3, 2010, 13:17 |
|
#6 |
New Member
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 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. |
|
September 3, 2010, 15:24 |
|
#7 |
Senior Member
Join Date: Apr 2009
Posts: 531
Rep Power: 20 |
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?)
|
|
September 6, 2010, 07:32 |
|
#8 |
New Member
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16 |
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.
__________________
Dr John Parry, CEng CITP Electronics Industy Manager Mecahnical Analysis Division Mentor Graphics Corporation Last edited by JohnParry; September 6, 2010 at 07:51. |
|
September 6, 2010, 09:33 |
|
#9 |
New Member
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17 |
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! |
|
September 6, 2010, 09:47 |
|
#10 |
New Member
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16 |
Stumpy,
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 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.
__________________
Dr John Parry, CEng CITP Electronics Industy Manager Mecahnical Analysis Division Mentor Graphics Corporation |
|
September 7, 2010, 13:18 |
|
#11 |
Senior Member
Join Date: Apr 2009
Posts: 531
Rep Power: 20 |
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. |
|
September 7, 2010, 19:53 |
|
#12 | |
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143 |
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. |
||
September 13, 2010, 05:57 |
|
#13 |
New Member
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16 |
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.
__________________
Dr John Parry, CEng CITP Electronics Industy Manager Mecahnical Analysis Division Mentor Graphics Corporation |
|
September 13, 2010, 07:48 |
|
#14 |
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143 |
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.
|
|
September 13, 2010, 08:33 |
|
#15 |
New Member
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16 |
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.
__________________
Dr John Parry, CEng CITP Electronics Industy Manager Mecahnical Analysis Division Mentor Graphics Corporation |
|
September 13, 2010, 10:28 |
|
#16 | |
Senior Member
Join Date: Apr 2009
Posts: 531
Rep Power: 20 |
Quote:
Thanks |
||
September 14, 2010, 03:56 |
|
#17 |
Super Moderator
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143 |
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. |
|
September 15, 2010, 23:08 |
|
#18 |
New Member
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17 |
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.. |
|
September 16, 2010, 08:34 |
|
#19 |
Member
james britton
Join Date: Jan 2010
Posts: 38
Rep Power: 16 |
Out of curiosity what type of solver technology is cf-design based on?
|
|
September 20, 2010, 17:44 |
|
#20 | |
New Member
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16 |
Quote:
|
||
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pros and Cons for CFX, CFdesign, COMSOL | Val | Main CFD Forum | 3 | June 10, 2011 03:20 |
FloEFD CFDesign or CFX | Bigga | CFX | 4 | January 4, 2010 07:41 |
CFX or CFDesign | Ed Chavez | Main CFD Forum | 8 | October 18, 2007 05:26 |
PhD using CFX | Rui | CFX | 9 | May 28, 2007 06:59 |
CFDesign > CFX or ICEM CFD | Endlos | CFX | 0 | June 14, 2005 03:55 |