Different results from stationary and rotating frame

[Ruonan]

Dear developers,

I am running v7.1.0-patch for a basic test case of a closed rotor-stator cavity. The schematic of my model is shown below. But I found the result depends on whether I run in a stationary or a rotating frame, which is not what we expected. In Sta. frame, the results are always correct; in Rot. frame, it is wrong.

When I run in a stationary frame, I just set rotating speed as boundary conditions to the rotating walls. When I run in a rotating frame, I set the Coriolis source term (rotation vector), i.e. icorio=1, then set reverse rotating speed as boundary conditions to the stationary walls.

From the figures attached below, we can see: for RANS, the k-ω SST model is frame-dependent, but the S-A model is frame-independent. So I'm using S-A model for RANS now.

For wall-modelled LES, I tried Smagorinsky and WALE, found both of the two SGS models are very frame-dependent. I need to run in a rotating frame, which is better for my rotating flows. But the current results of LES in rotating frame are all wrong.

As far as I know, all the turbulence models should be frame-independent. It will be great if you have some idea about why is my problem and maybe how to solve it? Thank you!

Best regards,
Ruonan

[Yvan Fournier]

Hello,

I assume when you switch from one reference frame to another you switch which walls are locally fixed and which ones are moving ?

I am not sure what can cause this difference. I would assume some turbulence models may include (or miss) some terms related to rotation, but am surprised you also have this issue with LES.

A asked a colleague who knows this part better if he has any ideas.

Best regards,

Yvan

[Ruonan]

Hello Yvan,

Thank you for your reply!

Yes, I checked the subroutine for rotating boundary conditions. I set different walls, either to rotate in a Sta. frame or to rotate reversely in a Rot. frame. I think the problem is not from boundary condition settings.

For LES, I'm also confused. As shown in the figure above, in a rotating frame, different SGS models give very different results. As shown in the figure below, I also tried to change the Smagorinsky constant, in a rotating frame, different Cs values also give very different results. But it shouldn't be like this.

In a stationary frame, changing SGS model and Smagorinsky constant both have little effect on the result, which is good as we expected.

I suppose something is wrong in the equations when running in a rotating frame but I haven't found the error. Thank you for checking with your colleague (I suppose is Benoît). Very much look forward to his ideas.

Best regards,
Ruonan

[BLM]

Hello Ruonan,

First I apologies for the response delay. I am not frequently on the user forum.

Indeed, it seems that there is a problem with the rotating frame of reference (icorio = 1). This option is not frequently used and it appears that it miss a test case in our validation basis in order to maintain it.

We will try to solve this problem but I am not sure we can fix it before several weeks.

So, have you consider to use the frozen rotor turbomachinery model instead of icorio ? For the rotating part, it is a somewhat hybrid formulation where all the terms are related to the absolute velocity except the convective flux which is relative (see also the attached short description). In principle, this formulation is better maintained.

You could indicate that you have a rotor with "all[]" for the rotor cells selection criteria and give a "0.0" sliding velocity at stationnary walls. You can find additionnal information here :

https://www.code-saturne.org/documentat ... inery.html

If you send me your test case, I can help you to do the data setting.

Best regards,
Benoît

[Ruonan]

Hello Benoît and Yvan,

Thank you very much for your help! I tried using the frozen-rotor turbomachinery model in this closed rotor-stator case. The result looks reasonable, which is good. But one thing I noticed is, I can't restart. Both in RANS and LES, when I run several timesteps and then restart, the calculation will crash with this error:

Code: Select all

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
   1: 0x7f5434ce46a0 <+0x59f6a0>                      (libsaturne-7.0.so)
   2: 0x7f5434cec695 <cs_mesh_get_perio_faces+0xca5>  (libsaturne-7.0.so)
   3: 0x7f5434d515a2 <cs_mesh_to_builder_perio_faces+0x32> (libsaturne-7.0.so)
   4: 0x7f5434914c75 <+0x1cfc75>                      (libsaturne-7.0.so)
   5: 0x7f5434915b04 <cs_turbomachinery_initialize+0x254> (libsaturne-7.0.so)
   6: 0x7f54356cf760 <main+0x2e0>                     (libcs_solver-7.0.so)
   7: 0x7f54342930b3 <__libc_start_main+0xf3>         (libc.so.6)
   8: 0x5629a10790ae <_start+0x2e>                    (cs_solver)
End of stack

I met this kind of restart error before. That was a bug and Yvan helped to fix it. I suspect this time it is a similar bug.

A small test case has been attached below, with the mesh, xml and subroutine. The restart error is easy to be reproduced, using either RANS or LES. It will be great if you can have a look and maybe fix it. Thank you very much!

Best regards,
Ruonan

[Yvan Fournier]

Hello Ruonan,

Are you using v7.0.4 ? With your test case, I cannot reproduce the issue on my side eitther with de development branch or the latest v7.0.4 (and even Valgrind does not complain).

Best regards,

Yvan

[Ruonan]

Hello Yvan,

Thank you! I tried two versions, v7.0.4 and v7.1.1, but both failed. It seems I do have this restarting error, on both my local laptop and HPC cluster.

Please find the listing files attached below. It will be great if you could have a look.

Many thanks,
Ruonan

[Ruonan]

Hello Yvan,

I tried version 7.1.0-patch, the case can restart without error. I don't know why, but I can use v7.1.0-patch at this moment.

Thank you very much for your great help!

Best regards,
Ruonan