Hello,<br><br><div><span class="gmail_quote">2007/9/5, Helena Mitasova <<a href="mailto:hmitaso@unity.ncsu.edu">hmitaso@unity.ncsu.edu</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brad, Soeren<br><br>would it be possible to create a list of modules that would be<br>affected by this change and then we should do a thorough testing on<br>spearfish and nc_sample data set and ask others to test it with their
<br>data (including all kinds of unusual applications that they may have,<br>large data sets, different scales, xy and latlong,etc.), especially<br>compare the results run with the current solvers and the new ones.<br>You are right that this is a significant and important change so it
<br>needs a lot of testing to make sure that we don't get unintended<br>consequences. I wish we did such comparison and testing before the<br>sites->vector points change.</blockquote><div><br><br>AFAICT the changes we want to make will effect the gmath, gpde libraries and
<br>every module which uses the gmath lapack interface as well as some gmath functions.<br><br>I will move the linear equation solvers from the gpde library into the gmath library.<br>And i will establish a unit and integration test structure (like in the gpde library) to test all of the
<br>gmath functions we will implement. And if i have time, i will implement some benchmarks.<br><br>Modules which will be affected (as far as i know):<br>* v.surf.rst<br>* v.surf.random<br>* r.gwflow<br>* r3.gwflow<br>*
r.surf.fractal<br>* r.surf.gauss<br>* r.surf.random<br>* Maybe the lidar modules, but im not quite sure <br>* i.gensigset ? --> uses G_alloc_matrix<br>* i.smap ? --> uses G_alloc_matrix<br>* i.cca ? --> includes
gmath.h<br>* i.pca ? --> inclues gmath.h<br>* i.fft ? --> includes gmath.h<br>* i.ifft ? --> includes gmath.h<br>* i.zc ? --> includes gmath.h<br>* v.kernel ? --> includes gmath.h<br><br>* v.generalize (will be changed to use the much faster cholesky decomposition with bandwith optimization)
<br></div><br>
This list is incomplete. <br><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Soeren - could you email to the dev list or at least to PSC the<br>comparison of different solver when used with
v.surf.rst? (if you<br>don't have it on-hand - I can post it - it may be even useful to put<br>it on a related wiki page - it is a useful reminder how much<br>difference there is for different solvers).</blockquote><div>
<br>I'm sorry, but i lost the mail i had send you, can you please post it for me?<br><br>Best regards<br>Soeren <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Helena<br><br><br>Helena Mitasova<br>Dept. of Marine, Earth and Atm. Sciences<br>1125 Jordan Hall, NCSU Box 8208,<br>Raleigh NC 27695<br><a href="http://skagit.meas.ncsu.edu/~helena/">http://skagit.meas.ncsu.edu/~helena/</a>
<br><br><br><br>On Sep 4, 2007, at 10:55 PM, Brad Douglas wrote:<br><br>> On Tue, 2007-09-04 at 10:05 +0200, Markus Neteler wrote:<br>>> Hi Arnulf,<br>>><br>>> On Tue, Sep 04, 2007 at 08:57:39AM +0200, Arnulf Christl wrote:
<br>>>> Hello,<br>>>> I wanted to send a friendly reminder of the open issues in the<br>>>> Wiki at:<br>>>> <a href="http://wiki.osgeo.org/index.php/">http://wiki.osgeo.org/index.php/</a>
<br>>>> GRASS_Incubation_Progress#Open_Issues<br>>>><br>>>> As far as I can see activity wrt to the incubation process has<br>>>> stopped<br>>>> altogether, there have been no edits in the Wiki for 3 months. I
<br>>>> have to<br>>>> report to the Incubation Committee in my function as mentor and<br>>>> they will<br>>>> again ask why incubation has stopped. What shall I tell them?<br>>><br>
>> that it didn't stop :) Indeed, we didn't update the Wiki as we<br>>> should. But currently we are replacing remaining "Numerical<br>>> Receipes in C"<br>>> code with new functions.
<br>><br>> BTW, I located more NR code in GRASS. The eigen and Jacobi<br>> routines use<br>> them. I've also discovered that the NR routines are inherently<br>> unstable, but that also applies to most OSS solutions.
<br>><br>> Both Soren and myself would like to replace the BLAS/LAPACK (Fortran<br>> code) libraries with ATLAS, a tuned C version. This also gets us away<br>> from the Fortran issues suffered by gcc4.<br>>
<br>> If there are no objections, I would like to go ahead and modify<br>> <a href="http://configure.in">configure.in</a> and include/ to reflect this. Soren has already<br>> created a<br>> good wrapper API for the functionality and has expanded it
<br>> extensively.<br>> I didn't note any objections when I queried the devel list, but I<br>> think<br>> this is sufficiently large enough to be voted on by the PSC.<br>><br>> I really can't complete my imagery/ and lib/gmath API changes until
<br>> ATLAS (or some equivalent..maybe even GSL?) has replaced existing<br>> BLAS/LAPACK.<br>><br>>> Some file headers may need update, too, as above page indicates.<br>><br>> I've been adding them to all files I've touched...and I've touched
<br>> quite<br>> a few lately.<br>><br>>>> I did hope that we might get GRASS through before FOSS4G. Any<br>>>> chance? There<br>>>> is really not much left to do.<br>>><br>>> That would be an excellent milestone.
<br>><br>> Agreed.<br>><br>><br>> --<br>> 73, de Brad KB8UYR/6 <rez touchofmadness com><br>><br>> _______________________________________________<br>> grass-psc mailing list<br>> <a href="mailto:grass-psc@grass.itc.it">
grass-psc@grass.itc.it</a><br>> <a href="http://grass.itc.it/mailman/listinfo/grass-psc">http://grass.itc.it/mailman/listinfo/grass-psc</a><br></blockquote></div><br>