[GRASS-dev] BLAS/LAPACK (Part II)

[Soeren Gebbert]

2007/8/17, Brad Douglas <rez at touchofmadness.com>:
> On Fri, 2007-08-17 at 17:12 +1200, Hamish wrote:
> > Brad Douglas wrote:
> > >
> > > I did not hear any response to my question of whether to continue
> > > using BLAS/LAPACK.

Well, i was responding ... .

> > >
> > > This uncertainty has been particularly hard on me, being unable to
> > > complete some work waiting for an answer one way or the other and not
> > > wanting to implement my own version if not needed.
> > >
> > > Currently, there is no code in the tree that makes use of either
> > > library other than my own.  In fact, others have implemented their own
> > > versions.
> >
> > If having it there is not hurting anything, I'd say leave it as-is.
> >
> > It is less work to maintain the configure scripts than it is to stay
> > current with the latest advancements in the library. ie 5 years from
> > now we'd have an unmaintained stale copy distributed with our source.
>
> ? There's nothing to go stale.  Or are you making my case for me?
>
> > BLAS/LAPACK are in common use elsewhere, so it's not like a user would
> > have to spend time hunting down and compiling obscure software to use
> > it.
> >
> > Take pride in being the first to use it, we've been waiting a while for
> > someone to. :)
>
> And then having modules become useless when the libraries aren't
> compiled in?
>
> > > What I propose is moving the matrix code from v.generalize (in
> > > particular, matrix_inverse() ) to lib/gmath and simplifying the
> > > existing MATRIX structure.
> >
> > regardless of BLAS/LAPACK staying or going, consolidation, consistency,
> > and anything else that makes the code easier to maintain is obviously a
> > good thing. (but no idea about that specific code)
>
> There are only a few functions in lib/gmath that make use of
> BLAS/LAPACK:
>
> G_matrix_product ()
> G_matrix_LU_solve ()
> G_vector_norm_euclid ()
> G_matrix_inverse () -- calls G_matrix_LU_solve ()
>
> v.generalize solves:
> G_matrix_product ()
> G_matrix_inverse ()
> G_matrix_LU_solve ()
>
> So what's the point of having BLAS/LAPACK?

I think we shoudl keep the LAPACK/BLAS interface in GRASS,
especially for high performance comnputing on cluster, the LAPACK
interface makes
much sense.

I had a short look at matrix.c and matrix.h in v.generalize.
Because of the similar implementation
of the gpde library functionality, i am able to port the functionality
of v.generalize/matrix stuff
into the gpde library. And i will implement it multithreaded, like all
the linear equation solvers within the gpde library.

What do you think?

Soeren

>
>
> --
> 73, de Brad KB8UYR/6 <rez touchofmadness com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>