[Paraview] ParaView 3 and PARAVIEW_EXTRA_EXTERNAL_MODULE

[Sean Ziegeler]

I've given this issue some serious consideration myself.  Actually, I
took it a step further and classified my options as follows: (1) static
linking, (2) dynamic linking (shared objects), (3) run-time-loaded
plugins.  They each have advantages and disadvantages.  Using
PARAVIEW_EXTRA_EXTERNAL_MODULE falls under (1) or (2) (depending upon
whether you specify shared objects in CMake).  Here's what I've learned:

I originally started out statically linking everything.  It's simple to
run.  No LD_LIBRARY_PATH's or plugin paths, etc.  But if you run it in
parallel on a single (multi-cpu/multi-core) node it takes up more
memory.  Keep in mind that each executable will load ALL of PV and VTK,
which can get big.  Also, if you change one of your custom plugins, you
have to recompile (though it doesn't take nearly as long as the first
time) and reinstall everything.

Option 2 (shared objects) takes care of the memory problem (the .so's
get loaded once per node and all execs share them), but you still have
to recompile.  You may get away with just swapping out the
.so(.dll/.dylib) files sometimes, but if you change the interface
there's stuff that gets generated by XML files that also usually needs
to be swapped out.  It's safest to just reinstall everything.

Recently, I've been using option 3, the run-time plugins.  If you're are
constantly adding to your plugins, it's very easy to just swap out the
.so files.  Also, you build each plugin separately (not as part of
ParaView's build process), so it's quick and clean.

Shared disks shouldn't be required on a cluster.  Since you must have
the executable installed on each node anyway, you should just be able to
put copies of the plugins in the same directory structure as the
executables.  You'll have to be careful to make sure the .so files on
each node all match each other.

-Sean

clinton at elemtech.com wrote:
> On Friday 07 December 2007 1:03:28 pm Kent Eschenberg wrote:
>> clinton at elemtech.com wrote:
>> < If the generated GUI isn't what
>>
>>  > you want, you have to write a plugin.
>>
>> The generated GUI cannot possibly know the labels, defaults and other
>> particulars that are best for the GUI so I guess I'll have to write a
>> plugin.
> 
> Like Berk said, you probably don't need to, and most ParaView builtin 
> filters/sources are auto-generated at run time.  So you probably don't need 
> to make a GUI plugin.
> 
>> How do I do that and build the code into paraview during compilation?
>> Loading things at every execution seems less reliable and could be
>> difficult on parallel systems with no shared disk.
> 
> Client/GUI side plugins aren't deployed on parallel systems, just on the 
> client machines.  You could even use PARAVIEW_EXTRA_EXTERNAL_MODULE to build 
> your server side code into ParaView, and have it work with GUI plugins on the 
> client side.
> 
>> Would I still use PARAVIEW_EXTRA_EXTERNAL_MODULE?
> 
> If you want, you can.  Here's the new wiki page I said I'd make.
> http://www.paraview.org/Wiki/ExtendingParaView
> 
> Clint
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>