[GRASS-PSC] Incubation progress, open issues in Wiki

Soeren Gebbert soerengebbert at googlemail.com
Wed Sep 5 12:20:45 EDT 2007


Hello,

2007/9/5, Helena Mitasova <hmitaso at unity.ncsu.edu>:
>
> Brad, Soeren
>
> would it be possible to create a list of modules that would be
> affected by this change and then we should do a thorough testing on
> spearfish and nc_sample data set and ask others to test it with their
> data (including all kinds of unusual applications that they may have,
> large data sets, different scales, xy and latlong,etc.), especially
> compare the results run with the current solvers and the new ones.
> You are right that this is a significant and important change so it
> needs a lot of testing to make sure that we don't get unintended
> consequences. I wish we did such comparison and testing before the
> sites->vector points change.



AFAICT the changes we want to make will effect the gmath, gpde libraries and
every module which uses the gmath lapack interface as well as some gmath
functions.

I will move the linear equation solvers from the gpde library into the gmath
library.
And i will establish a unit and integration test structure (like in the gpde
library) to test all of the
gmath functions we will implement. And if i have time, i will implement some
benchmarks.

Modules which  will be affected (as far as i know):
* v.surf.rst
* v.surf.random
* r.gwflow
* r3.gwflow
* r.surf.fractal
* r.surf.gauss
* r.surf.random
* Maybe the lidar modules, but im not quite sure
* i.gensigset ? --> uses G_alloc_matrix
* i.smap ? --> uses G_alloc_matrix
* i.cca ? --> includes gmath.h
* i.pca ? --> inclues gmath.h
* i.fft ? --> includes gmath.h
* i.ifft ? --> includes gmath.h
* i.zc ? --> includes gmath.h
* v.kernel ? --> includes gmath.h

* v.generalize (will be changed to use the much faster cholesky
decomposition with bandwith optimization)

This list is incomplete.

Soeren - could you email to the dev list or at least to PSC the
> comparison of different solver when used with v.surf.rst? (if you
> don't have it on-hand - I can post it - it may be even useful to put
> it on a related wiki page - it is a useful reminder how much
> difference there is for different solvers).


I'm sorry, but i lost the mail i had send you, can you please post it for
me?

Best regards
Soeren

Helena
>
>
> Helena Mitasova
> Dept. of Marine, Earth and Atm. Sciences
> 1125 Jordan Hall, NCSU Box 8208,
> Raleigh NC 27695
> http://skagit.meas.ncsu.edu/~helena/
>
>
>
> On Sep 4, 2007, at 10:55 PM, Brad Douglas wrote:
>
> > On Tue, 2007-09-04 at 10:05 +0200, Markus Neteler wrote:
> >> Hi Arnulf,
> >>
> >> On Tue, Sep 04, 2007 at 08:57:39AM +0200, Arnulf Christl wrote:
> >>> Hello,
> >>> I wanted to send a friendly reminder of the open issues in the
> >>> Wiki at:
> >>> http://wiki.osgeo.org/index.php/
> >>> GRASS_Incubation_Progress#Open_Issues
> >>>
> >>> As far as I can see activity wrt to the incubation process has
> >>> stopped
> >>> altogether, there have been no edits in the Wiki for 3 months. I
> >>> have to
> >>> report to the Incubation Committee in my function as mentor and
> >>> they will
> >>> again ask why incubation has stopped. What shall I tell them?
> >>
> >> that it didn't stop :) Indeed, we didn't update the Wiki as we
> >> should. But currently we are replacing remaining "Numerical
> >> Receipes in C"
> >> code with new functions.
> >
> > BTW, I located more NR code in GRASS.  The eigen and Jacobi
> > routines use
> > them.  I've also discovered that the NR routines are inherently
> > unstable, but that also applies to most OSS solutions.
> >
> > Both Soren and myself would like to replace the BLAS/LAPACK (Fortran
> > code) libraries with ATLAS, a tuned C version.  This also gets us away
> > from the Fortran issues suffered by gcc4.
> >
> > If there are no objections, I would like to go ahead and modify
> > configure.in and include/ to reflect this.  Soren has already
> > created a
> > good wrapper API for the functionality and has expanded it
> > extensively.
> > I didn't note any objections when I queried the devel list, but I
> > think
> > this is sufficiently large enough to be voted on by the PSC.
> >
> > I really can't complete my imagery/ and lib/gmath API changes until
> > ATLAS (or some equivalent..maybe even GSL?) has replaced existing
> > BLAS/LAPACK.
> >
> >> Some file headers may need update, too, as above page indicates.
> >
> > I've been adding them to all files I've touched...and I've touched
> > quite
> > a few lately.
> >
> >>> I did hope that we might get GRASS through before FOSS4G. Any
> >>> chance? There
> >>> is really not much left to do.
> >>
> >> That would be an excellent milestone.
> >
> > Agreed.
> >
> >
> > --
> > 73, de Brad KB8UYR/6 <rez touchofmadness com>
> >
> > _______________________________________________
> > grass-psc mailing list
> > grass-psc at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-psc/attachments/20070905/77f8ae10/attachment.html


More information about the grass-psc mailing list