[Paraview-developers] VTK xml formats with external geometry references

[Mark Olesen]

Hi Andy,

This was a pleasant surprise. I'll forward the information internally to 
see if we can help with finding some sponsorship. I also liked Berk's idea.

Cheers,
/mark

On 02/19/18 16:26, Andy Bauer wrote:
> Hi Mark,
> 
> I would think that this is doable without an extreme amount of effort. 
> This wouldn't be needed for image data or rectilinear grids since the 
> grid information in them is tiny compared to the field information. It 
> could definitely be useful for polydata, unstructured grids and maybe 
> even structured grids. I think the main thing in order to get this done 
> would be to find a champion and/or funding source for the work. In the 
> next couple of months we'll be starting work on a reader framework that 
> this may fit nicely into but I'll have to get deeper into that work to see.
> 
> Best,
> Andy
> 
> On Wed, Jan 24, 2018 at 3:38 PM, Mark Olesen <Mark.Olesen at esi-group.com 
> <mailto:Mark.Olesen at esi-group.com>> wrote:
> 
>     I realize this discussion pops up at regular intervals, but I
>     haven't seen it for a while and I have some use cases that would
>     really need it.
> 
>     Seeing that there are multiblock and parallel VTK file formats such
>     as .vtm, .pvtp, .pvtu serving as collections for externally defined
>     data, I was wondering if it would be feasible to use a similar idea
>     to hold the geometry separate from the cell/point data?
>     AFAIK this isn't really something that the normal (eg, vtp, vtu)
>     formats support, but something that would really help me.
> 
>     A fairly common situation is sampling to predefined surface that is
>     reused for different times and for different fields. At the moment I
>     have the choice of writing geometry+data for each sampled field at
>     each time value. This can lead to fairly excessive disk usage.
> 
>     To avoid this duplicate geometry, I would need a complete
>     (non-trivial) rewrite of my sampling. But even after that I would
>     still have geometry duplication if the geometry is not changing in
>     time. I also lose the ability to easily remove unneeded fields a
>     posteriori.
> 
>     The desired meta-format might look like this:
> 
>     <VTKFile type="XXXUnstructuredGrid"...>
>        <XXXUnstructuredGrid>
>          <Piece file="abc.vtu" NumberOfPoints="1000" NumberOfCells="10">
>            <CellData Name="p" format="file" file="abc_p.dvtu"/>
>            <CellData Name="T" format="file" file="abc_T.dvtu"/>
>            <CellData Name="conc0" format="file" file="abc_scalar.dvtu"/>
>            <CellData Name="conc1" format="file" file="abc_scalar.dvtu"/>
>            <CellData Name="conc2" format="file" file="abc_scalar.dvtu"/>
>            <CellData Name="conc3" format="file" file="abc_scalar.dvtu"/>
>          </Piece>
>        </XXXUnstructuredGrid>
>     </VTKFile>
> 
>     This is somewhat like a pvtu file, but with the geometry and data
>     being able to reside in separate files.
> 
>     The "abc.vtu" base geometry is just a regular VTU file with or
>     without an fields.
> 
>     The "abc_T.dvtu" (dvtu for a data vtu) has data but no geometry. For
>     sanity checks it should have the basic sizing information
>     (NumberOfPoints, NumberOfCells). To be thoroughly redundant, I guess
>     a geometry file could also be specifically named in the respective
>     dvtu file.
> 
>     Is there any thing within the current framework that could be easily
>     leveraged to solve such a problem, and is such a way that it
>     eventually be part of the VTK file-format collections. Is there
>     actually a VTK format that already fits the bill and I just haven't
>     found it?
>     I know that the EnSight format covers many of these points, but a
>     pure VTK solution is what I'm looking for since it would be
>     important to have parallel file format output as per
>     PUnstructuredGrid etc.
> 
>     Cheers,
>     /mark
>     _______________________________________________
>     Powered by www.kitware.com <http://www.kitware.com>
> 
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
> 
>     Search the list archives at:
>     http://markmail.org/search/?q=Paraview-developers
>     <http://markmail.org/search/?q=Paraview-developers>
> 
>     Follow this link to subscribe/unsubscribe:
>     https://paraview.org/mailman/listinfo/paraview-developers
>     <https://paraview.org/mailman/listinfo/paraview-developers>
> 
> 

-- 
Dr Mark OLESEN
Principal Engineer, ESI-OpenCFD
ESI GmbH | Einsteinring 24 | 85609 Munich | GERMANY
Mob. +49 171 9710 149
www.openfoam.com | www.esi-group.com | mark.olesen at esi-group.com