Hello all,
I have been working with a developer at Tecplot concerning development
of a reader for VTU files and have provided him with a number of VTU
files generated by PyFR. He informs me that the data in these files is
missing connectivity information and hence each cell is an island unto
itself and is unaware of the existence of any neighbor cells. As a
result post-processing and visualization of the data is greatly
degraded. For instance construction of isosurfaces is extremely poor
(see attached picture). Could the developers comment on this issue?
Cheers,
Frank
Hi Frank,
I have been working with a developer at Tecplot concerning development
of a reader for VTU files and have provided him with a number of VTU
files generated by PyFR. He informs me that the data in these files is
missing connectivity information and hence each cell is an island unto
itself and is unaware of the existence of any neighbor cells. As a
result post-processing and visualization of the data is greatly
degraded. For instance construction of isosurfaces is extremely poor
(see attached picture). Could the developers comment on this issue?
PyFR does not include connectivity information inside of our VTU files. This is partly a consequence of the fact that our solutions are inherently discontinuous; at certain points in space we can have multiple solution values from adjoining elements.
The need for connectivity information appears to be a Tecplot related quirk. ParaView has no trouble with processing the VTU files without any connectivity information (and, can to an extent reconstruct it if needed using the clean to grid filter).
Regards, Freddie.
Hello Freddie,
I apologize for only now replying. With all due respect I believe that the approach where PyFR does not output connectivity information to be a mistaken one. PyFR is capable of generating very accurate data, however, for the accuracy of this data to be fully taken advantage of, the connectivity information is very important. One example concerns the calculation of derivatives. It is possible of course, that a given visualization program may generate on its own what it thinks the connectivity information should be, however, leaving this task to the visualization or other post processing program has important downsides. The first is that the connectivity information thereby created may not be that which is used by PyFR and hence interpretation of the data maybe incorrect and/or inaccurate, the second concerns efficiency in that recreation of connectivity information has a cost (likely significant), whereas PyFR already has that information at hand. This last issue is very important when post processing the large amounts of data arising from DNS/LES.
The issue of non-unique solutions at certain points it seems could be addressed by minimizing the difference between the different solutions at this point and some higher order polynomial. At the end of the day, further post-processing and analysis generally does require a unique solution and it seems logical that PyFR aids the user in obtaining this in the most accurate manner possible.
Cheers,
Frank
