[Paraview] paraview & HDF5/XDMF: how to control memory usage?

[David E DeMarle]

It has to parse the entire xml file to determine the scope of the entire
data, but it should only read into memory the enabled arrays from the
enabled blocks for the current time step. If it isn't doing that you've
probably found a new bug.

Is this a dataset that you can send me so that I can take a look at it? I'm
working on the next generation xdmf reader/writer with ARL right now and
I'ld like to see if the new reader does better with your data.

cheers,

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
Hi, All.

I'm an using paraview for quite some time now, in conjunction with HDF5
and XDMF (the XMF descriptor is generated "manually", i.e. not by the
XDMF library tool)

Everything is working smoothly for small enough datasets; I have several
time steps and several quantities per time step, they all appear as desired.

Now, my question is whether I can influence the way paraview loads this
data from HDD into memory. It seems to me that not only paraview loads
all quantities of a given time step into memory, even if this is
currently unnecessary, because some quantities are not used yet. It also
tries to load data from several time steps. The latter is a big problem
for me, since right now I have to create one XMF file per time step,
load it, and so on, as opposed to just have all time steps in one XMF
file and use paraviews forward/backward buttons, if my data is too big.

Regards
Thomas
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView

Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20140609/74e66a8a/attachment.html>