code_saturne User's Forum

Hello,

Just a minor (but important) precision if you are new to the code:

When I talked about adjusting the time step, I meant the time step value, that is dt, and not the number (nt max). The value must be chosen for a reasonable CFL range, and the CFL (ou Courant number) will appear in your listing file (and also in the visualizable postprocessing output). Once the time step value is chose, you then need to run sufficient time steps for a "converged" solution. Checking probes is useful at that point, and a good rule of thumb is to run enough time steps that the mean flow has been convected twice through the domain.

Regarding mesh joining in the same domain, with version 3.2.1, could you post the detailed error log ? This will help me know if it is an error or just a warning. Also, an image of a part of your mesh (zoomed in near the rotor/stator junction) may help us judge "quality" and provide furtger recommendations.

Regards,

Yvan

Hello Yvan,

i attached two pictures of the meshes as well as error.log and listing file for the mesh joining. In Addition i attached a screenshot of the time step section in the GUI. What do i have to change here in order to get a reasonable CFL range?

... and the rest.

Regards,

Sebastian

Hello,

In the listing, you have a warning because reference velocity uref is not defined. This does not explain the joining issue, but will need to be defined later.

Could you try to run in serial mode (only one processor), to see if you have the same joining issue ? We recently fixed a bug in parallel mesh joining, which impacted mainly meshes with tetrahedra or prisms near the joining boundary, and which was partitioning dependent. I hope the bug is completely squashed, but am not 100% sure, so this is an easy test. If the joining works on 1 proc, it means we do still have an issue, in which case I would be interested if you could post your mesh and case setup (if it is small), or a link to your mesh (if it is large). If your mesh is confidential, you can send the info as a private message, or to saturne-support at edf.fr (note I won't have access to that mailbox between tomorrow and Jan 2).

In more general terms, I would strongly suggest adding a layer of prisms at the rotor/stator interfaces (not to thin like a boundary layer; just the same thickness as neigboring cells, but more "regular" than tetrahedra).

Also, on the views of you mesh, tetrahedra on one side (near the left) seem very flat. Code_Saturne is not too fond of that, whether near a joining or near a boundary, so simply avoiding too flat tetrahedra in that area might solve your issues.

Regards,

Yvan

Hello Yvan,

thank you for having a look to the files. I apologize for a really stupid mistake that I did. When I performed sat/sat coupling i deleted the boundary faces in the boundary region definition section of the GUI. This was no problem, because the subroutine had a higher priority. In mesh joining I did the same. This was the problem. I´m so sorry.

I chose “Symmetry” for the coupled_boundary and then it worked for both 1 and 4 processors.

So, everything is fine with your code

Having a look to the listing file I observed the following warning:

*** WARNING *** Globally, 22 problem(s) found during the face splitting
0 open cycles,
22 edges traversed twice,
0 faces split into more than max_subfaces (= 200)

=> Eventually modify joining parameters

Is that a problem?

And I have questions related to cs_user_turbomachinery.c: First of all, which rotor/stator model would you use:

CS_TURBOMACHINERY_NONE, No turbomachinery modeling
CS_TURBOMACHINERY_FROZEN, Frozen rotor model
CS_TURBOMACHINERY_TRANSIENT Full transient simulation (I would choose this, but i´m not sure)

For a rotation of 2500 rpm and the z-axis as rotation axis I did the following:

/* Define rotor axis and cells, with rotor/stator interface face joining */ /* --------------------------------------------------------------------- */
if (true) {

/* Define cells belonging to rotor and associated axis */

double rotation_velocity = 2500.; (or 261.799 rad/s?)
double rotation_axis[3] = {0., 0., 1.}; (for z-axis?)

Here, I don`t know what to do.

const char cell_criteria[] = "cylinder[0.0, 0.0, 0.0,"
" 0.0, 0.0, 1.0,"
" 2.0]";
cs_turbomachinery_add_rotor(cell_criteria,
rotation_velocity,
rotation_axis);

/* Define joining associated with rotor/stator interface */

const char faces_criteria[] = "coupled_boundary";

int verbosity = 1; /* per-task dump if > 1, debug level if >= 3 */

int visualization = 1; /* debug level if >= 3 */

float fraction = 0.10, plane = 25.;

int join_num = cs_turbomachinery_join_add(faces_criteria,
fraction,
plane,
verbosity,
visualization);

/* Note that advanced parameters may be defined using cs_join_set_advanced_param(), just as for regular joinings or periodicities. */

} } /*----------------------------------------------------------------------------*/

END_C_DECLS


Is there any example that exists for turbomachinery? I could not find one in the “EXAMPLES” folder.


I attached the listing file for the single domain using non-conforming mesh joining and no rotation.

Thank you very much for your support.

Regards,

Sebastian

Hello Yvan,

i`ve sent you a private message related to mesh joining as you mentioned in your previous post.

Regards,

Sebastian

Hello Yvan,

as already mentioned in my pm i`ve attached the listing file for the turbomachinery case. Computation was successful, but nothing has been joined or does rotate. Do i have to set rotation velocity in rad/s?

Regards,

Sebastian

Hello,

Could you also post the full "Calc" parameters file and cs_user_turbomachinery.c file (and any other user subroutines) ? I already have your mesh, so I'll try to test this on my machine.

Regards,

Yvan

Hello,

yes, of course. Attached you can find the files.

Thank you. Regards,

Sebastian

Hello,

I downloaded the files, but won't have time to look at them before a few days
(I believe I finally have a robust fix for the joining bug, but expect it will take about a half-day to code and test it, and I really want to get rid of that first; and I don't plan on spending more than a few hours on the code during the holidays).

I'll update this post when I get to that.

Regards,

Yvan