|
Mesh and Solve Times for CFX, Fluent, CD-adapco
Over a year ago, I was brought into my company to be the CFD specialist. Perviously, I had a long career in writing my own codes with spectral methods, so I am new to the commercial CFD side of things. I made the recommendation for CFX because wer were already using ANSYS products, CFX was fully integrated into Workbench, and the physics that we treat is not complicated. Now that I have some experience with CFX, I am now aware of some other issues and wonder if there is a better choice.
In my (limited) experience, CFX seems to be very time consuming for both meshing and solving. I've been treating relatively simple problems in terms of the physics (forced convection with air) but in complicated geometries (complex fin designs with lots of surfaces, thus lots of inflation). How do mesh and solve times compare between CFX and other products? Additionally, it seems fairly common that my computer ends up running on vitual memory, crashes and/or corrupts the model. How do these issues compare between CFX and other products? Do other products use more than one processor by default? CFX only uses one processor, requiring a HPC license for more processors. Thanks in advance for any thoughtful comments. I am very grateful for any advice. |
Quote:
The problem and strength both of CFX are its solver. Its major time consuming part is its solver which is based on multigrid preconditioned by BiCGStab (if i remember correctly, i do not use it). Plus it is a coupled algorithm. So in theory and in practice it shall converge very fast. This seems to be true. So what is the problem. The problem is that BiCG takes lots of time compared to gauss seidel of Fluent/Starccm+ . Why is this a problem. This becomes a neuisence when you try to do unsteady simulation where you are supposed to run some fixed number of sub iterations and have to run simulation for some fixed number of time steps. Then calculations time would be at least 4 times of Fluent. for steady state problems though it might end up saving time because of coupled algo with powerful matrix solver. In sum, in CFX they have put best of everything on cost of computation time. For me Fluent is fastest so far that is commercially available. (But is slower than some of the codes i have written). |
Thanks so much, arjun.
I talked with an ANSYS engineer who had some experience with both CFX and Fluent, and nearly 20 years of experience in CFD. His comment was that CFX and Fluent are similar and that the equivalent settings could be set up in both software to give the same performance. He also commented that there is a trade off between numerical accuracy and model stability (as opposed to numerical stability, because I was having issues with my Workbench file crashing and getting corrupted). Other general comments were that CFX is better for turbomachinery whiel Fluent is better for shocks and multiphase. CFX is better for general use and also is integrated into the Workbench environment. These comments are from a particular engineer that I have a great deal of respect for. However, he does work for ANSYS and may not want to make one software sound better than the other. What are your (and others') thoughts on this? Originally, I was set on ANSYS products as we use their other software and I believe they have quality products. So then it was a matter of choosing between CFX and Fluent. Since we do have specialized applications, I thought CFX would be better. However, it might be worth reevaluating. I would appreciate any comments from experienced users. |
Quote:
Fluent,StarCCM+ and to large extent openFOAM are similar solvers. CFX is very different. There is no chance for same or similar settings. Here are the major differences: 1. Quote from CFX manual : "CFX uses an element based finite volume method. " Page 363. Then they explain what they mean by it. On page 364 there is figure 10.1. If you look at it you will understand in one glance that both can never be similar or same. The thing is in CFX control volume is constructed by centers of mesh elements present in mesh that you load. In a way that each node in mesh that you loaded act as control volume center. In fluent /starccm/openFOAM control volumes are the control volumes that you load in mesh. (no change). In other words fluent and cfx do not solve equations at same points. 2. Both use Rhie Chow approach for interpolation but the way velocity is interpolated is completely different. Fluent,starccm+ use the approach explained in peric's book.(or very close to it). Where as cfx uses very different approach. 3. Even when in pressure based coupled solver fluent and cfx construct matrix in different manner. (manual does not say much about this issue but i guess Fluent's approach is much similar to M darvish http://portal.acm.org/citation.cfm?id=1461314 I can list a lot of small difference but that would take up lots of space here. Their multigrid solver is though very similar : both are additive corrective multigrid. (starccm+ openFOAM also share this part, not sure about the coupled versions though if they are present in starccm and openFOAM???). so in theory when you use Fluent as pressure based coupled and set same setting as CFX they both shall be similarly slow :-D There is one more issue. I think (i can be wrong) that mesh quality plays important role. For good meshes segregated approach may be faster because matrices shall converge without problem. But for poor meshes coupled algorithm and coupled matrix solver MIGHT be better way to go. (this is just my guess never been tested). Quote:
CFX products have reputation for turbomachinary. But one shall be careful. big part of that reputation comes because of CFX-Tascflow. Tascflow is one that created that reputation and it was present till CFX 5 came along. Tascflow is no longer here but reputation that CFX products good for turbomachinary is continued. Having said this i still believe for flows with strong swirl CFX may be better choice. (but this is my opinion and again i may be wrong). |
Quote:
|
| All times are GMT -4. The time now is 10:57. |