[Paraview-developers] RE: Pipeline 'split'
Wylie, Brian
bnwylie at sandia.gov
Thu, 25 Mar 2004 10:00:43 -0700
Berk,
Thank you for the detailed explanation of the issues and proposed solutions.
After reading your email I agree with you on having a 'thicker' layer that
can abstract some of the parallel functionality. I think your proposed
design is reasonable... The only reason I was grumbling was because I hadn't
heard anything... :)
Best,
Brian Wylie
Sandia National Laboratories
MS 0822 - Org 9227 - Building 880/A1-J
(505) 844-2238 FAX (505) 845-0833
> -----Original Message-----
> From: Berk Geveci [mailto:berk.geveci at kitware.com]
> Sent: Thursday, March 25, 2004 7:45 AM
> To: Jim Ahrens
> Cc: Brian Wylie; Charles Law; Bill Hoffman; Ken Martin;
> ParaView Developers
> Subject: Re: Pipeline 'split'
>
>
> Hi.
>
> I don't exactly understand what "pipeline split" is. I will
> describe shortly what I have been doing:
>
> Objective: Separate ParaView's server management code from
> the GUI code.
>
> Current state: ParaView uses a loose proxy pattern to drive
> the server. Each object on the server is represented by an id
> and is accessed by the client through this id and the stream
> based wrappers.
>
> Problems:
>
> * The server access is spread throughout the ParaView code
> and the method used to manage objects vary depending on the
> class (and the programmer who implemented the class). For
> example, a filter is manipulated directly by a PVSource,
> PVWidget, PVWidgetProperty.
>
> * There is no uniform method to access VTK objects on the
> server. For example, RenderModules access the RenderWindow
> directly (a RenderModule has an ivar that is the id of the
> RenderWindow), whereas PVSources use PVWidgets and
> PVWidgetProperties to access the sources (PVSource has a an
> ivar that is the ids of the filters it maintains and it
> passes this to other objects as necessary).
>
> * It is not possible to re-use any ParaView code to write
> another client.
>
> Solution:
>
> Separate the part of ParaView that manages the VTK objects on
> the server to an independent module (i.e. a library that
> ParaView client links to). This module consists of:
>
> * Proxy classes: Actually, a combination of proxy and adapter
> patterns. While providing a way to manipulate one or more VTK
> objects of the same class on the server, the proxy does not
> duplicate the interface of the object it manages. Rather, it
> provides an adapter that makes the interface more uniform.
>
> * Property classes: There are read and write properties.
> Write properties usually correspond to SetXXX methods.
> However, they can do much more complicated things under
> covers. Read properties usually correspond to PVInformation
> objects. They provide some sort of information about the VTK
> object(s) they are associated with. For example, the (whole)
> bounds of a (data parallel) data object.
>
> Proxies and properties are described in XML. Currently, the
> configuration file is created manually. It would be nice to
> have it semi-automatically generated (not in our radar right now).
>
> We did not use the "thin" proxy described by Brian because it
> provides very little advantage over directly accessing the
> VTK objects through a wrapping layer such as Tcl or
> Client/Server streams. The proxies and properties I described
> above provide a thicker layer that implement:
> - composite objects : the client does not have to create a
> mapper, actor, renderer, renderwindow. Instead, it creates
> displayers and display windows. We create a small pipeline
> (for example, geometry
> filter-mapper-actor) in these classes and set good default
> values. Furthermore, we can automatically instantiate the
> right sub-class depending on whether ParaView is running on
> batch, tiled display, chromium mode etc.
> - algorithms to access the VTK objects in parallel to get
> things like total number of points, bounds etc.
> - functionality that is not in VTK yet. A good example is
> multi-block support.
>
> What I have so far:
>
> 1. Nothing is committed to ParaView. All code is my work
> repository. 2. A hierarchy of proxy and property classes,
> with an xml parser to create and configure objects from these
> 3. A modified ParaView tree that writes out Tcl batch files
> driving the server manager. This will be re-done once I start
> incorporating the server manager into ParaView proper.
>
> The next release (1.4) will use the server manager only in
> batch scripts.
>
> I will provide more information and documentation once we
> branch 1.4. Right now, I am very busy trying to get the batch
> working as much as I can for 1.4. The current batch does NOT
> work. I actually wanted to write a short message but got
> excited and wrote this loooong one instead. My apologies :-)
>
> -Berk
>
>
>
> > On Mar 24, 2004, at 9:42 AM, Wylie, Brian wrote:
> >
> >
> > ...
> >
> >
> > I'd like to see the pipelinesplit work be closely related to
> > the 'proxy' pattern. Below in anexample of how this works.
> > Basically the remote object looks like alocal object. This
> > type of mechanism seems to me to be very flexibleand
> > straightforward. All the classes that will be proxy enabled
> > willget auto generated in a form similar to the tcl
> wrapping.
> >
> > Machine1:
> >
> > vtkConeSource *cone =vtkConeSource::New();
> >
> > vtkPolyDataMapper*coneMapper = vtkPolyDataMapper::New();
> > coneMapper->SetInput(cone->GetOutput() );
> >
> > vtkActor *coneActor =vtkActor::New();
> > coneActor->SetMapper(coneMapper );
> >
> > vtkRenderer *ren1=vtkProxyRenderer::New();
> > ren1->SetHost("machine2" );
> > ren1->AddActor(coneActor );
> >
> >
> > Machine2:
> >
> > vtkActor *coneActor =vtkProxyActor::New();
> > coneActor->SetHost("machine1" );
> > coneActor->SetMapper(coneMapper );
> >
> > vtkRenderer *ren1=vtkRenderer::New();
> > ren1->AddActor(coneActor );
> >
> > vtkRenderWindow *renWin =vtkRenderWindow::New();
> > renWin->AddRenderer(ren1 );
> >
> >
> > ...
> >
> > BrianWylie
> > Sandia NationalLaboratories
> > MS 0822 - Org 9227 - Building880/A1-J
> > (505) 844-2238 FAX (505)845-0833
>
>
>