[Paraview] Any performance hints or tips for .pvtr reader?
Berk Geveci
berk.geveci at kitware.com
Thu Jul 9 09:50:09 EDT 2009
> Yes, well, that's a separate issue that I'm having; I can reliably kill
> paraview dead by trying to `Save Data', either immediately after the pvtr
> data has been read as cell data or after converting it to point data. If I
> just try to save smaller data sets resulting from the visualization process
> (eg, generated contours) I have no problems with that. There's nothing
> obviously weird about the data set, as I have no issues plotting or
> manipulating the data. This was true with PV 3.4 and with a current (eg,
> this morning) cvs build.
Can you reproduce this will smaller datasets on fewer processors? I
wonder if it is bug that causes some memory problem. We should track
it down.
-berk
On Mon, Jun 29, 2009 at 12:17 PM, Jonathan
Dursi<ljdursi at scinet.utoronto.ca> wrote:
> Moreland, Kenneth wrote:
>
>> That is, organize the data so that each process only has to
>> do one read from a single file. The easiest way to do that is to read
>> in your data into ParaView or VTK on 64 processes as you are doing now
>
> Still easier when possible is to run the viz task on 192 cores, matching one
> file per core; I've done that and performance improves but not enormously.
> It's an inconvenience, but I just wanted to know if there was anything in
> particular I needed to be aware of.
>
>> (pay the time price) and then write it back out in a new .pvtr file.
>> The new .pvtr file should contain 64 .vtr files. Loading that back
>> onto 64 processes should be quick.
>
> Yes, well, that's a separate issue that I'm having; I can reliably kill
> paraview dead by trying to `Save Data', either immediately after the pvtr
> data has been read as cell data or after converting it to point data. If I
> just try to save smaller data sets resulting from the visualization process
> (eg, generated contours) I have no problems with that. There's nothing
> obviously weird about the data set, as I have no issues plotting or
> manipulating the data. This was true with PV 3.4 and with a current (eg,
> this morning) cvs build.
>
> - Jonathan
>
> --
> Jonathan Dursi <ljdursi at scinet.utoronto.ca>
> _______________________________________________
> 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
>
More information about the ParaView
mailing list