Coupling in code_saturne
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
Re: Coupling in code_saturne
Hi Yvan,
I sent you a PM.
Now i switch to version 3.2.2 and I'm trying to use the full transient simulation for rotor-stator mixer and it diverge from first time step (just when I switch form Frozen to transient turbo machinery)
I attached source file and listing file for both cases.
Thanks
I sent you a PM.
Now i switch to version 3.2.2 and I'm trying to use the full transient simulation for rotor-stator mixer and it diverge from first time step (just when I switch form Frozen to transient turbo machinery)
I attached source file and listing file for both cases.
Thanks
Re: Coupling in code_saturne
This is the attached files again
- Attachments
-
- Mixer.tar.gz
- (6.25 MiB) Downloaded 265 times
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Coupling in code_saturne
Hello,
Several things are strange, or wrong, in your setup :
- in the frozen rotor case, your CFL is a bit hight (mean over 10, max over 100). If you are using the same time step for the transient case, reducing your time step by a factor of 2 to 5 would be safer.
- At least for testing, using a verbosity of 1 instead of 0 for the turbmachinery joining may help see how the joining is going.
- No need to put names of boundary face groups such as rotor1_wall in the rotor cell criteria (not a cause for the crash, but confuses those checking your setup...)
- the iterative vector gradient reconstruction does not converge in 100 iterations. This is a sign of a "not so great" mesh quality.
- There is also an "Abort due to the detection of a negative control volume." message. The code should abort, but does not do so in turbomachinery case (the abort only happens before the time loop; we have to fix this). This also equates to a bad mesh. In any case, a negative control volume can lead to other inconsistent values, so I wouldn't expect the code not to crash from there...
Since there is no image of your mesh, it's hard to tell where to improve it, but with this turbomachinery mode, you need to ensure the mesh is as regular as possible near the rotor/stator mesh junctions. Using at least one layer of extruded cells for this is often a good recipe for this (similar to prismatic viscous layers, but not too refined, and especially not with increased refinement).
Regards,
Yvan
Several things are strange, or wrong, in your setup :
- in the frozen rotor case, your CFL is a bit hight (mean over 10, max over 100). If you are using the same time step for the transient case, reducing your time step by a factor of 2 to 5 would be safer.
- At least for testing, using a verbosity of 1 instead of 0 for the turbmachinery joining may help see how the joining is going.
- No need to put names of boundary face groups such as rotor1_wall in the rotor cell criteria (not a cause for the crash, but confuses those checking your setup...)
- the iterative vector gradient reconstruction does not converge in 100 iterations. This is a sign of a "not so great" mesh quality.
- There is also an "Abort due to the detection of a negative control volume." message. The code should abort, but does not do so in turbomachinery case (the abort only happens before the time loop; we have to fix this). This also equates to a bad mesh. In any case, a negative control volume can lead to other inconsistent values, so I wouldn't expect the code not to crash from there...
Since there is no image of your mesh, it's hard to tell where to improve it, but with this turbomachinery mode, you need to ensure the mesh is as regular as possible near the rotor/stator mesh junctions. Using at least one layer of extruded cells for this is often a good recipe for this (similar to prismatic viscous layers, but not too refined, and especially not with increased refinement).
Regards,
Yvan
Re: Coupling in code_saturne
Hello Yvan,
Thanks for your comments. Yes I have change the time step and now I'm using variable time step (IDTVAR = 1), and CFL is reduced.
I set the verbosity to 1 but nothing changed.
What I should put in rotor cell criteria?, I should name the rotor cells??
But it does converge in the frozen simulation.
Thanks for your comments. Yes I have change the time step and now I'm using variable time step (IDTVAR = 1), and CFL is reduced.
I set the verbosity to 1 but nothing changed.
What I should put in rotor cell criteria?, I should name the rotor cells??
But it does converge in the frozen simulation.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Coupling in code_saturne
Hello,
It should be enough to place the rotor cells in the cell criteria. Faces only need to be either in the boundary conditions or in the face joining criteria, depending on where they are.
Verbosity should only help check in the "listing" file how the joining behaves.
You can't use idtvar=1 for transient rotor/stator computations (it's a bug if the code lets you do it). This is because of the way the position is computed (physical_time*angular_velocity, which could easily be replaced by an increment per time step), and the fact that if I remember correctly, the rotation is computed before way the time step value is predicted in dttvar.f90 (and changing this may be more risky).
You mesh looks quite nice, but I recommend using a reduced refinement near the junction, to avoid having very large and sudden cell size variations. Also, with a single color, it's hard to guess where the stator/rotor junction lies (in the middle of the refined region, on on of its sides ?).
Regards,
Yvan
It should be enough to place the rotor cells in the cell criteria. Faces only need to be either in the boundary conditions or in the face joining criteria, depending on where they are.
Verbosity should only help check in the "listing" file how the joining behaves.
You can't use idtvar=1 for transient rotor/stator computations (it's a bug if the code lets you do it). This is because of the way the position is computed (physical_time*angular_velocity, which could easily be replaced by an increment per time step), and the fact that if I remember correctly, the rotation is computed before way the time step value is predicted in dttvar.f90 (and changing this may be more risky).
You mesh looks quite nice, but I recommend using a reduced refinement near the junction, to avoid having very large and sudden cell size variations. Also, with a single color, it's hard to guess where the stator/rotor junction lies (in the middle of the refined region, on on of its sides ?).
Regards,
Yvan
Re: Coupling in code_saturne
Hello Yvan,
I have reduced the mesh refinement close to rotor, but im still getting same error.
I took two more snapshot for my mesh.
The empty spaces close to yellow mesh represent rotors and the rectangular shape close to the black mesh represent stators.
I have reduced the mesh refinement close to rotor, but im still getting same error.
I took two more snapshot for my mesh.
The empty spaces close to yellow mesh represent rotors and the rectangular shape close to the black mesh represent stators.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Coupling in code_saturne
Hello,
What is the white section ? rotor, stator, or mixed ? It still seems muhc too fine compared to the rest.
The rotor-stator functionnality in Code_Saturne assumes that boundary faces do not change, so they are not updated. In your mesh, some faces could be boundary faces in some positions, interior faces in others, and that is not currently handled.
If the white section can be split in 2, with 1/2 rotor, and 1/2 stator, with one cell thickness in each case, your calculation should run better (assuming this is indeed where rotor and stator sections meet).
Regards,
Yvan
What is the white section ? rotor, stator, or mixed ? It still seems muhc too fine compared to the rest.
The rotor-stator functionnality in Code_Saturne assumes that boundary faces do not change, so they are not updated. In your mesh, some faces could be boundary faces in some positions, interior faces in others, and that is not currently handled.
If the white section can be split in 2, with 1/2 rotor, and 1/2 stator, with one cell thickness in each case, your calculation should run better (assuming this is indeed where rotor and stator sections meet).
Regards,
Yvan
Re: Coupling in code_saturne
Hello,
The white section is the fluid gab between the rotor and stator.
I tried to run it for both frozen or rotating fluid.
The white section is the fluid gab between the rotor and stator.
I tried to run it for both frozen or rotating fluid.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Coupling in code_saturne
Hello,
It is as I guessed. So following my advice from my previous post (split the gap mesh in 2, one half assigned to rotor, the other to the stator, and coarsen it) should help.
Regards,
Yvan
It is as I guessed. So following my advice from my previous post (split the gap mesh in 2, one half assigned to rotor, the other to the stator, and coarsen it) should help.
Regards,
Yvan
Re: Coupling in code_saturne
Hello Yvan,
I have split the gap into a rotating and a frozen zone, I'm still getting the same error (high pressure residual).
I just visualise the error and compare it with original mesh (see the attached snapshots). You can clearly see something wrong at the interface cells (distorted!!) between rotating and frozen cells (the white cells as original mesh cells and the coloured one is the visualised results).
I have split the gap into a rotating and a frozen zone, I'm still getting the same error (high pressure residual).
I just visualise the error and compare it with original mesh (see the attached snapshots). You can clearly see something wrong at the interface cells (distorted!!) between rotating and frozen cells (the white cells as original mesh cells and the coloured one is the visualised results).