[miro2000]

Hello everyone,

I'm using Gambit 2.4.6 to create mesh to simulate centrifugal pump. I successfully made mesh, but it consists of several volumes (both stator and rotor). I will simulate it using fluent 12.0.16.
Now it's becoming clear that that approach is bad, because now i have faces which define those volumes that are inside the mesh. Gambit let's me define them as "interior" boundaries.
However, since faces actually have mesh only from one side (my domain is just divided into several volumes) fluent says that those boundaries can't bee interior, and that they will be wall.
So, right now i have a centrifugal pump with a several walls which don't exist.

I used this approach so it would be easier to make good mesh. Unfortunately, i didn't take into account that volumes must share a face for this to work. Off course, I don't want to change my mesh. Help me

note that this work is part of my school assignment, and I'm not cheating, my prof. is not available right now.

Many thanks kind stranger
- miro

P.S. in one case, those faces are not identical (on both volumes) since there are three volumes.

edit: picture 6

[vasava]

Questions: What approach are you using? Dynamic mesh, sliding mesh, moving frame of reference or mixing plane method.

Also some pictures from your mesh would help us.

[miro2000]

Dear Mr Vasava,

thank you for your intrest. I see now that my description wasn't that great.

I'm using moving mesh. My domain is split in half, in which half is moving (rotor) and half is stationary. I'm simulating only 1/7th of a pump, and using periodic b.c. to compensate.

Pictures are in the attachment. I have selected stator in one picture, and problem faces in the other. Note that in that picture, one face in upper volume is split in two faces in lower volume.

I think problem with fluent happens because my volumes are defined by diferent faces that are on the same geometric position, although mesh is identical...

[-mAx-]

You don't have to define interior faces as interior.
If your splits are well done (understand volumes are connected), then gambit treat automatically internal surfaces as interior.
So delete those interior BC, and re-try
Then moving mesh is quite vague: are you using sliding mesh, remeshing, layering...? But this is another problem

[miro2000]

Dear Max,

what you are writing is correct. It seems that said faces are not connected. It seems that other faces that are not making problems are connected. Is there a way to connect them now? There is a problem of that face that's split in two, I guess it would be a problem to connect them... Also, i have hard-linked (but disabled periodic option) front and back of the pump (walls) because Cooper wouldn't work otherwise.
I really don't want to make the whole thing from scratch.

Yes, again, I didn't clarify. I'm using dynamic mesh in which the upper region (stator) is stationary and the lower region (rotor) is rotating around Z axis. I'm using interface to connect them. The interface is the lowest marked face in the picture where stator is selected.
Please ask if you have further questions regarding this.

Thank you ,
- miro

[-mAx-]

*try faces/connect/All
But it should delete one or more volume mesh.

*If you are using an interface between rotor and stator, then you are using sliding mesh (rotor mesh will move as rigid body --> no deforming mesh)

I would work step by step: compute first a steady case, to be sure that your mesh is ok (is your fluid flowing through interface for instance)
If everything is ok, switch to unsteady case, and activate dynamic mesh (rotor as rigid body with angular velocity)

[vasava]

Originally Posted by miro2000

I'm using dynamic mesh in which the upper region (stator) is stationary and the lower region (rotor) is rotating...

This sounds description of 'sliding mesh' or 'mixing plane model'. A dynamic mesh is approach where your mesh is updated every time-step. When you visualize dynamic mesh you should feel as if the impeller is moving through the mesh. See this animation http://www.youtube.com/watch?v=nWX6On8H3Mg.

[miro2000]

OK, thank you for your advice, I find them very useful, especially about steady case.

@ mr. Vasava; Yes, you are correct, I didn't describe the problem properly.

At this point it seems that the most painless solution is to modify the volumes to remove duplicate faces and make them connected. Different ideas are also welcome.

tnx,
- miro

[miro2000]

Hello again!

Well, I fixed the mesh and ran a steady simulation and everything works fine.

However, when I try to run transient, fluent says mesh has negative volumes. This makes me wanna cry, because it SHOULD work, especially because steady simulation works fine.

For some reason, mesh check fails in Fluent, but passes in Gambit. It says:

 Domain Extents:
   x-coordinate: min (m) = -1.454961e-01, max (m) = 1.034974e-01
   y-coordinate: min (m) = -4.377876e-02, max (m) = 1.960000e-01
   z-coordinate: min (m) = 0.000000e+00, max (m) = 6.000000e-02Creating empty surface. 
Warning: non-positive volumes exist.

   minimum volume (m3): -5.262027e-09
   maximum volume (m3): 2.892039e-08
     total volume (m3): 3.498354e-04
   minimum face area (m2): 3.127471e-10

 Volume statistics:
 Face area statistics:
 Checking number of nodes per cell.
 Checking number of faces per cell.
 Checking thread pointers.
 Checking number of cells per face.
 Checking face cells.
 Checking cell connectivity.
 Checking bridge faces.
 Checking right-handed cells.
 Checking face handedness.
 Checking face node order.
 Checking closed cells.
 Checking contact points.
 Checking element type consistency.
 Checking boundary types:
 Checking face pairs.
 Checking wall distance.
