code_saturne User's Forum

Hello,

Both your errors seem to be related to a memory leak or overwrite error.

I am currently running a debug version of your case, to see if I find anything...

Regards,

Yvan

Hello,

thank you very much! I do not know what i would do without your help . Maybe just for your information: i also obtain this "floating point exception" error in single mode with your pointe.f90 in SRC.

Regards,

Sebastian

Hello,

The "floating point exception" is probably another problem, maybe related to the mesh or time step. I just reproduced the memory-related crash on 2 cores, 3 iterations, using the "adress sanitizer" checks of gcc 4.8, and am trying on 1. Won't have any time for this tomorrow, so I can't guarantee how much time it will take to fix this, as I don't yet know whether this is an "immediate" or "subtle" problem.

Regards,

Yvan

Hello,

ok. Then i will wait until you will update this post. Thank you very much!

Regards,

Sebastian

Hello,

Running your case on 2 procs, I believe I have found the cause of the crash both on 1 and multiple processors:

The number of boundary faces changes with rotation, while it is assumed it should not. Arrays are thus not resized, and bad things happen.

This probably means that depending on the rotor and stator positions, some faces are not joined correctly, and remain as boundary faces.

For future releases, we'll have to add a check on this to stop with an explicit error message.
I added a possible check as an attachment (to replace src/base/cs_turbomachinery.c)

This is a mesh quality issue. Increasing the tolerance fraction a bit (from 0.15 to 0.2 or even 0.25) may help, but if it does not work, the best solution would be (as I recommended some time ago) to make the mesh more regular in the joining zone. Using a hybrid mesh with an extruded section near the joining (similar to that which could be used for viscous layers, but not too thin).

Another important aspect for mesh joining tolerance in curved areas is to avoid too "thin" cells: local tolerance is multiplied by the shortest edge length near a vertex, so if the edges parallel to the boundary are long and those perpendicular are short, joining will not work well. In short, in curved areas, the "tangential" refinement must be comparable to the "radial" refinement.

Regards,

Yvan

Hello Yvan,

ok, the cs_turbomachinery.c is a kind of control if the joining works well or not? But to overcome the problem i have either to increase the value for the fraction or to change the mesh as you mentioned? Did i understand it the right way? Were is the folder SRC/Base, please? Thank you very much for your help.

Regards,

Sebastian

Hello,

Yes, you understood correctly. I was mentioning src/base from the sources, but you can simply add the file to your case's SRC directory.

Also, when re-running the case with the modification, I saw only 1 face is added or reduced at time step 3 (with a time step of 0.0001) , so increasing the criterion to 0.2 might be sufficient.

Finally, regarding an older question of yours, in the listing, CFL is the computed CFL at the beginning of a time step (0 at time step 1 as there is no flow yet), while the Courant/Fourier criterion is a combined criterion relative to the time step (an indicator here, but used to compute the local time step for cases where that may be used).

Regards,

Yvan

Hello Yvan,

thank you for this nice explanation. I tried several values for the fraction between 0.13 and 0.2. The highest number of iterations that i have achieved was 30 . I could also observe that with increasing fraction the computed values for velocity, pressure and fourier went crazy. Adjusting the time step did not change anything.

I think that i should either refine the mesh or change it as you already mentioned (adding something like a viscous layer). Until now i used Netgen 1D-2D-3D. Due to the fact that i am completely new in Computational Fluid Dynamics (this is my first project ) i do not really know how to do this. If it takes not a too long time, could you maybe give me hint how to do this?

Regards,

Sebastian

Hello,

In your case, arranging for the rotor/Stator interface to be base on "rotational sweeping" around the rotor axis of a 2d mesh would be fine. Of course, this is not compatible with vanes, but you could try to arrange for at least one layer of cells on each side of the rotor/stator interface to be built this way.

You may then join this layer with a Netgen defined mesh, either using joining by Code_Saturne (not on the rotor/stator boundary, so definable in the preprocessing stage), or better, use that regular boundary as one of submeshes (in Salome terms) of the volume mesh (to avoid adding additional mesh-degrading joinings).

Actually, even without defining a specific layer, just arranging for the surface meshes at the rotor/stator boundary to be built by a sweep of a 1D profile around the rotation axis should help have a much better joining behavior.

The theory documentation describes the joining tolerance with a few figures, so that may help you a bit, but your time will probably be better spent experimenting with sweeping in SALOME than figuring out the intricacies of mesh joining...

If all else fails, there is always the possibility of reverting to the old Code_Saturne coupling approach for rotor/stator, as it is less picky about meshes, but with a good mesh, the new version is expected to provide better results, or at least avoid the need for sub-iterations. In the near future, I hope to be able to align the data setup of the "old" method with that of the new, so as to easily compare both, but we have not started on that yet.

Best regards,

Yvan

Hello,

thank you very much. A lot of information for me I have to read now about "rotational sweeping" and how it works. In the meantime i will try Sat/Sat coupling in 3.0.3. In the case of Sat/Sat coupling: is there a way to combine both RESULTS.case files of the rotor and the stator in ParaView?

Regards,

Sebastian