[vtk-developers] Fitting code and it's place in VTK

Tue Sep 18 16:15:13 EDT 2001

Most of the nonlinear optimization code in Insight calls VXL routines which call netlib routines.
The VXL/VNL architecture is fairly nice for doing optimization.  However, it still has the flavor
that you call a routine and pass it a function to evaluate over.  Insight put a layer on top of this
so you could have an object interface that fits better in a pipeline mechanism.

There are other numerics libraries but they tend not to be very portable (they use too many high end
C++ features).  Also, many numerics libraries are really just matrix libraries (they have a matrix
class but are devoid of algorithms like SVD and eigenvectors).

The complexity of SVD and eigensystems is an issue in porting faithfully to vtk.  However, we are
fairly confident in the f2c lapack code.  So we might just focus on the impact of removing "statics"
from the code and run with whatever routines we want.

-----Original Message-----
From: David Gobbi [mailto:dgobbi at irus.rri.ca]
Sent: Tuesday, September 18, 2001 4:09 PM
To: Miller, James V (CRD)
Cc: Blezek, Daniel J (CRD); 'vtk-developers at public.kitware.com'
Subject: RE: [vtk-developers] Fitting code and it's place in VTK

On Tue, 18 Sep 2001, Miller, James V (CRD) wrote:

> VXL uses the f2c generated code from lapack.  VXL grew out of system that definately not thread
safe.
> So I don't think they are too concerned with thread safety issues.
>
> I would suggest we identify what algorithms we are missing from VTK and port those methods from
> lapack that we need. This may start with the f2c code and remove any statics, etc.

It seems like there really should be some decent, modern, open-source
numerical code out there somewhere.  But when I first went looking for
some four years ago I didn't find anything, and it looks like the
situation hasn't changed.  When I first saw vxl, I was hoping I had
found it.

> The glaring ommission from VTK is an SVD algorithm.  We may have one in house that was a port of
the
> LAPACK routine. If that is the case, we'll roll that out.  The other ommission is a general
> eigenvector routine.  VTK's routine requires symmetric matrices.  Are there any other routines that
> we need?

The major problem with SVD and eigenvector routines is their complexity,
and hence the need for thorough testing of the myriad cases in the code
(even if the code is simply a mogrified version of reliable code).  But
the VTK regression testing is probably up to it, if only the needed
routines are ported.

The other thing that VTK needs is some good nonlinear minimization code.
It looks like Insight already has this, but I'm not sure whether that is
Insight code or some package that Insight relies on.

 - David

> -----Original Message-----
> From: David Gobbi [mailto:dgobbi at irus.rri.ca]
> Sent: Tuesday, September 18, 2001 2:10 PM
> To: Miller, James V (CRD)
> Cc: Blezek, Daniel J (CRD); 'vtk-developers at public.kitware.com'
> Subject: RE: [vtk-developers] Fitting code and it's place in VTK
>
>
> Hi Jim,
>
> I've taken a brief look at vxl/vnl, and it appears to be miles ahead of
> clapack in terms of suitability, and also in terms of support.  It even
> has an active CVS repository on SourceForge.  I'm guessing that most
> people on this list will have already seen it (since vxl uses CMake,
> and the vxl people are obviously familiar with VTK).
>
> So I retract my suggestion that clapack be included with VTK.
>
> The thread-safety is a big issue (not that many of the VTK primitives
> don't have their own thread-safety issues).  It looks like vxl
> uses netlib for some of its underlying matrix operations, however,
> and netlib shares the same fortran heritage as clapack.  So at
> first glance, it seems that vxl has exactly the same problems with
> thread-safety as clapack.
>
> Can someone who is familiar with vxl comment on its thread-safety?
>
>  - David
>
>
> On Tue, 18 Sep 2001, Miller, James V (CRD) wrote:
>
> > My concern with any of the f2c converted code (clapack, etc.) is that (at first glance) it is not
> > thread safe. It looks like the fortran "common" blocks were translated into "static" variables in
> > function and files.
> >
> >
> >
> > -----Original Message-----
> > From: Blezek, Daniel J (CRD)
> > Sent: Wednesday, September 12, 2001 1:51 PM
> > To: 'David Gobbi'
> > Cc: 'vtk-developers at public.kitware.com'
> > Subject: RE: [vtk-developers] Fitting code and it's place in VTK
> >
> >
> > David,
> >
> >   I toyed around with clapack, blas and f2c on Tuesday.  blas went in very easily under CMake,
but
> I
> > abandoned it pending discussion on the mailing list, Kitware, and CRD.  I don't think the
mechanics
> > of adding blas, lapack, etc are difficult, it's defining the interface w/VTK that is the problem.
> > One of the thoughts is to incorporate vnl, the numerics package from VXL and Insight into VTK.
> That
> > way we have one common numerics package across three different packages.  VXL, Insight, and VTK
are
> > very cross platform, so I know that vnl would fit in well.  Again the question is: do we add a
> > "VTK-ish" layer to clapack/vnl, or just compile them in for use wherever needed in VTK.
> >
> >   I have no strong preferences of any numerics package; I just want to solve my problem.
> >
> > Thanks,
> > -dan
> >
> > -----Original Message-----
> > From: David Gobbi [mailto:dgobbi at irus.rri.ca]
> > Sent: Monday, September 10, 2001 5:21 PM
> > To: Blezek, Daniel J (CRD)
> > Cc: 'vtk-developers at public.kitware.com'
> > Subject: Re: [vtk-developers] Fitting code and it's place in VTK
> >
> >
> > On Mon, 10 Sep 2001, Blezek, Daniel J (CRD) wrote:
> >
> > > 2) where/when/who would like to put some numerical code into VTK 4.0, in a similar way that
png,
> > > zlib, and jpeg were bundled?
> > >   - this would eliminate the "Numerical Recipes in C" debacle that I just went through
> > >   - would give VTK uses a great deal more power to do things
> >
> > I will again give my vote for the blas_lite, dlapack_lite, etc. that are
> > included in the Python Numeric package (http://numpy.sourceforge.net/).
> >
> > The code isn't very pretty (most of it has been machine-translated from
> > fortran to C) but it is API-compatible with the optimized versions of
> > libblas that are available for many platforms, i.e. cmake can use the
> > optimized libblas if present, or link to blas_lite otherwise.
> >
> > Another option is to include cblas and clapack themselves.  Again,
> > the code isn't pretty, but these are fairly standard tools and are
> > very well tested.
> >
> >  - David
> > _______________________________________________
> > vtk-developers mailing list
> > vtk-developers at public.kitware.com
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
>