[Paraview] Parallel ParaView- file formats and Chromium

Berk Geveci berk.geveci at kitware.com
Tue, 16 Mar 2004 12:05:20 -0500


> 1) Can someone send an example of an XML file which will cause ParaView to 
> read data in parallel across several processors?  For example, if I have 4 
> blocks of data and 4 PEs, I gather I need to produce a .pvd or .pvti file from 
> my 4 individual .vti files.  The only example I can find contains a reference 
> to only 1 .vti file and my attempts to generalize it seem to be failing.

The easiest way of producing an example is to run paraview on 4 procs,
create a source of the type you want (for example, wavelet for images)
and save a .pvt* or .pvd file. 
IMPORTANT NOTE: There is an issue with the way structured data is
divided in ParaView (actually, in VTK). It is not possible to load n
disjoint blocks in parallel such that each block is on one processor.
The boxes have to be parts of a larger structured data whose "whole"
extent is given in the .pvt* file. For example:

  <PImageData WholeExtent="-10 10 -10 10 -10 10" GhostLevel="0"
Origin="0 0 0" S
pacing="1 1 1">
    <PPointData Scalars="RTData">
      <PDataArray type="Float32" Name="RTData"/>
      <PDataArray type="UInt8" Name="vtkGhostLevels"/>
    </PPointData>
    <Piece Extent="-10 10 -10 10 -10 0" Source="test_0_0.vti"/>
    <Piece Extent="-10 10 -10 10 0 10" Source="test_0_1.vti"/>
  </PImageData>

In this case, the two pieces put together HAVE to fill the whole extent.
If you want to load 4 completely disjoint boxes, you have to point to
each file from a .pvd file like so:

  <Collection>
    <DataSet part="0" file="mb/mb_0.vts"/>
    <DataSet part="1" file="mb/mb_1.vts"/>
    <DataSet part="2" file="mb/mb_2.vts"/>
    <DataSet part="3" file="mb/mb_3.vts"/>
    <DataSet part="4" file="mb/mb_4.vts"/>
  </Collection>

In this case, every dataset in the collection will be automatically
broken to n pieces (where n is the number of procs) and each processor
will work on 1/nth of each piece.


> 2) The documentation (1.2.1) stresses that if the DISPLAY environment variable 
> is set for all processes, the several workers will all open windows on the 
> display, causing problems for the rank 0 worker that is supposed to be 
> handling the UI.  Experimentally this doesn't seem to happen- I only get one 
> window.  Has the problem with multiple access to the DISPLAY been fixed?

Not really. What is happening is this: There is a threshold (given in
terms of the size of the polygonal data displayed - note that this is
not the datasize, the size of the polygonal data produced by a filter,
for example, in case of image data, this will be the outline, which is
12 lines, which is tiny) below which all the polygonal data is collected
to the first process (or client) and rendered locally. There is a slider
labeled "Composite Threshold" in the 3D view settings. Try adjust that
to force paraview to composite.

> 3) The default configuration seems to be for each worker to use Mesa to do its 
> own rendering (presumably off-screen), and then to read back the image.  The 
> images are then composited by ParaView itself.  We'd like to use Chromium, and 
> to let Chromium do the compositing.  I *guess* all that's really needed is to 
> keep ParaView from trying to do the compositing.  How does one set this up?

The default configuration uses hardware accelerated on-screen rendering.
You have to compile with Mesa OS support (and probably mangled mesa if
you want hardware acceleration AND off-screen rendering) for off-screen.
Currently, there is no Chromium support for compositing.

> 
> Thanks, I hope;
> -Joel
>  welling at psc.edu
> 
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview