Slightly crooked mesh and problems with periodicity
 

Since it's my first post: hello everyone! :)

I've been lurking here for quite some time, and always found an answer in the archive, but a similar problem to this problem I can't find.

I'm trying to make a periodic boundary condition and the two, what seems to be and should be identical zones (created in Workbench meshing by Match Control), don't want to match.

I think that the problem may lay in the slightly crooked mesh. I can't really explain it. I drew everything normally, an imported stp file from NX and some revolves in Design Modeller. Then after importing the mesh into FLUENT it shows after check:

Domain Extents:
x-coordinate: min (m) = -6.696252e-17, max (m) = 1.200000e+01
y-coordinate: min (m) = 0.000000e+00, max (m) = 3.000000e+00
z-coordinate: min (m) = -2.121320e+00, max (m) = 7.366217e-16

(I put in bold what shouldn't be there)
It's like the domain extends more than it should. And also the face at the beginning of this domain (velocity inlet) isn't perpendicular to the sides, and the vector, which would be perpendicular to it gets a very small y and z component.

And I think that's why I can't match the sides as periodic boundaries, because they are a little bit off and away from the tolerance.

Did any of you encounter a similar problem?

How can you tell that the inlet isn't perpendicular to the sides or that the mesh is crooked? Again, don't use very small y and z component as the culprit right away.

Don't worry about the e-17, it's basically the numerical way of saying 0. Show the error when you try to do the periodic boundary conditions and maybe we will have something to work with. It helps a lot for Fluent when you manually input the translation vector rather than letting it calculate automatically. Non-matching periodic meshes is nothing new, I've seen it pop up tons of times before so I encourage you to find some of them.

That's what I thought at first too, but I can't find any other reason for not matching the zones for periodic boundary condition. There is also a possibility that I'm doing sth wrong too :)

This is the error I get after trying to make periodic:

/mesh/modify-zones> make-periodic
Periodic zone [()] 10019
Shadow zone [()] 10018
Rotational periodic? (if no, translational) [yes]
Create periodic zones? [yes]

zone 10019: matched 0 out of 17894 faces.
zone 10018: matched 0 out of 17894 faces.

Error: Failed to make zones periodic.
Error Object: #f

Changing the matching-tolerance doesn't help much - I have to go way above 0.5 to start matching some faces

The default rotation axis is the x-axis. Did you build your geometry and mesh in accordance to that?

Editing my old post since I don't feel like posting another, and also since that only applies to 2D axissymmetric meshes.

Upon thinking about it more, this is probably a meshing problem. Your mesh is not properly setup to be rotationally periodic (for whatever reason) before you import it into Fluent.

What did you use to generate the mesh? And did you properly set up the matching vertices and rotation axis during the meshing process?

Yes, the whole 45 degree revolve is around the x-axis from the beginning.

Finally got it!

Turns out the axis of rotation was the problem, and fluent didn't know which way to rotate.

Default axis of rotation is z, but one can easily change it under Cell Zone Conditions -> Edit... Switching it to x solved everything and got the report:

/mesh/modify-zones> make-periodic
Periodic zone [()] 40046
Shadow zone [()] 40047
Rotational periodic? (if no, translational) [yes]
Create periodic zones? [yes]

all 17894 faces matched for zones 40046 and 40047.

zone 40047 deleted

created periodic zones.

Anyways, thanks for the help LuckyTran.

I have had plenty trouble with the rotationally periodic domain before in Fluent with the axis problem. I thought it would be back in the meshing problem since you mentioned you had a crooked mesh. Alas there is nothing wrong with the mesh as I originally suspected!

Fluent calculates the rotation angle automatically (but not the axis apparently). Ahh that does make some sense. There really is no way for it to know beforehand which axis is the rotation axis unless there is some preset default. There is a default for the 2d axisymmetric case but not 3D. I do not think this is in the user manual anywhere, good to document for myself in the Future. Anyway, glad it's working now.