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

Andy Bauer andy.bauer at kitware.com
Mon Feb 19 10:26:18 EST 2018


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>
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
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=
> Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> https://paraview.org/mailman/listinfo/paraview-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview-developers/attachments/20180219/84a745a3/attachment.html>


More information about the Paraview-developers mailing list