<div dir="ltr">I suggest taking a look at the vtkFileSeriesReader class. Make sure that you look at master not an older version. That should provide a good starting point.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 19, 2018 at 12:42 PM, Mark Olesen <span dir="ltr"><<a href="mailto:Mark.Olesen@esi-group.com" target="_blank">Mark.Olesen@esi-group.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Berk,<br>
<br>
If we can split up geometry/fields etc with a FileSeries, that sounds highly attractive. A json metafile would be a very convenient way of gluing everything together without reinventing the wheel.<br>
<br>
Cheers,<br>
/mark<span class=""><br>
<br>
On 02/19/18 17:00, Berk Geveci wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Hi Mark,<br>
<br>
Depending on how much code you want to write and what you want to do with files, this is doable.<br>
<br>
0. For unstructured grids, the Exodus format supports this out of box.<br>
<br>
1. The simplest solution past Exodus would probably be to write some simple Python reader that manages arrays from various files. This could easily support any format. You would simple have some files that have geometry, others that have arrays...<br>
<br>
2. If you want a single file, the .vtx formats actually support time with the option of some arrays not changing over time. At least partially. This was done a long time ago and would have to be update to the new time support. I can provide some guidance if necessary. I am not sure if it would work with the .pvtx<br>
<br>
3. If you want multiple files, the pvd reader can be updated to support this. Someone had done this years ago but their changes never made into upstream.<br>
<br>
4. The FileSeries reader now supports a json based metafile. That reader can be update to do this as well. It is probably an easier piece of code than the pvd one and it would work with other formats.<br>
<br>
<br>
<br></span><div><div class="h5">
On Wed, Jan 24, 2018 at 3:38 PM, Mark Olesen <<a href="mailto:Mark.Olesen@esi-group.com" target="_blank">Mark.Olesen@esi-group.com</a> <mailto:<a href="mailto:Mark.Olesen@esi-group.com" target="_blank">Mark.Olesen@esi-group.<wbr>com</a>>> wrote:<br>
<br>
I realize this discussion pops up at regular intervals, but I<br>
haven't seen it for a while and I have some use cases that would<br>
really need it.<br>
<br>
Seeing that there are multiblock and parallel VTK file formats such<br>
as .vtm, .pvtp, .pvtu serving as collections for externally defined<br>
data, I was wondering if it would be feasible to use a similar idea<br>
to hold the geometry separate from the cell/point data?<br>
AFAIK this isn't really something that the normal (eg, vtp, vtu)<br>
formats support, but something that would really help me.<br>
<br>
A fairly common situation is sampling to predefined surface that is<br>
reused for different times and for different fields. At the moment I<br>
have the choice of writing geometry+data for each sampled field at<br>
each time value. This can lead to fairly excessive disk usage.<br>
<br>
To avoid this duplicate geometry, I would need a complete<br>
(non-trivial) rewrite of my sampling. But even after that I would<br>
still have geometry duplication if the geometry is not changing in<br>
time. I also lose the ability to easily remove unneeded fields a<br>
posteriori.<br>
<br>
The desired meta-format might look like this:<br>
<br>
<VTKFile type="XXXUnstructuredGrid"...><br>
<XXXUnstructuredGrid><br>
<Piece file="abc.vtu" NumberOfPoints="1000" NumberOfCells="10"><br>
<CellData Name="p" format="file" file="abc_p.dvtu"/><br>
<CellData Name="T" format="file" file="abc_T.dvtu"/><br>
<CellData Name="conc0" format="file" file="abc_scalar.dvtu"/><br>
<CellData Name="conc1" format="file" file="abc_scalar.dvtu"/><br>
<CellData Name="conc2" format="file" file="abc_scalar.dvtu"/><br>
<CellData Name="conc3" format="file" file="abc_scalar.dvtu"/><br>
</Piece><br>
</XXXUnstructuredGrid><br>
</VTKFile><br>
<br>
This is somewhat like a pvtu file, but with the geometry and data<br>
being able to reside in separate files.<br>
<br>
The "abc.vtu" base geometry is just a regular VTU file with or<br>
without an fields.<br>
<br>
The "abc_T.dvtu" (dvtu for a data vtu) has data but no geometry. For<br>
sanity checks it should have the basic sizing information<br>
(NumberOfPoints, NumberOfCells). To be thoroughly redundant, I guess<br>
a geometry file could also be specifically named in the respective<br>
dvtu file.<br>
<br>
Is there any thing within the current framework that could be easily<br>
leveraged to solve such a problem, and is such a way that it<br>
eventually be part of the VTK file-format collections. Is there<br>
actually a VTK format that already fits the bill and I just haven't<br>
found it?<br>
I know that the EnSight format covers many of these points, but a<br>
pure VTK solution is what I'm looking for since it would be<br>
important to have parallel file format output as per<br>
PUnstructuredGrid etc.<br>
<br>
Cheers,<br>
/mark<br>
______________________________<wbr>_________________<br></div></div>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a> <<a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a>><span class=""><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<<a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/openso<wbr>urce/opensource.html</a>><br>
<br>
Search the list archives at:<br>
<a href="http://markmail.org/search/?q=Paraview-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>Paraview-developers</a><br>
<<a href="http://markmail.org/search/?q=Paraview-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q<wbr>=Paraview-developers</a>><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://paraview.org/mailman/listinfo/paraview-developers" rel="noreferrer" target="_blank">https://paraview.org/mailman/l<wbr>istinfo/paraview-developers</a><br></span>
<<a href="https://paraview.org/mailman/listinfo/paraview-developers" rel="noreferrer" target="_blank">https://paraview.org/mailman/<wbr>listinfo/paraview-developers</a>><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Dr Mark OLESEN<br>
Principal Engineer, ESI-OpenCFD<br>
ESI GmbH | Einsteinring 24 | 85609 Munich | GERMANY<br>
Mob. <a href="tel:%2B49%20171%209710%20149" value="+491719710149" target="_blank">+49 171 9710 149</a><br>
<a href="http://www.openfoam.com" rel="noreferrer" target="_blank">www.openfoam.com</a> | <a href="http://www.esi-group.com" rel="noreferrer" target="_blank">www.esi-group.com</a> | <a href="mailto:mark.olesen@esi-group.com" target="_blank">mark.olesen@esi-group.com</a><br>
</div></div></blockquote></div><br></div>