[GRASS-dev] LINEQS solvers and v.surf.rst

GRASS GIS GRASS GIS developer
1

Soeren,
I am forwarding the tests to the dev list so that it gets into the archive and everybody can check it out.

For everybody - this relates to the discussion about the NR lineqs solver replacement,

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/

Begin forwarded message:

From: Sören Gebbert <soerengebbert@gmx.de>
Date: May 6, 2007 6:19:03 AM EDT
To: Helena Mitasova <hmitaso@unity.ncsu.edu>
Subject: Re: LINEQS

Helena,
Thanks for the chapter.
I have tested the solvers with several vector maps from the
new demo location.

The script which performs the tests is attached. So you are
able to reproduce the tests.
The log file, including time measurement and error log,
is attached as well.

I have created two simple bar charts. The first represents the processed vector maps and
the cpu time consumption of each solver, measured by the time command. The second one
represents the elev result error between the iterative solvers and the nrlu solver
for each processed vector map.

All the data presented in the charts is available in the log file.

The cg solver is the fastest solver, the new direct lu and gauss
solver are 20% slower than the nrlu algorithm.

The computation error of the iterative solvers is small enough to be
accepted. The gpde lu and gauss solver producing exactly the same result as the nrlu
algorithm (see log file).

So the new lu and the cg solver are the best replacement for nrlu.
I did not tested parallel computation, because i have no
multi core computer at home.

But, the iterative solvers partially failed on vector maps with low data density (contour lines
in maps elev_contour_3m and elev_ned10m_cont10m),
in case the npmin was set to 50 or lower. A value of 50 is not meaningful for the maps,
but its the users choice ... .

So much more testing is needed.
Anyway, the gpde lu solver can handle this.

Important region and v.surf.rst settings:

g.region rural_1m res=2
npmin=500

Best regards
Soeren

Helena Mitasova schrieb:

On May 5, 2007, at 4:00 PM, Sören Gebbert wrote:

Hi,
now i know the source of the linear equation solver
which you had send me.
Its is the solver implemented in v.vol.rst in user4.c. :smiley:

yes - actually v.surf.rst (s.surf.tps) originally looked like v.vol.rst which is a direct
rewrite of our original fortran code. There should also be v.volt.rst
that interpolates in 3D+time space.
I really wanted all 3 programs and r.resamp.rst to be based on a single library as
most of the code is almost the same, only the dimensions change,
but Irina (one of the russian twins that worked with me at CERL
and did a lot of coding for GRASS, you can see Olga and Irina
mentioned throughout various GRASS modules)
managed to get it to where it is now by the time she finished her Masters
and CERL dropped the GRASS project. So it is a quite ugly code right now
but it works . I doubt that anybody would have time to rewrite it.

Looks like good old fortran code converted to C.
I think i will patch v.vol.rst too.

yes that would be good. I am thinking that it may be useful to submit
the options for solvers that you have added into CVS, I would like to let
people from GEON project try it out too (http://lidar.asu.edu/), especially
the parallel processing.
It would be great if you could try out the performance of the solvers with
the new data set - both in terms of how fast they are and whether there are
any differences in the results. The data are here, (set the region to rural_1m)
http://mpa.itc.it/grasstutor/data_menu3rd.phtml
Try it with elev_lid792_bepts, elev_lid792_mrpts, elev_lid792_randpts and
elev_contour_3m. I have attached chapter6.tex file that has all the commands
so you can just cut and paste them into a script and run it all at once
(ignore the figures in the pdf file - they are still for sperafish).
These are all small files so a few tests with millions of points would be useful
too (e.g. the Jockey's ridge data from the second edition available at the same web site).
That should help to decide which method put as default and which are not
needed (to make the life easier for the user). I will then get Jaro and some
other people test it more to make sure that the new solvers work for everybody's data.
Helena

Best regards
Soeren

(attachments)

RST_solver_test.sh (2.28 KB)
RST_solver_test_bar_charts.pdf (15.5 KB)