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 четверг, 1 июня 2017 г., 1:36:17 UTC+4 пользователь Фрэнк Малдун написал: > > 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 > -- > Frank Herbert Muldoon, Ph.D. Mechanical Engineering > New Technologies and Service > 27 Gzhatskaya street, room 205 > Saint Petersburg > Russia, 195220 > +79313075021 (cell) > > Фрэнк Херберт Малдун, к.ф.-м.н. > Новые Технологии и Сервис > 195220 г. Санкт-Петербург > ул. Гжатская, д. 27, комната 205 > +79313075021 (мобильный) > > fmuldoo (skype) > > http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html > > -- 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.
