[vtk-developers] vtkHyperTreeGridGeometry and vtkDataSetSurfaceFilter

Mon May 14 20:01:23 EDT 2012

>
>
> I did not realize that CMake compiler options were now entirely banned
> in VTK. That is quite a change indeed. I am also concerned by the
> complexity of the run-time options.
>
>
To clarify, CMake options are not supposed to change the contents of
modules. A CMake option cannot add classes to a modules nor can it extend
the functionality of a class (such as adding a new type of surface
extraction filter). This is so that package maintainers can create a set of
packages that can build on each other but that are independent. In the
past, this was a problem because options such as VTK_USE_MPI changed the
contents of kits, making it impossible to have both version (with and
without MPI) exist as two independent packages due to library name and
symbol duplication. VTK 6 aims to avoid this. It is still allowed to have
option that change the behavior of modules in limited ways or select
different implementations of libraries - such as a system zlib as opposed
to built-in zlib, or different types of threading libraries.


> Creating a SurfaceExtraction makes sense if we assume that there might
> be one user somewhere who wants to use VTK but without surface
> extraction. That is the point of modules, isn't it?
>
>
Or someone may want to build VTK with your surface extraction filters and
leave out everything else from whatever modules that class is currently in.
We are trying to give developers the option of picking and choosing among
VTK classes. Usually the boundary between modules are blurry and we need
the community's help to move towards a separation that represents most of
the use-cases out there.


> So, the simplest solution (moving the hyper tree grid surface filter
> where the other surface filters are) seems reasonable. If nobody has a
> strong disagreement then this is what I will do.
>
>
Fine with me.


> Thanks for the comments
> Philippe
>
>
> On Mon, May 14, 2012 at 11:12 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> > You don't have the choice of extending it at compile time :-) As of VTK
> 6,
> > we will not allow for the content of individual modules to change based
> on
> > compile-time (i.e. CMake) options.
> >
> > The run-time options sounds overly complicated and computer-sciency to
> me.
> > And they are harder to support when linking statically. But that's me. I
> am
> > a simple mechanical engineer.
> >
> > If this was my code, I would put the new geometry filter in the same
> place
> > as the dataset surface filter and be done with it. If I felt like being
> > fancy, I might consider creating a SurfaceExtraction module and move all
> > surface filters there.
> >
> > On Mon, May 14, 2012 at 2:13 PM, Philippe Pebay <
> philippe.pebay at kitware.com>
> > wrote:
> >>
> >> Hello Marcus
> >>
> >> Thanks for having taken the time to respond.
> >>
> >> So, regarding this option:
> >> > Having a pattern where one module creates meta-filters, combining
> >> > those of multiple modules is reasonable. If one wishes to use that
> >> > filter then they accept the dependency graph.
> >> Yes, but in this case the "wish" would be almost a mandate, as the use
> >> of vtkDataSetSurfaceFilter is quite prevalent (for example this is the
> >> one used by PV for surface extraction, and not vtkGeometryFilter). On
> >> the other hand I think that HyperTreeGrid is quite an exotic data set.
> >> So, is it all right to force this dependency for all users?
> >>
> >> If the answer to this question is no, then we have the choice of
> >> extending either during compilation, or at run time. If I am not
> >> mistaken, a good example of the former is the Statistics vs.
> >> StatisticsGnuR. Is this correct?
> >>
> >> Thanks
> >> Philippe
> >>
> >>
> >> On Fri, May 11, 2012 at 8:43 PM, Marcus D. Hanwell
> >> <marcus.hanwell at kitware.com> wrote:
> >> > On Thu, May 10, 2012 at 10:13 AM, Philippe Pebay
> >> > <philippe.pebay at kitware.com> wrote:
> >> >> Hello all:
> >> >>
> >> >> I have a question regarding vtkDataSetSurfaceFilter, the accelerated
> >> >> version of the Geometry filter.
> >> >>
> >> >> My question is the following: I would like to make
> >> >> vtkDataSetSurfaceFilter able to automatically fork off to the
> >> >> vtkHyperTreeGridGeometry filter when the data object is found to have
> >> >> type VTK_HYPER_TREE_GRID.
> >> >> This seems like a simple addition to make, by simply instantiating
> the
> >> >> hyper tree grid geometry filter when the case is met in the switch
> >> >> statement of vtkDataSetSurfaceFilter::RequestData().
> >> >>
> >> >> However, this would introduce a dependency of Filters/Geometry on
> >> >> Filters/HyperTree because this is where the hyper tree grid geometry
> >> >> filter currently is, which is certainly a bad thing.
> >> >>
> >> >> So, we can think of 2 possible ways to mitigate that:
> >> >> 1. Move vtkHyperTreeGridGeometry to Filters/Geometry. Whch would
> >> >> defeat the purpose of the Filters/HyperTree module, which is there
> >> >> precisely to hold hyper tree grid algorithms, so one has the option
> to
> >> >> not build support for tree-based AMR things.
> >> >> 2. Another route is to create a new module Filters/SurfaceExtractiion
> >> >> whose purpose would be to contain only surface extraction filters
> >> >> (including the HyperTreeGrid one).
> >> >> I am not sure that either of these options is really great, for the
> >> >> sake of modularity, it would be nice to be able to turn off all hyper
> >> >> tree support.
> >> >>
> >> > Having a pattern where one module creates meta-filters, combining
> >> > those of multiple modules is reasonable. If one wishes to use that
> >> > filter then they accept the dependency graph. An alternative you
> >> > didn't mention is one of filter registration and extending the
> >> > vtkDataSetSurfaceFilter at run time.
> >> >
> >> > You can see an example of this in vtkIOSQL and the related modules
> >> > vtkIOMySQL, vtkIOPostgreSQL. If the vtkIOMySQL module is linked then
> >> > is uses the auto init logic to register a new handler with the
> >> > vtkSQLDatabase function.
> >> >
> >> > The other alternative would be to derive from vtkDataSetSurfaceFilter
> >> > and create an override if the hyper tree module is linked that would
> >> > use the hyper tree filter if appropriate. Users who do not link get
> >> > the normal class, those who do get the more derived version of the
> >> > filter - this would not support registering multiple handlers but
> >> > should satisfy your current need.
> >> >
> >> > Marcus
> >>
> >>
> >>
> >> --
> >> Philippe Pébay, PhD
> >> Director of Visualization and High Performance Computing /
> >> Directeur de la Visualisation et du Calcul Haute Performance
> >> Kitware SAS
> >> 26 rue Louis Guérin, 69100 Villeurbanne, France
> >> +33 (0) 6.83.61.55.70 / 4.37.45.04.15
> >> http://www.kitware.fr
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>
> >
>
>
>
> --
> Philippe Pébay, PhD
> Director of Visualization and High Performance Computing /
> Directeur de la Visualisation et du Calcul Haute Performance
> Kitware SAS
> 26 rue Louis Guérin, 69100 Villeurbanne, France
> +33 (0) 6.83.61.55.70 / 4.37.45.04.15
> http://www.kitware.fr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120514/a11b0464/attachment.html>