[GRASS5] s.surf.krig (updated)

[David D Gray]

Hi developers,

I've uploaded to CVS a new version of s.surf.krig. This is just a rehash
of the old package, but includes support for most GRASS5 features:

* now uses/requires a GRASS5 sites-list for spot heights.
* creates DCELL fp map. This is fixed at the moment, but I plan to make
the cell type optional later.
* attempts to use ellipsoid sensitive geodesic lengths for LL locations
(and euclidean distance for planimetric)- see below.

Problems:

1) Stack corruption error. 

The call to G_distance() in d2nsamp.c works fine, but within it calls to
other functions and its return value get corrupted. GDB reports a
returned value of 11704 in the receiving stack as 288, also hypot()
imports nonsense (mostly 1). Can anyone repeat this/ know what's going
on? My system is Debian GNU/Linux 2.2 i386, kernel 2.2.17, GRASS5 CVS
updated compiled with CFLAGS="-g". I am fairly certain the problem is
with import/export from the G_distance() stack.

2) Unusably slow. (except for v. small/low res. maps)

The problem is the way the site-list is scanned for neighbouring points
in read_sites.c. Need to build a spatially aware network database and
use that to locate the neighbourhood of kriging points.

3) Dependency issues.

This module uses the engine from LAPACK (and so BLAS also) for solving
linear systems. It is yet uncertain how to deal with this dependency.
Currently there is a need to link to the system installation. Should we
bundle the LA libs? Many people will want to use locally maintained,
optimised versions and so would want to link to the system installation.
Others might not otherwise have any involvement with/knowledge of these
libs, so bundling it would ease installation (it would add c. 1.5MB to
the source package compressed to distribute the BLAS and LAPACK
sources), also a fortran compiler is needed.

Also the protype files generated by f2c in src/include/ ie. blas.h
lapack.h declare eg. dgemm_(...), but I have read that you can't rely on
the form foo_ for a C symbol translation of a fortran routine, so this
may have to be varied accordingly.

And there is a dependency on g2c.h and -lg2c which are usually stored in
the system at ...lib/gcc-lib/<platform>/<version>/ in gcc-based systems.
Non-gcc systems will probably deal with fortran lib compatibility
differently. A job for autoconf?

This change was made initially because of the license problem with the
bundled `Numerical Recipes' routines, but there are also considerations
of performance in operations that take a long time. 


Feel free to test this (you will also have to check out the new gmath
wrappers), but don't be concerned if it doesn't go very far. there is
some work to be done in stabilising this. If you do try it out, I would
like to know of any problems though - in the module or the library links
or wrappers.

Regards

David


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'