Hello to all CFX users,

I've been running on CFX 11.0 in the last few days axisymmetric simulations of a diffuser using the SST turbulence model and it worked perfectly.

I copied the .CFX file, switched to the K-E turbulence model and since then I found no way to prevent the solver from crashing after ~40 iterations. I tried using the same mesh as before (i.e. y+<2 ) as well as a new one with larger y+ values. I also changed the boundary conditions with no improvement. I really dont understand what's happening... Could anyone help ?

When I write a backup file, the solver writes:

|Bounds error detected

|---------------------

|Variable: Turbulence Eddy Frequency

|Locale : Inlet

Then, after the solver crashes, the error message is:

|ERROR #001100279 has occurred in subroutine ErrAction.

|Message: Floating point exception: Overflow

|Details of error:

|Error detected by routine POPDIR

|CRESLT = ILEG

|Current Directory : /FLOW/NAMEMAP

Thanks a lot ! Felix

hello

i am also getting error with k-epsilon model for my simulation but not with SST turbulence model. actually i am doing simualtion of mixing vessel with CFX 11 for case of SST turbulence model, it is runing very properly.. but in case of k-epsilon model, after some iteration it ends with error... wht is wrong in that case

with regards

CFDUSERIN

Try turning on the Production Limiter with a Clip Factor of 10 for the k-e model. This setting is in CFX-Pre in the section where you pick the turbulence model, under Advanced Control. SST has the Production Limiter on by default - see the turbulence theory doc for more details. k-e doesn't have it on by default (well it does, but it just has a value of 1e30, so it has no influence). I'm interested to see if this helps, so keep us posted.

Hello Stumpy,

Using the Production Limiter with a Clip Factor of 10 seems to have solved the problem. Thank you very much for the adviced, it helped a lot.

However, you might be interested to know that the convergence behavior has changed. Using the SST turbulence model, the convergence was slow but smooth. Using the K-E with the Production Limiter leads to an even slower convergence but most importantly there are important peaks in the residual curves.

Within a few (4-5) iterations, the residuals rise of 2 orders of magnitude and then get back to the level they were before. Just like if the solver was about to crash but at the last minute it regained control of the solution. This happens quite a few times.

I don't know if this can be related to the use of the limiter, I'll try reading a little more on this. What is sure is that I did obtain a K-E solution with the Clip Factor = 10. It works.

Have you ever tried the Kato-Launder option ?

Thanks again for your help,

Felix

No, haven't tried the kato-launder option. It's probably worth a try since I seem to remember that TASCflow had that option on by default for the k-e model. Glad to hear it's working.

The epsilon equation is much more sensitive to poor mesh. Check the mesh quality, in particular "Orthogonality Angle". This is one of the new mesh quality criterion calculated by the solver and written to the res file for each run.

If you were to look at your solution right before it blows or at one of the residual peaks that you describe, I would be willing to bet there is some bad stuff hapening where the orthogonality angle is poor.

Regards, Robin

My experience with axisymmetric calculations is that you once in a while can get the solver to crash. If you can afford it, it is worth considering calculating the full domain without use of symmetry planes.

Hi Robin,

This is probably another good explanation. I calculated my case on 3 meshes to make some comparisons: Y+<2, Y+=40, Y+=250. The first one of those three meshes always led the solver to crash no matter the Production Limiter I tried. In the .out file, under mesh statistics, I have the following:

Minimum Orthogonality Angle [degrees] = 4.5 !

A low minimum orthogonality value is nothing surprising since I have extruded a 2 degrees slice in ICEM to make my calculation axisymmetric (but don't ask me why CFX now calculates 4.5).

The thing is: If I want to run an axisymmetric calculation, I can't help having low angles at the axis, unless I take a huge slice, right ? Then does that mean that, as Dr Flow Squad suggests, the solver will crash once in a while and we have to live with it ? Or that we must run "real" 3D calculations even when were looking for a 2D solution? My opinion is that CFX should have the 2D equations implemented and use them whenever it is possible. Wouln't that help ?

Regards,

Felix

What really helps a lot is to use a very small face on r=0. Thus, rather an annulus geometry in stead of a pie. Then use a free slip wall on r=0.

There is (hardly) no difference between both approaches and make life a lot easier.

Good luck, Gert-Jan

www.bunova.nl

The orthogonality angle is actually the angle between the integration point face and the line connecting two nodes. Remeber that CFX solves on the mesh dual, so these faces are not where you might expect them to be. Since there are multiple ip faces per node, the solver calculates the area averaged value, which is what is reported.

The wedge angle shouldn't be a problem, but I would recommend using an angle of 3 to 5 degrees if you can. I would also avoid refining the mesh too much at the axis.

Have you looked at a solution right before the solver blows to see where the problems are occurring?

Regards, Robin

Hello everyone,

Gert-Jan, thank you very much for your tip but changing the problem's physic isn't something I like to do. However I'll keep that in mind if nothing else works.

Robin, I went back in the documentation to see how the orthogonality angle is measured and it is well explained, thanks.

I looked at the solution before it crashes (using no Production Limiter) and I've been surprised to see the max residuals are not at the axis. I thought that I should find them in that region of low orthogonality angle. Rather, the max residuals were in the core flow just upstream of where I would expect a recirculation bubble. I'll keep on investigating this.

I'll try using a wider slice (4-5 degrees) next week. I'll let you know wether this solves the problem or not.

Regards,

Felix

Hi there,

Using a 4 degrees slice didn't improve the convergence in my case (the solver still crashes). I also used a 1mm radius near the axis to get rid of the small angles, as Gert-Jan suggested but it didn't work either.

It must be something else but it's hard to figure out what since the solver crashes in 2-3 iterations afetr having done 40 good ones ! The fine-looking solution then completely changes, and a wall is placed on 100% of my inlet ! Maybe I should change my outlet condition from "opening" to "outlet".... Yep, think I'll give it a try.

Keep on working and smiling, the week is almost over ;-)

Felix