About the convergence
 

Hi guys,

I met some problems when running the simulation in Starccm+:

1. Version confliction. I made several volume mesh in version 5.02 and run them. And then the version 6.02 came out in April. So I run them in the new version using meshes generated from the old version. Finally I found that both the residuals and results are different. Are there anybody who know's why?

2. All the simulations haven't converged. For the residual, all plots are under 10E-6 except Tdr which is round 10E-4. 6000 iterations had been done. I tried to decrease the relaxation factor by 0.1 but it didn't work. (rfs for velocity and pressure are summed up as 1, that 0.6 for v and 0.4 for p). The reason why I say it hasn't been converged is that I created a pressure sensor and a corresponding report to monitor the change of pressure in some certain interested points. The report indicated that they are fluctuation by about 2% which is two large for us. It should be less than 10E-4. What's going on?

What should I do? Thanks.

Anyone here?:confused:

1. No. But how big is the difference?
2. Fluctuations in pressure might be due to a unsteady nature of the flow.
3. In my experience, it is better to decrease the under-relaxation factor for pressure than increasing it. Even when it doesn't sum up to 1.
4. Don't expect too much precision without being sure, every source for errors is eliminated. For example, are you sure, your mesh is fine enough to give a mesh-independent solution?

Last week or so, i had some interesting experience with starccm+ . We wanted to run flow around smooth sphere and calculate drag.

Mesh size was about 2.5 million cells, all hexas.

At first we tried, spalart almaras model and the results were nothing less than shocking. There was no separation and no drag. The pressure in front of sphere for that reynolds number should be 16 but starccm+ predicted 180 or so.
This was the same story with 5.04 and newer 6.x version.

All the residuals showed convergence below 10-6 or so.

Then we tried k epsilon model and things were better but still drag and lift were only 10% of experimental values.

With LES also came out the same results.

In all the above cases we ran at least 5000 iterations.


Well failing to get the results from starccm+, i tried the same thing with my own solver.(using the same mesh and same settings).

i ran 200 iterations with Spalart and similar iterations with k omega model. My solver predicted 0.4 as Cd (experimental was 0.49).

So if my solver could do the job in 200 iterations or so, i can not understand why starccm can not do it in 5000 iterations, using the same mesh.

yes, you're right. That rule is thumb is bullshit. I did drease the pressure rf. But the problem, like you said, it's the mesh. Although it has 67M polyhedral which is a very big one, but I just checked the skewness angle and it was 132 degree...

The problem may be the base size is too big, which is 0.2 in but the inlet of my geometry is 3 in. I used some volume controls convering 70 of my geometry and obviously the base size for volumetric control is very small.

Do you agree with me? Do I need to only change the base size for those area without volumetric control or you have better idea? Please let me know. Thanks.

What do you mean by your solver? You wrote the code by yourself?

Possibly it is the mesh quality which should be blamed upon.

Changing the base size will affect the volumetric control as well, except you put an absolute number in the volumetric control.
Depending on your geometry and where the problem is located, it might also be possible to set a different surface size at a boundary or twiddle with groth rates etc. There is no general rule. Maybe you can just cut a small part of your geometry (create a block around the problem area and make an intersect) to test the settings without having to create a 67M cell mesh every time.

yes.

Why??

1. The mesh is made up of only hexa elements.

2. I used the same mesh with my solver, so why the mesh quality not an issue with my solver. Both of them are same segregated algorithm.

The problematic aspect was that solver showed convergence below 10E-6 in residual and results were far from converged.

Hey Abdul,

I got a question related the pressure monitor. I want to monitor pressure values of several single points located on the same wall. When I create the reports, which value I should choose? I selected the maximum first but I just realized that for a single point, there is only one pressure value each iteration (I'm trying to plot the pressure of those points as a function of iteration).

Then I tried surface average and I got constant zero. Since they share the same wall and I'm only interested in a single point's pressure, it seems that surface average is not correct here.

So which one I should choose to create and reports from which I can go on creating the plot. Thanks!

Funny, a surface averaged value for a point ;-) A point doesn't have any surface, that's why it is a point...

As you already mentioned, a point has only one pressure. You will get what you want when you choose maximum. It does NOT mean, you will get the pressure occuring at iteration 12487 because it is higher than the pressure in any other iteration.You will get the maximum (= only) value for this point at EVERY iteration / time step.

Or you can try expression when you prefer this, but it will not make any difference, as well as choosing minimum...

Thanks abdul. I've soloved the problem. I appreciate all your help!