A question about the pyfrm data structure: import mesh files

General
1

Dear all,

My name is Antonio Garcia-Uceda, and I’m a researcher on Flux Reconstruction methods. I’m using pyFR as part of my project.

I’m digging a bit into the pyFR data structure. Concerning the import of mesh files, I’ve noticed that pyFR creates, for each boundary patch, a list of tuples of four elements of the form: (b'elem_type', idCell, ???, n-part) I can’t figure out the meaning of the third element. Could you please let me know this?

Also, pyFR create another list of tuples of the same form, with the header con_npart What does this section refer to?

Finally, Could you please spot the place where pyFR works out the connections between periodic boundary patches?

Thanks a lot in advance.

Best regards,
Antonio

2

Hi Antonio,

I'm digging a bit into the pyFR data structure. Concerning the
import of mesh files, I've noticed that pyFR creates, for each
boundary patch, a list of tuples of four elements of the form:
*(b'elem_type', idCell, ???, n-part). *I can't figure out the
meaning of the third element. Could you please let me know this?

The form of the tuple is (ele-type, ele-num, face-num, flags). The
final element, flags, is unused and set to 0.

Also, pyFR create another list of tuples of the same form, with
the header *'con_npart'. *What does this section refer to?

This encodes interior connectivity --- including periodic connectivity.

Finally, Could you please spot the place where pyFR works out the
connections between periodic boundary patches?

This is never done by PyFR. Periodic connectivity is encoded in the
con arrays and so is never computed directly. It is all done during
the mesh generation phase.

Regards, Freddie.

3

Dear Arvin,

Thanks for your reply. You’re right, I thought it was a list of cells, but it’s instead a list of faces (of cells).

I think your reply also answers my second question: The section ‘con_npart’ is a list of interior faces (of cells again) with both left and right cells (or faces of cells), right?

Thanks a lot for your reply

Best regards,

Antonio

4

Dear Freddie,

Thanks a lot for your reply.

I also noticed that pyFR does not support Serendipity type elements. Is this right? If so, Is there any reason for this too?

Thanks again in advance

Best regards,
Antonio

5

Hi Antonio,

No reason beyond the fact that no one has implemented them yet.
However, as the Lagrange type elements we support are a superset of
serendipity elements (just extra control nodes in the interior) it
should not be too difficult to convert a serendipity mesh into a
Lagrange mesh.

Regards, Freddie.

6

True. Thanks a lot for your reply.

Best regards,
Antonio