CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > ANSYS > CFX

CFX vs. CFDesign

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 26, 2010, 14:12
Default CFX vs. CFDesign
  #1
New Member
 
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16
narender is on a distinguished road
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
narender is offline   Reply With Quote

Old   February 27, 2010, 15:16
Default
  #2
New Member
 
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17
derrek.cooper is on a distinguished road
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.
derrek.cooper is offline   Reply With Quote

Old   February 27, 2010, 15:49
Default CFX vs. CFDesign
  #3
New Member
 
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16
narender is on a distinguished road
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.
narender is offline   Reply With Quote

Old   February 27, 2010, 16:19
Default solution from the CFdesign Customer Portal
  #4
New Member
 
luke mihelcic
Join Date: Feb 2010
Posts: 2
Rep Power: 0
lukemihelcic is on a distinguished road
"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
shiva102 likes this.
lukemihelcic is offline   Reply With Quote

Old   September 3, 2010, 12:57
Default On the need for good convergence
  #5
New Member
 
JohnParry's Avatar
 
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16
JohnParry is on a distinguished road
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.
shiva102 likes this.
__________________
Dr John Parry, CEng CITP
Electronics Industy Manager
Mecahnical Analysis Division
Mentor Graphics Corporation
JohnParry is offline   Reply With Quote

Old   September 3, 2010, 13:17
Default
  #6
New Member
 
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17
derrek.cooper is on a distinguished road
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.
shiva102 likes this.
derrek.cooper is offline   Reply With Quote

Old   September 3, 2010, 15:24
Default
  #7
Senior Member
 
Join Date: Apr 2009
Posts: 531
Rep Power: 20
stumpy is on a distinguished road
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?)
stumpy is offline   Reply With Quote

Old   September 6, 2010, 07:32
Default
  #8
New Member
 
JohnParry's Avatar
 
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16
JohnParry is on a distinguished road
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.
JohnParry is offline   Reply With Quote

Old   September 6, 2010, 09:33
Default
  #9
New Member
 
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17
derrek.cooper is on a distinguished road
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!
derrek.cooper is offline   Reply With Quote

Old   September 6, 2010, 09:47
Default
  #10
New Member
 
JohnParry's Avatar
 
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16
JohnParry is on a distinguished road
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
JohnParry is offline   Reply With Quote

Old   September 7, 2010, 13:18
Default
  #11
Senior Member
 
Join Date: Apr 2009
Posts: 531
Rep Power: 20
stumpy is on a distinguished road
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.
stumpy is offline   Reply With Quote

Old   September 7, 2010, 19:53
Default
  #12
Super Moderator
 
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143
ghorrocks is just really niceghorrocks is just really niceghorrocks is just really niceghorrocks is just really nice
Quote:
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.
ghorrocks is offline   Reply With Quote

Old   September 13, 2010, 05:57
Default
  #13
New Member
 
JohnParry's Avatar
 
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16
JohnParry is on a distinguished road
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
JohnParry is offline   Reply With Quote

Old   September 13, 2010, 07:48
Default
  #14
Super Moderator
 
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143
ghorrocks is just really niceghorrocks is just really niceghorrocks is just really niceghorrocks is just really nice
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.
ghorrocks is offline   Reply With Quote

Old   September 13, 2010, 08:33
Default
  #15
New Member
 
JohnParry's Avatar
 
John Parry
Join Date: Mar 2009
Posts: 12
Rep Power: 16
JohnParry is on a distinguished road
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
JohnParry is offline   Reply With Quote

Old   September 13, 2010, 10:28
Default
  #16
Senior Member
 
Join Date: Apr 2009
Posts: 531
Rep Power: 20
stumpy is on a distinguished road
Quote:
Originally Posted by JohnParry View Post
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!
Thanks
stumpy is offline   Reply With Quote

Old   September 14, 2010, 03:56
Default
  #17
Super Moderator
 
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,655
Rep Power: 143
ghorrocks is just really niceghorrocks is just really niceghorrocks is just really niceghorrocks is just really nice
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.
ghorrocks is offline   Reply With Quote

Old   September 15, 2010, 23:08
Default
  #18
New Member
 
Derrek Cooper
Join Date: Mar 2009
Location: Philadelphia, PA USA
Posts: 19
Rep Power: 17
derrek.cooper is on a distinguished road
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..
derrek.cooper is offline   Reply With Quote

Old   September 16, 2010, 08:34
Default
  #19
Member
 
james britton
Join Date: Jan 2010
Posts: 38
Rep Power: 16
jbritton is on a distinguished road
Out of curiosity what type of solver technology is cf-design based on?
jbritton is offline   Reply With Quote

Old   September 20, 2010, 17:44
Default
  #20
New Member
 
narender
Join Date: Feb 2010
Posts: 3
Rep Power: 16
narender is on a distinguished road
Quote:
Originally Posted by stumpy View Post
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.
narender is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


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


All times are GMT -4. The time now is 07:22.