WARNING: The mesh contains very high aspect ratio hexahedral
         or polyhedral cells.
         The default algorithm used to compute the wall
         distance required by the turbulence models might
         produce wrong results in these cells.
         Please inspect the wall distance by displaying the
         contours of the 'Cell Wall Distance' at the
         boundaries. If you observe any irregularities we
         recommend the use of an alternative algorithm to
         correct the wall distance.
         Please select /solve/initialize/repair-wall-distance
         using the text user interface to switch to the
         alternative algorithm.
 Checking node count.
 Checking nosolve cell count.
 Checking nosolve face count.
 Checking face children.
 Checking cell children.
 Checking parent-child pointers (cell).
 Checking parent-child pointers (face).
 Checking thread consistency across compute nodes.
 Checking thread layer counts.
 Checking neighbor counts.
 Checking exterior faces.
 Checking exterior shadow faces.
 Checking interface faces.
 Checking interface nodes.
 Checking face ids.
 Checking node ids.
 Checking corner nodes.
 Checking interior cell pointers.
 Checking exterior cell pointers.
 Checking storage.
 Checking periodic boundaries.
   Periodic zone   5: average rotation angle (deg) = 48.131 (48.133 to 48.133)
                      stored zone rotation angle (deg)  = 48.133
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone   7: average rotation angle (deg) = 48.126 (48.133 to 48.133)
                      stored zone rotation angle (deg)  = 48.133
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone   9: average rotation angle (deg) = 48.133 (48.133 to 48.133)
                      stored zone rotation angle (deg)  = 48.133
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone  11: average rotation angle (deg) = 48.133 (48.133 to 48.133)
                      stored zone rotation angle (deg)  = 48.133
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone  13: average rotation angle (deg) = 51.428 (51.429 to 51.429)
                      stored zone rotation angle (deg)  = 51.429
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone  15: average rotation angle (deg) = 51.428 (51.429 to 51.429)
                      stored zone rotation angle (deg)  = 51.429
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone  17: average rotation angle (deg) = 51.545 (51.422 to 52.022)
                      stored zone rotation angle (deg)  = 51.641
                      stored axis  , (0.000000e+00, 0.000000e+00, 1.000000e+00)
                      stored origin, (0.000000e+00, 0.000000e+00, 0.000000e+00)
   Periodic zone  42: x-translation: 0.000000e+00
                      y-translation: 0.000000e+00
                      z-translation: 0.000000e+00
   Periodic zone  44: x-translation: 0.000000e+00
                      y-translation: 0.000000e+00
                      z-translation: 0.000000e+00
   Periodic zone  53: x-translation: 0.000000e+00
                      y-translation: 0.000000e+00
                      z-translation: 0.000000e+00
Done.

WARNING: Mesh check failed.

WARNING: left-handed faces detected on zone  29: 224755 right-handed,   251 left-handed.
WARNING: left-handed faces detected on zone  21:  3441 right-handed,    92 left-handed.

And has different view on mesh quality than gambit which is very happy with created mesh:

Mesh Quality:

Applying quality criteria for tetrahedra/mixed cells.
Maximum cell squish =  1.00000e+00
Warning: maximum cell squish exceeds 0.99.
Maximum cell skewness =  1.00000e+00
Warning: maximum cell skewness exceeds 0.98.
Maximum aspect ratio =  2.40857e+06

All these things aside, in case of a sliding mesh (interface), if steady simulation works, so should transient! Or? Am I wrong?
Because mesh doesn't change?

Well, anyway, thank you for your help so far,
sincerely,
- miro

P.S. I did scale the mesh in Fluent. But that also shouldn't make problems.

P.P.S. Also, fluent adds two b.c. called wall, but when I try to visualize them, there's nothing there. Also, when I import .msh into gambit again, nothing is wrong, and those b.c. don't exist...

[miro2000]

Well, it seems my time-step was a bit too big.
But other questions still remain..

Thank you,
- miro

[-mAx-]

negative cells warning sounds like you are handling dynamic mesh.
But as I said you have to work with sliding mesh, and only the rotor domain should rotate. As the rotor is not connected to stator (interface), then you shouldn't get any "dynamic" update of your mesh (but just its rotation which shouldn't generate negative cells ---> except you have negative volume already with your initial mesh)

[miro2000]

Hi,

It took me awhile, but I got it working in the end. The problem was that my interface - faces were assigned to the wrong volume. So, when the rotor region moved, it moved the interface - surface of the stator. That actually created dynamic mesh, and that's why it blew up.

There are still some questions regarding mesh check in Fluent, however, these are not important for my assignment.

Anyway, you have been a huge help,
thank you,
- miro