Hallo,

I got a problem with the CFX-solver and its convergence behavior. I have created a mesh with pretty coarse resolution (in terms of y+) and have done several runs with it without a problem. Then I have created a prisem layer in order to resolve two Zylinders in my geometry and get the seperation there(y+=2). However now the convergence behavior is zigzag-like instead of steady as it was before. And at some point of the calculation the residuals will drop very sharply towards zero (kind of "out of the screen bottom"). Unfortunatley the solver tells me that the run has completed normally. Well, quite obvious it did not. Had anyone ever had the same probelm and can help me with this issue? Or can anyone at least tell me what that sharp drop means physically/mathematically?

Regards and thanks Andy

Dear Andy,

Correct me if I have understood you wrong!!!

1) you have a bouncing convergence lines ("3" velocity lines and mass flow line) instead of a smooth line.

The bounce is acceptable if it is within the required RMS limits (example RMS = 1E-06) which depends on what exactly you are trying to solve. From my experience I have had bouncing solver convergence lines which fall within the range (RMS = 1E-06 to RMS = 1E-07).

2) you have sudden steep drops (almost vertical lines) crossing the required RMS limits. This could be only possible if the solver is experiencing extreme convergence errors and is almost about crash.

Question: Does the solver not crash when you have such drops?

Possible reasons could be an incorrect boundary conditions set (Advection scheme or the time step need to be checked).

I hope my answer serves you at least as good starting point to debug the problem.

Good luck,

Best regards, Arjun

Hey Arjun, that is right, the convergence lines are bouncing very steeply, forming linear zigzag-lines instead of the normal steady-like convergence lines (at least normal to my experience). It happens, that all lines are jumping far below the convergence criteria with a single jump. The weird thing is that CFX is reporting a "... has finished normally", that is it does not report a linear solver error or something like that. I have not changed my BCs compared to the coarser grid and the time step is at 1/3 of the physical time step (as recommended by the CFX-help).

Probably the mesh is screwed by the very thin prism layers. However the "check mesh" in ICEM does not report any problems and the worst TETRA-quality is acceptable, too, I think. (about 0.025) I think I have to figure out a different way of creating the prism layer /y+ - resolution.

But thanks anyway

I am not sure whether it is really a prism issue, In fact creating prisms near the walls should help in improving convergence, as tet elements adjacent to walls create troubles in convergence (and its a known thing). Further if it could be help, I am currently running a flow around an object (with complecated geo) with prisms around it and it is converging very well.

I guess your problem may be due to the fact that you are trying to solve it as steady state where as this may be an unsteady problem (am not very sure about it but consider this possiblity).

Further the issue could be cfx solver it self, because it is coupled solver may give you convergence problems at very low velocities (symm might have helped convergence some way, i am not able to think that).

for me I am sick of one thing that how slow cfx is compared to fluent. I am running the same mesh with same boundary conditions on both solvers (that is fluent and cfx)

Calculations started at last wednesday 2:30 pm for cfx 5 pm for fluent. Last evening, cfx = 87 time steps done, fluent 245 time steps done. CFX is bloody slow.

Hi,

Just on the CFX versus fluent thing - yes, CFX is likely to be slower than Fluent on an iteration speed comparison. CFX is a fully coupled solver versus Fluent being uncoupled (but recently they have claimed to add a new coupled solver, I don't know much about that). This means CFX works harder per iteration, but should converge in much less iterations.

Comparing the speed of iterations between software is meaningless. The speed at which accurate results are produced is a more useful comparison.

Glenn Horrocks

I agree with most of what you have said. Like agree that comparing speed of two solvers is meaningless in most of the situations. But could be meaningful in some cases. I am waiting for both of them to finish the calculations so that I can compare the results and see whether doing calculation with CFX really worth the extra wait. For us, how much time the solver takes is important, because the mesh sizes are large and we need to run at least 2000 time steps to reach the conlcusions about the results. As far as results are concerned, Fluent has so far given best results (when compared to experimental values) among the solvers we have tried so far (two more, Cobalt and one another univs code). So in this senario where results are same or not better it is foolish to spend three times of time of fluent run on CFX. I hope you understood my point. For CFX I am running with 3 coeffo iterations where as with fluent i am running 8 iteration per time step.

I guess the major slowness in speed comes from the fact that CFX uses ILU preconditioner, which is far better than Gauss Siedel used by Fluent, but ILU is very costly in terms of calculations.

Further, fluent allows user to chose ILU as preconditioner where as CFX does not give any other option.

And yes, Fluent has density based coupled solver with AMG and Full multigrid options

I have worked with both CFX and FLUENT and I must say that CFX handles the numerics far better than FLUENT. It is correct that "iteration speed" is faster for FLUENT than for CFX but, it's like comparing apples with bananas. As CFX uses a coupled solver compared to FLUENTS segregated solver, the changes towards convergence is higher with CFX. I have compared cases where CFX converges in less than 100 iterations, but for FLUENT it takes more than 1000 iterations. So actual wall clock time is less for CFX than for FLUENT

And it gets worse when you are running in parallel! Then the network traffic is much higher for FLUENT than for CFX due to higher amount of iterations so you spend more time on sending information from each CPU for FLUENT than for CFX. The speed-up effect is far from linear for FLUENT and is better for CFX.

Also the CFX parallel license costs only close to 1/3 of the value of a FLUENT parallel license not to forget.

It is correct that FLUENT 6.2.17 and earlier versions have a coupled solver as well but it is not as robust as the CFX solver. I have only bad experiences with the FLUENT coupled solver. I'm looking forward to the new FLUENT release 6.3 where it is announced that a new coupled solver is implemented.

To say something bad about the CFX coupled solver is that it sometimes behaves strangely with regards to 2D cases. I have experienced sudden crashes in 2D calculations using CFX that has gone well on FLUENT. Maybe it has to do with the fact that CFX is a fully 3D solver and working on a 2D grid with one cell layer in the 3rd direction is hard to handle. But anyway… who is doing 2D in 2006?

Cheers

Michael Bo

I would not rubbish either Fleunt or CFX completely. Each could be better than other in some situations. Like for example you said, you have seen a case in which CFX converges in 100 where as fluent takes 1000. (Fluent could have done that in 100 or less if you had switched to Fullmultigrid coupled solver, try that once).

Our case is DES calculations and I can not do a steady state calculation, so I have to wait till 2000plus steps to see the results. (so wall clock time matters here).

Further we are not comparing apples to banana, because I assume both are CFD Solvers and they compete with each other (i am not sure of it, after anysys took over Fluent).

I agree with you on Fluent's parallel performance, its a joke.

And we should not confuse the convergence with accuracy in results. A very good convergence does not gurantee very accurate results. We want accurate results, we can get well converged results with Fluent. (So there is no need to look upto CFX for it).

Another advantage CFX has over Fluent is it supports transition model with DES, and we are hoping for our cases, transition model gives us more accurate results than what we are getting with Fluent.