[GRASS-dev] GRASS GIS nightly builds

[Markus Metz]

On Mon, Feb 25, 2013 at 2:49 AM, Newcomb, Doug <doug_newcomb at fws.gov> wrote:
>
> I've been playing with generating surfaces at home on an 8 core AMD vishera
> system 3.5 ghz Ubuntu 12.04 system with G7  using this point layer:

Your point layer extents:
> |
>  |               N:         694901.76    S:         482704.72
>  |               E:         580721.99    W:         492486.01
>  |               B:           1083.51    T:           5558.44


> I get the following 20ft resolution surface using v.usrf.bspline

bspline surface:

> |
>  |            N:     693610    S:     482260   Res: 19.99905375
>  |            E:     580722    W:     492486   Res: 19.99909338
> |
>  |   Range of data:    min = 92.2649807704968  max = 5558.35850509857

Note the range of data, compare to the original points and the rst surface.

>
> As you can see , the surface generation ran in 805 minutes.  I'm currently
> rerunning the analysis with maxit = 100 to see how long it takes with the
> iterations lowered.

It will make no difference because you used the cholesky solver. The
module could be faster if you recompile GRASS without openmp, or use a
system with at least 16 cores. v.surf.bspline would be much faster if
you increase the spline steps to 60 or 80.

>
> Now with v.surf.rst, I generated the following grid:

rst surface:

> |
>  |            N:     693610    S:     482260   Res: 19.99905375
>  |            E:     580722    W:     492486   Res: 19.99909338
> |
>  |   Range of data:    min = -1.409014e+28  max = 7.890661e+27

Note the range of data. Looks like serious overshoots. You could try
different values for tension and smoothing for a smaller subregion in
order to get a range of data that is closer to the original data.

>
> As you can see, it took only 458 minutes to generate the same resolution
> surface from the same input points.  On the 8 core system, it is using 650%
> of the cpu to process the data, bouncing  up and down 30% or so as it
> processes.
>
>  v.surf.bspline, on the other hand parses the data up into zones and uses
> 100% cpu up to the time it writes the individual zone out.  When it writes
> the zone out, it spikes up to 750% cpu.  For this vector set and grid
> extent, it generated 920 zones.

See above, recompile GRASS --without-openmp to get more speed.
>
> V.surf.rst seems to use much more memory than v.surf.bspline

v.surf.bspline has a memory option (defualt 300MB). But giving
v.surf.bspline more memory will not make processing faster, most of
the time is spent in the solver.

Markus M
>
> I am of course, speaking as an end user who has not looked at the source
> code. ( I'm trying to back myself into learning C :-))

Very useful testing report!

Markus M