choice of nterup and dtref

[lzhang]

Hello,

I would like to know how to choose nterup in code_saturne. If I understand well, nterup=1 corresponds to the simplec algorithm, and nterup>1 corresponds to the piso algorithm?

I am using code_saturne 5.0.9 to simulate flow around a circular cylinder in order to determine the fluid force applied to the cylinder. And I notice that different choices of nterup (nterup=1, 5, 10) gives quite different fluid forces. The choice with nterup=5 may be wrong, because the solution at one step is not convergent. However with nterup=1, 10, I cannot understand why there is a such difference. Perhaps there is something wrong in my configuration.

Another point is that with a large nterup (nterup=20), I notice that different choices of dtref give also quite different fluid forces, which also seems very strange.

Then I go to the code, and I notice that for the 5 steps to calculate the fluid force (in predvv.f90, condli.f90), there is the if condition (iterup .eq. 1) for certain steps and no such condition for the other steps, as already pointed in the post viewtopic.php?f=2&t=707&p=3975&hilit=nterup#p3975.

So do you have any ideas about what I encountered in my simulation as described above, please? I can upload some related configuration files if necessary.

Thanks in advance!

Best regards,
Lei

[Yvan Fournier]

Hello,

Actually, to my knowledge, nterup is not a "true" PISO algorithm, in the sense that it does a more complete sub-iteration than PISO, so the prediction/correct aspects.

These sub-iterations are used/recommended mostly for coupled fluid/structure simulations with code_aster or boundary-coupling based rotor-stator computations, less in other cases, so recent feedback may be a bit limited.

I would not expect additional nterup sub-iterations to change the results in a significant manner, or at least to converge to a same result. We would need to check if there is a bug, so if you can post a small case showing this strange behavior, that would be great. Aside from a possible bug, a possible explaination might be the Rhie&Chow filter (required to avoid checkerboarding with colocated velocity/pressure), which introduces a minor "reference-time-step-dependent" term, which should be very small in most cases. Using nterup might have an influence in this term (again, I'll check with colleagues who know this part of the code better), but I would expect only a very small influence on the results. A larger impact would probably be a bug in the way fluid forces are updated, so a more detailed description on how values are influenced (stronger, weaker, ...or plots if possible) can help here.

Best regards,

Yvan

[Yvan Fournier]

Hello,

I also checked the routines given in 2011 by James Mc-Naughton in the post that you referred to, and his recommended fixes are present in version 5.0 (they were probably integrated in v3.0), so the issue you observe is probably slightly different. So a test case and/or more details would definitely be of use.

Best regards,

Yvan

[lzhang]

Hello,

Happy new year! I am sorry for the very late response. You can find in the attached .zip file the small test case which involves an oscillating cylinder with an imposed vertical motion (mesh file, .xml files and source file). The .ps file shows a comparison of dimensionless drag force and lift force using different "nterup". We can see a remarkable influence of nterup on these forces. In the first case, nterup=1, and in the second one nterup=10.

I have other more complex test cases with the same behaviour, including for example turbulent models. I can upload them if necessary. I think this small case will be enough for you to analyse the influence of nterup.

Thanks!

Best regards,
Lei

[Yvan Fournier]

Hello,

The simpler the test case the better to analyze issues, so this case should be fine. I may not be able to check it before a week or so, but I'll keep you updated.

Best regards,

Yvan

[lzhang]

Hello Yvan,

Did you have the time to look at my test case please?

Thanks!

Best regards,
Lei

[Yvan Fournier]

Hello Lei,

No, not yet, but I have not forgotten. I'll try to check this soon.

Best regards,

Yvan

[Yvan Fournier]

Hello,

Still had not had time to check this, but not forgotten...

Best regards,

Yvan

[lzhang]

Hello Yvan,

Thank you for your information, I am looking forward to your test results.

Best regards,
Lei

[Yvan Fournier]

Hello Lei,

I finally ran your test case and reproduced the issue, or something similar (I viewed the plot slightly differently).

To isolate issues, I disabled ALE, using a fixed mesh, and still reproduce a difference in plots when running additional time steps.

Plotting the velocity, I also have slightly different results, but since this may be a naturally oscillating case sensible to numerical parameters.

I'll try simply running our "flow around a cylinder" test case (similar to yours but with no ALE and automatic postprocessing scripts to check the oscillation features) with different NTERUP values and check how it behaves.

I'll keep you informed.

Best regards,

Yvan