Hi Freddie, Many thanks for the clarification. I think I understand the difficulties, even though I am not working with curved elements for the time being. Nevertheless, I guess I will have to live with this and use the repartition into linear elements as an OK approach for the moment.
BTW, I am having trouble getting from the .VTU files the boundary elements to do post-processing. I have checked with Paraview and it seems there is no information about them inside. I would have expected to be able to get them from the "Physical tags" provided in the GMSH file. Any advice on this? Regards, Eduardo On Thursday, November 15, 2018 at 9:17:31 AM UTC, Freddie Witherden wrote: > > Hi Eduardo, > > On 14/11/2018 15:28, Eduardo Ramos Fernandez wrote: > > Thanks for your reply. I am really interested in this since for large > > meshes become unfeasible to subdivide into linear elements to do the > > post-processing. I think the best thing would be to include this > > functionality in "pyfr export" and export the polynomials information > > local to each cell to the VTU file with -d 1. This is desirable because > > working with the HDF5 format can be really slow to query for spatially > > dependent data, and in that respect , VTK provides space partitioners > > which are very useful to map coordinates to cells efficiently. I am > > willing to work on this and contribute to the project if you point me to > > the right place to look and if you provide me detailed information on > > how polynomial information is encoded in the HDF5 file and how can I > > reconstruct them. I think this is a valuable feature to have and I have > > seen at least another message in the mailing list related to this > > problem [1]. > > So things are a little bit more subtle than this. Specifically, PyFR > permits elements to be curved. Such elements are typically employed in > the vicinity of boundary layers. A consequence of this is that a -d 1 > subdivision does not necessarily constitute an accurate representation > of the geometry. > > This greatly complicates the task of finding what element a given point > (x, y, z) is in. Further, even once this has been determined some > additional work is required in order to determine the corresponding > location within the reference element (p,q,r) at which to evaluate the > solution polynomial. > > In this sense subdivision remains a very good means of bypassing all of > these issues whilst simultaneously enabling one to use traditional > post-processing libraries which are designed for linear elements. > > Although pyfr export is relatively slow (in the grand scheme of things) > this does not necessarily need to be the case. In the past we have > written plugins which perform the subdivision extremely efficiently (and > in parallel) without having to write anything to disk. The resulting > in-memory structures can then be passed to VTK or VTK-m for processing. > > Regards, Freddie. > -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
