Hello all,
From the documentation, it seems that PyFR itself does not itself create periodic boundary conditions (i.e. define the required connectivity) and hence such must be specified already in the mesh file.
In this regards, could folks mention how they create such boundary conditions? I have am currently using Gmsh for PyFY meshes, but its support for periodic boundaries is extremely poor.
Cheers,
Frank
Hi Frank,
I’m not sure whether Peter and his team have a solution for you on the solver side, but I’ll mention that we have worked with his team to provide native PyFR support on the meshing front in Pointwise. Creating periodic boundaries in Pointwise is much more straightforward and user-friendly. The software also supports exporting meshes created in Gmsh or PyFR’s native grid formats. If this is something that you may be interested in exploring, then feel free to contact me.
Best Regards,
Hi Frank,
You are right that in PyFR, ‘periodic’ is not a boundary condition, like in many other CFD software. Periodicity is achieved at the stage of importing the mesh while setting up the connectivity between elements.
PyFR does not directly use the periodic information in gmsh msh file.
Rather, while importing the mesh, it matches the locations of surface elements on the surfaces which are named in pairs
“periodic_n_l” with “periodic_n_r” n= 0,1,2 … and makes them as periodic.
So if you want to make a periodic mesh for a rectangular channel, for instance, you would name:
min-x plane “periodic_0_l” and
max-x plane “periodic_0_r”, and likewise
min-z plane “periodic_1_l” and
max-z plane “periodic_1_r”
I do not think it matters which is _l and which is _r.
The catch here is,
the mesh on the _l and the _r must conform with a single displacement.
the displacement, if I remember it right, must me along x or y or z-axis (not rotating, not skewed).
When you make mesh with gmsh with extrusion of a surface wuth ‘layers’, the mesh is automatically conforming on the end surfaces of the extrusion, even if the surface has an unstructured mesh. So, you can apply periodicity on those surfaces.
However, on a fully unstructured mesh, you would need to tell gmsh explicitly to set up identical mesh on the periodic surfaces. This is done by setting the appropriate flags in gmsh: http://gmsh.info/doc/texinfo/gmsh.html#Miscellaneous-mesh-commands
Yes it is painful to do in gmsh.
You will find the euler vortex (structured) and the couette flow(unstructured) examples both using periodic surfaces
Hope the above answers your question.
Regards
Arvind
Hi, Arvind or others.
As per my understanding, the two offset planes that need to be set as periodic boundary conditions should be labeled as “periodic_0_l” and “periodic_0_r” in Gmsh’s PhysicalNames. Also, I must ensure that these two offset planes are offset only along one of the X, Y, or Z axes, which I comprehend.
But I’m not sure if any other measures are required. It seems that simply placing the periodic faces into the designated named physical group should be enough to satisfy the aforementioned requirements, which doesn’t seem too complex.
In the provided couette-flow.msh file by the official source, there’s the following content.
......
$Elements
71
1 1 2 2 1 1 5
2 1 2 2 1 5 6
3 1 2 2 1 6 7
4 1 2 2 1 7 2
5 1 2 3 2 3 8
6 1 2 3 2 8 9
7 1 2 3 2 9 10
8 1 2 3 2 10 4
……
The first number represents the element number, and the second number represents the element type. And then “number-of-tags” indicates the number of integer tags that follow for the n-th element. By default, the first tag is the number of the physical entity to which the element belongs, and the second is the number of the elementary geometrical entity to which the element belongs.
Therefore, the physical entity numbers for the first 4 elements are 2, belonging to “periodic_0_l,” while elements 5 to 8 belong to “periodic_0_r.” However, I’m unsure about the significance of the subsequent geometric entity numbers. I’m uncertain whether careful setting of geometric entity numbers is necessary to satisfy the periodic boundary conditions.
I acknowledge that this might be more related to Gmsh specifics, but I’m still quite eager to know the answer to this question. Many thanks for the help from kind individuals!
Best regards.
I think this question would be best answered by the gmsh documentation or gmsh support. However, I made a super simple tool for making periodic gmsh files of a square or cube which you might like to checkout: GitHub - WillTrojak/basic_gmsh: Python scripts to make basic gmsh mesh files
I’ve read your code, and the ease of manually generating Gmsh in version 2.2 is remarkable, greatly facilitating the work for all of us.
Your code perfectly addressed my confusion. In your code, you set the geometric entity numbers in Gmsh to match the physical entity numbers, and I’m very grateful for that.
One last minor question: Is the capitalization of “periodic_0_r” important?
This is the regex line that matches the entities: https://github.com/PyFR/PyFR/blob/8edbf1878437ab43f2787b836f013f7f73a8a27f/pyfr/readers/gmsh.py#L281