rotor/stator interface joining cs_user_turbomachinery.c

[vgm567]

Hi

I am running a simulation on one stage of a cavity transfer mixer model using Code saturne V3.2.2 It is essentially a very similar setup to Taylor-Couette flow with hemispherical cavities on either side of the annulus serving as rotor and stator vanes.

I am using the cs_user_turbomachinery.c file to specify the criteria for rotation. The problem I am having is with joining of the rotor and stator interfaces. After the joining operation some parts of the interface remain as boundary face. I am attaching the postprocessing output along with the log files and the meshes (med format). I visualised the joining.case file and it looks like parts of the interfaces that remain boundary face coincide with those with Open cycle error.

I am unsure whether the issue is with my mesh or it can be fixed by the correct joining parameters.

Thanks for your help

Michael

[Yvan Fournier]

Hello,

I just checked your mesh, and can "explain" the joining issues.

In general, joining uses a tolerance which is proportional to the shortest edge connected to a joined edge (so as to avoid "entangling" cells, or turning them inside-out). So having highly stretched cells near a joining boundary is bad, at least if that boundary is not perfectly planar. The theory guide has a few more details and sketches explaining how the joining works, which should clarify this (search for "joining" in the PDF.

As your mesh "almost" joins correctly, you may try increasing your "fraction" parameter from 0.1 (default) to 0.2 and see if that works. If it is not enough, defining the joining using user subroutines (cs_user_turbomachinery.c, with advanced joining parameters from cs_user_mesh.c may help.

But my main recommendation would be to improve the aspect ratio of your cells in your mesh: either reduce the radial refinement , increase the non-radial refinement, or a mix of both.

Regards,

Yvan

[vgm567]

Hello,

Hope you can help me further with the mesh joining for my rotor/stator study. I am sending my meshes (in Salome med format) and the output from a Mesh preprocesser run (v 3.2.5 using GUI xml file 'joining'). I am using cs_user_mesh.c to test the joining parameters for the rotor_interface/stator_interface. I have tried several values for 'fraction' and 'plane' parameters as well as changing some advanced joining parameters values.
I am using unstructured mesh with prism layers (i am keeping the radial refinement to just 4 prism layers). Please let me know if this mesh setup is satisfactory to obtain mesh joining.

I hope you can help in choosing the right parameters for obtaining a complete joining of the rotor_interface with stator_interface faces.

The mesh is very large so I am sharing via Dropbox (hope this is ok)
https://www.dropbox.com/s/lk0tkoexxlpew ... ar.gz?dl=0
https://www.dropbox.com/s/elcyq6hee6ws3 ... ar.gz?dl=0


Many thanks,

Michael

[Yvan Fournier]

Hello,

I downloaded your files, but I'll probably not have time to look at them in detail before the end of the week. I'll keep you updated.

Regards,

Yvan

[vgm567]

Hello Yvan,

Thanks for your reply. I hope you had a chance to look at my mesh.

Regards,
Michael

[Yvan Fournier]

Hello,

I did not find anything obviously wrong with your mesh so far, but as cells are very thin in the joining area, it is difficult to zoom on the zones where issues can be seen.

To further analyze you mesh, a solution would probably be (before joining) to cut just a small piece of the mesh (both rotor and stator), either with SALOME, or generating a secondary output (using a writer to the MED format and an auxiliary postprocessing submeshes selected using a small "box"), so as to zoom an that area, try to join it, and proceed from there.

You can try that on your side, or if you are not comfortable with this, I can try it near the end of the week.

Regards,

Yvan

[Yvan Fournier]

Hello,

I looked a bit more at your mesh, and zoomed on an extracted part. It seems the meshes are "interlocked", as can be seen using a mesh quality check or preprocessing on the unjoined mesh, then using the "extract blocks" filter in ParaView on the boundary groups output, then the "block id" filter, and coloring by block ids.

To work around this, having a small gap between you meshes may help (so you joining always "pulls" in the same direction), though I am not sure if the local cell size variation between joinings may cause issues.

A better solution is to reduce the cell aspect ratio near the joined areas, which means refining your mesh in the tangential directions (an unfortunately increasing its size).

If all else fails, the older, coupling/interpolation-based rotor-stator model should work here.

Regards,

Yvan

[vgm567]

Thank you very much Yvan for your response.
I have been able to successfully run CS_TURBOMACHINERY_TRANSIENT simulations by only having one prism layer on either side of the rotor_interface/stator_interface. Refining the cells tangentially unfortunately did not help with the mesh joining issues.

Now I would like to run CS_TURBOMACHINERY_FROZEN simulation. If I understand correctly this peforms a mesh joining step at the very beginning only? In addition I will have to set icorio=1 and specify omegay also in cs_user_parameter?

Is it possible to run a Frozen rotor simulation without requiring any mesh joining? This could allow me to experiment with mesh refinement in the annulus part of my geometry (and have just one combined mesh as input).

Thanks again for your time and help

Regards

Michael

[Yvan Fournier]

Hello,

I am not sure of all the answers:

Yes, the frozen rotor mode only requires one mesh joining in the beginning, as the mesh is fixed.

I believe you can run it without any mesh joining, on a mesh which is all in one piece (in which case, if it complains about missing joining parameters, just set the selection criteria to none[]).

I am less sure about icorio and omegay, but using the turbomachinery definition, I do not believe you need to set them (you only need them for the coupling-based option which already existed in versions 3.0).

Regards,

Yvan