<br>Hello !!<br> <br> I am using cygwin 1.5.24 with postgres 8.0.7.<br> <br> when i n initializing the data directory i m having following problem<br><br> <font face="Arial, Helvetica, sans-serif">$ /usr/sbin/initdb -D /usr/local/pgsql/data <br><br>The files belonging to this database system will be owned by user "pawan".<br>This user must also own the server process. <br><br>The database cluster will be initialized with locale C.<br><br>modifica dei permessi sulla directory esistente /usr/local/pgsql/data ... ok<br>creazione directory /usr/local/pgsql/data/global ... ok<br>creazione directory /usr/local/pgsql/data/pg_xlog ... ok <br>creazione directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok<br>creazione directory /usr/local/pgsql/data/pg_clog ... ok<br>creazione directory /usr/local/pgsql/data/pg_subtrans ... ok<br>creazione directory /usr/local/pgsql/data/base ... ok <br>creazione directory /usr/local/pgsql/data/base/1 ...
ok<br>creazione directory /usr/local/pgsql/data/pg_tblspc ... ok<br>selecting default max_connections ... sh: line 1: 3576 Bad system call<br>"/usr/sbin/postgres.exe" -boot -x0 -F -c shared_buffers=500 -c max_connections=1 <br>00 template1 < "/dev/null" > "/dev/null" 2>&1<br>sh: line 1: 3796 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=250 -c max_connections=50 template1 < "/dev/null" > "/dev/null <br>" 2>&1<br>sh: line 1: 2580 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=200 -c max_connections=40 template1 < "/dev/null" > "/dev/null<br> " 2>&1<br>sh: line 1: 3092 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=150 -c max_connections=30 template1 < "/dev/null" > "/dev/null<br>"
2>&1 <br>sh: line 1: 1028 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=100 -c max_connections=20 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br> sh: line 1: 1616 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=50 -c max_connections=10 template1 < "/dev/null" > "/dev/null"<br> 2>&1<br>10 <br>selecting default shared_buffers ... sh: line 1: 1416 Bad system call "<br>/usr/sbin/postgres.exe" -boot -x0 -F -c shared_buffers=1000 -c max_connections=1<br>0 template1 < "/dev/null" > "/dev/null" 2>&1 <br>sh: line 1: 2492 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=900 -c max_connections=10 template1 < "/dev/null" >
"/dev/null<br>" 2>&1<br> sh: line 1: 612 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=800 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br>sh: line 1: 1756 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F <br>-c shared_buffers=700 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br>sh: line 1: 3656 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br> -c shared_buffers=600 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br>sh: line 1: 2156 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=500 -c max_connections=10 template1 < "/dev/null" > "/dev/null <br>" 2>&1<br>sh:
line 1: 2084 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=400 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br> " 2>&1<br>sh: line 1: 1572 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=300 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1 <br>sh: line 1: 2352 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=200 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br> sh: line 1: 3664 Bad system call "/usr/sbin/postgres.exe" -boot -x0 -F<br>-c shared_buffers=100 -c max_connections=10 template1 < "/dev/null" > "/dev/null<br>" 2>&1<br>sh: line 1: 424 Bad system
call "/usr/sbin/postgres.exe" -boot -x0 -F <br>-c shared_buffers=50 -c max_connections=10 template1 < "/dev/null" > "/dev/null"<br> 2>&1<br>50<br> child process is terminated by signal 12<br>initdb: removing data directory "/usr/local/pgsql/data"<br><br><br><br><br><br>I have down the following before initdb command<br><br>1. set CYGWIN=server<br><br>2. /usr/sbin/cygserver.exe &<br><br>and cygrunsrv is not required anymore for 8.0.x versions.<br><br><br>Thanks,<br> Pawan<br></font><br><b><i>grassuser-request@grass.itc.it</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Send grassuser mailing list submissions to<br> grassuser@grass.itc.it<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://grass.itc.it/mailman/listinfo/grassuser<br>or, via email, send a message with subject
or body 'help' to<br> grassuser-request@grass.itc.it<br><br>You can reach the person managing the list at<br> grassuser-owner@grass.itc.it<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of grassuser digest..."<br><br><br>Today's Topics:<br><br> 1. Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster commands<br> (Roy Sanderson)<br> 2. Re: Problem with slope modeling . (Dylan Beaudette)<br> 3. Re: Problem with slope modeling . (Maciej Sieczka)<br> 4. Re: Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster commands<br> (Glynn Clements)<br> 5. Re: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4,<br> 6.0, 6.2 raster commands (Helena Mitasova)<br> 6. Re: Problem with slope modeling . (Dylan Beaudette)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 30 Apr 2007 15:28:12 +0000<br>From: Roy Sanderson <R.A.Sanderson@newcastle.ac.uk><br>Subject:
[GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster<br> commands<br>To: grassuser@grass.itc.it<br>Message-ID: <3.0.3.32.20070430152812.009de6b0@popin.ncl.ac.uk><br>Content-Type: text/plain; charset="us-ascii"<br><br>Hello Everyone<br><br>I've been trying to persuade our users to stop working with Grass 4.3 and<br>Grass 5.4 for some time now, and as I have to upgrade the OS on our<br>applications server have told them that they now have no choice.<br><br>However, a couple of users stated that they preferred to use Grass 4.3 as<br>it was faster, and for large tasks, more stable than the newer versions. I<br>checked this on a map of 52,000 rows by 28,000 columns and commands like<br>r.mapcalc, r.clump, r.volume operated about 10x faster in Grass 4.3 than<br>the more recent versions.<br><br>This might simply arise from the age of the applications server OS (still<br>running RH7.3), or because I've mis-configured the newer versions of Grass.<br> For example, I did
not compile Grass 5 or 6 with large-file support<br>enabled, although the file sizes are only around 180Mb, but the speedy<br>performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps there's an<br>additional overhead associated with the introduction of nulls and<br>floating-points, which were major changes from 4.3 to 5.4. However, the<br>performance difference is still present when working with integer maps. As<br>I haven't benchmarked versions, and also because personally I only work<br>with Grass version 6, I hadn't spotted the differences until now.<br><br>Has anyone else noticed this issue?<br><br>Many thanks<br>Roy<br>----------------------------------------------------------------------------<br>-------<br>Roy Sanderson<br>Institute for Research on Environment and Sustainability<br>Devonshire Building<br>University of Newcastle<br>Newcastle upon Tyne<br>NE1 7RU<br>United Kingdom<br><br>Tel: +44 191 246 4835<br>Fax: +44 191 246
4999<br><br>http://www.ncl.ac.uk/environment/<br>r.a.sanderson@newcastle.ac.uk<br><br>----------------------------------------------------------------------------<br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Mon, 30 Apr 2007 09:03:47 -0700<br>From: Dylan Beaudette <dylan.beaudette@gmail.com><br>Subject: Re: [GRASS-user] Problem with slope modeling .<br>To: grassuser@grass.itc.it<br>Message-ID: <200704300903.47190.dylan.beaudette@gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Monday 30 April 2007 06:01, Radomir wrote:<br>> Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisał(a):<br>> > > Radomir wrote:<br>> > > > I'm preparing the slope and elevation map from digitised isolines.<br>> > > > I'm using v.surf.rst to do that with the following options:<br>> > > ><br>> > > > v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"<br>> > >
> dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"<br>> > > > maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300<br>> > > ><br>> > > > The screenshot from small part of resulting map is here:<br>> > > > http://mort.no-ip.org/screen.png<br>> > > ><br>> > > ><br>> > > > On this screen you can see the valley in the center. I expect that<br>> > > > the slope between two isolines on the bottom of the valley will be<br>> > > > similar. But it is changing and gives an effect of "wave" between<br>> > > > isolines.<br>> ><br>> > Mars wrote:<br>> > > I presume the Isolines are representative of Elevation.<br>> ><br>> > and the displayed raster, legend, and profile show the slope.<br>> > it might help to show a profile using the elevation map. (it is hard to<br>> > tell if the slope stays
monotonically increasing in your profile as<br>> > slope will always be positive)<br>> ><br>> ><br>> ><br>> > profiler notes:<br>> > - y-scale is ranged to max/min of map, not max/min of profile?<br>> > ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)<br>> > Not sure which is best. Both ways have some merit.<br>> ><br>> > - in your screenshot the axes tick labels are not formatted cleanly.<br>> > I've just prettified those in CVS, please test.<br>> ><br>> > - BUG: if profile ends outside of the raster map off in NULL-land,<br>> > the totaldistance calculation is calculated to the end of the arrows,<br>> > but the end of real data in the plot is stretched to the far right end<br>> > regardless. e.g.: Zoom out so your raster is a postage stamp sized box<br>> > in the middle, then make some profiles from map canvas corner to<br>> >
corner. The start of the data is positioned ok. Also it should break<br>> > the plot at NULL data, not draw a line beween the last known good data<br>> > either side of the NULLs.<br>> ><br>> > - it would be possible to add a title like "Profile for $mapname" at the<br>> > top of the profile. Is there demand for this? Better to have it in the<br>> > window title than on the plot itself?<br>> ><br>> > Maciek wrote:<br>> > > I had this problem too when interpolating DEM from contour lines with<br>> > > RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI<br>> > > add-ons page and let us know if the artifact hollow between 2 adjacent<br>> > > contour lines still remains. I'm not 100% sure it will help. It might.<br>> ><br>> > v.surf.rst is designed for semi-evenly distributed series of data points<br>> > (at least locally, it is fine for data density to
smoothly change), not<br>> > contour lines.<br>> ><br>> > running v.to.points + v.surf.rst tends to bias the surface to the<br>> > isolines. Output the treefile= segmentation map and curvature maps to<br>> > see the effect in detail. Also in the GRASS book, if you have access to<br>> > it.<br>> ><br>> > as Maciek wrote, you should get better results with r.surf.nnbathy, or<br>> > you can try r.surf.contour (see hints about that posted in the last day<br>> > or two to this list for r.surf.contour).<br>> ><br>> > You might try r.contour with your output raster map at levels half way<br>> > between your original isolines to get a nice visual check of how the<br>> > interpolation went. (create new contour lines 1/2 way between the<br>> > original ones and overlay them)<br>> ><br>> ><br>> ><br>> > Hamish<br>><br>> Maciek, Hamish, Mars,<br>> Thank you for
your comments.<br>><br>> I've interpolated isolines with use of r.surf.nnbathy:<br>><br>> r.surf.nnbathy alg=nn input=izolinie output=nn_elevation<br>><br>> unfortunately, the results are even worse that those which comes from<br>> RST method. After "translating" it into the slope map (r.slope.aspect) I<br>> have the following result:<br>><br>> http://mort.no-ip.org/grass/indexgrass.html<br>><br>> As You can see, I still have "waves" between isolines. On the graph you<br>> will find those "waves" really large.<br>><br>> The r.surf.contour methods gives much worse results then RST (see the<br>> Elevation graph).<br>><br>> I've run r.contour with my RST output map as Hamish suggested ( see the<br>> last image on the http://mort.no-ip.org/grass/indexgrass.html )<br>><br>> It was really interesting to analyse the output vector map. It seems<br>> that when the distance between two isolines is "large" GRASS "puts
the<br>> next isoline" very close to the previous and this is how the "waves"<br>> comes from.<br>><br>> What sholud I do next?? Please for comments and suggestions.<br>> Best Regards,<br><br>I do not know what is causing this behaviour, but there is a well-documented <br>problem with USGS dem data that causes similar artifacts:<br><br>(see the image at the bottom of the page)<br>http://169.237.35.250/~dylan/gdalwarp/image_matrix.html<br><br>dylan<br><br>-- <br>Dylan Beaudette<br>Soils and Biogeochemistry Graduate Group<br>University of California at Davis<br>530.754.7341<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 30 Apr 2007 19:31:01 +0200<br>From: Maciej Sieczka <tutey@o2.pl><br>Subject: Re: [GRASS-user] Problem with slope modeling .<br>To: dylan.beaudette@gmail.com<br>Cc: grassuser@grass.itc.it<br>Message-ID: <463627D5.8050802@o2.pl><br>Content-Type: text/plain; charset=ISO-8859-2<br><br>Dylan Beaudette
wrote:<br>> On Monday 30 April 2007 06:01, Radomir wrote:<br>>> Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisa�(a):<br>>>>> Radomir wrote:<br>>>>>> I'm preparing the slope and elevation map from digitised isolines.<br>>>>>> I'm using v.surf.rst to do that with the following options:<br>>>>>><br>>>>>> v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"<br>>>>>> dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"<br>>>>>> maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300<br>>>>>><br>>>>>> The screenshot from small part of resulting map is here:<br>>>>>> http://mort.no-ip.org/screen.png<br>>>>>><br>>>>>><br>>>>>> On this screen you can see the valley in the center. I expect that<br>>>>>> the slope between two
isolines on the bottom of the valley will be<br>>>>>> similar. But it is changing and gives an effect of "wave" between<br>>>>>> isolines.<br>>>> Mars wrote:<br>>>>> I presume the Isolines are representative of Elevation.<br>>>> and the displayed raster, legend, and profile show the slope.<br>>>> it might help to show a profile using the elevation map. (it is hard to<br>>>> tell if the slope stays monotonically increasing in your profile as<br>>>> slope will always be positive)<br>>>><br>>>><br>>>><br>>>> profiler notes:<br>>>> - y-scale is ranged to max/min of map, not max/min of profile?<br>>>> ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)<br>>>> Not sure which is best. Both ways have some merit.<br>>>><br>>>> - in your screenshot the axes tick labels are not formatted
cleanly.<br>>>> I've just prettified those in CVS, please test.<br>>>><br>>>> - BUG: if profile ends outside of the raster map off in NULL-land,<br>>>> the totaldistance calculation is calculated to the end of the arrows,<br>>>> but the end of real data in the plot is stretched to the far right end<br>>>> regardless. e.g.: Zoom out so your raster is a postage stamp sized box<br>>>> in the middle, then make some profiles from map canvas corner to<br>>>> corner. The start of the data is positioned ok. Also it should break<br>>>> the plot at NULL data, not draw a line beween the last known good data<br>>>> either side of the NULLs.<br>>>><br>>>> - it would be possible to add a title like "Profile for $mapname" at the<br>>>> top of the profile. Is there demand for this? Better to have it in the<br>>>> window title than on the plot
itself?<br>>>><br>>>> Maciek wrote:<br>>>>> I had this problem too when interpolating DEM from contour lines with<br>>>>> RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI<br>>>>> add-ons page and let us know if the artifact hollow between 2 adjacent<br>>>>> contour lines still remains. I'm not 100% sure it will help. It might.<br>>>> v.surf.rst is designed for semi-evenly distributed series of data points<br>>>> (at least locally, it is fine for data density to smoothly change), not<br>>>> contour lines.<br>>>><br>>>> running v.to.points + v.surf.rst tends to bias the surface to the<br>>>> isolines. Output the treefile= segmentation map and curvature maps to<br>>>> see the effect in detail. Also in the GRASS book, if you have access to<br>>>> it.<br>>>><br>>>> as Maciek wrote, you should get better
results with r.surf.nnbathy, or<br>>>> you can try r.surf.contour (see hints about that posted in the last day<br>>>> or two to this list for r.surf.contour).<br>>>><br>>>> You might try r.contour with your output raster map at levels half way<br>>>> between your original isolines to get a nice visual check of how the<br>>>> interpolation went. (create new contour lines 1/2 way between the<br>>>> original ones and overlay them)<br>>>><br>>>><br>>>><br>>>> Hamish<br>>> Maciek, Hamish, Mars,<br>>> Thank you for your comments.<br>>><br>>> I've interpolated isolines with use of r.surf.nnbathy:<br>>><br>>> r.surf.nnbathy alg=nn input=izolinie output=nn_elevation<br>>><br>>> unfortunately, the results are even worse that those which comes from<br>>> RST method. After "translating" it into the slope map (r.slope.aspect)
I<br>>> have the following result:<br>>><br>>> http://mort.no-ip.org/grass/indexgrass.html<br>>><br>>> As You can see, I still have "waves" between isolines. On the graph you<br>>> will find those "waves" really large.<br>>><br>>> The r.surf.contour methods gives much worse results then RST (see the<br>>> Elevation graph).<br>>><br>>> I've run r.contour with my RST output map as Hamish suggested ( see the<br>>> last image on the http://mort.no-ip.org/grass/indexgrass.html )<br>>><br>>> It was really interesting to analyse the output vector map. It seems<br>>> that when the distance between two isolines is "large" GRASS "puts the<br>>> next isoline" very close to the previous and this is how the "waves"<br>>> comes from.<br>>><br>>> What sholud I do next?? Please for comments and suggestions.<br>>> Best Regards,<br>> <br>> I do not know what is
causing this behaviour, but there is a well-documented <br>> problem with USGS dem data that causes similar artifacts:<br>> <br>> (see the image at the bottom of the page)<br>> http://169.237.35.250/~dylan/gdalwarp/image_matrix.html<br><br>Dylan,<br><br>Are you sure this is related? The material you mention refers to issues<br>connected with raster DEM re-projection. Radomir is concerned with a<br>comparison of different interpolation methods (with a specific input<br>such as contour lines), in regard to DEM's slope.<br><br>Maybe I'm missing something. Please excuse me and elaborate, if so.<br><br>Best,<br>Maciek<br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Mon, 30 Apr 2007 19:17:12 +0100<br>From: Glynn Clements <glynn@gclements.plus.com><br>Subject: Re: [GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0, 6.2 raster<br> commands<br>To: Roy Sanderson <R.A.Sanderson@newcastle.ac.uk><br>Cc: grassuser@grass.itc.it,
grass-dev@grass.itc.it<br>Message-ID: <17974.12968.328085.755096@cerise.gclements.plus.com><br>Content-Type: text/plain; charset=us-ascii<br><br><br>[CC to grass-dev]<br><br>Roy Sanderson wrote:<br><br>> I've been trying to persuade our users to stop working with Grass 4.3 and<br>> Grass 5.4 for some time now, and as I have to upgrade the OS on our<br>> applications server have told them that they now have no choice.<br>> <br>> However, a couple of users stated that they preferred to use Grass 4.3 as<br>> it was faster, and for large tasks, more stable than the newer versions. I<br>> checked this on a map of 52,000 rows by 28,000 columns and commands like<br>> r.mapcalc, r.clump, r.volume operated about 10x faster in Grass 4.3 than<br>> the more recent versions.<br>> <br>> This might simply arise from the age of the applications server OS (still<br>> running RH7.3), or because I've mis-configured the newer versions of
Grass.<br>> For example, I did not compile Grass 5 or 6 with large-file support<br>> enabled, although the file sizes are only around 180Mb, but the speedy<br>> performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps there's an<br>> additional overhead associated with the introduction of nulls and<br>> floating-points, which were major changes from 4.3 to 5.4. However, the<br>> performance difference is still present when working with integer maps. As<br>> I haven't benchmarked versions, and also because personally I only work<br>> with Grass version 6, I hadn't spotted the differences until now.<br><br>I strongly suspect that the support for nulls is to blame. The<br>implementation is really quite inefficient in several ways.<br><br>It doesn't help that the null file is repeatedly opened and closed<br>(the null bitmap is read in chunks of 8 rows at a time, with the file<br>being opened anew for each read). Depending upon the speed
of<br>filesystem calls (open(), access() etc) relative to actual I/O, that<br>could be a significant factor.<br><br>Keeping the null file open would eliminate that part of the overhead,<br>but would double the number of descriptors used. On older versions,<br>that would halve the maximum number of open maps, although that limit<br>has been eliminated in recent 6.3 CVS versions.<br><br>Also, that would only eliminate part of the overhead. Actually<br>decoding and embedding the null data is also non-trivial.<br><br>Embedding the nulls in the data file, eliminating the null bitmap<br>altogether, would eliminate all of the null overhead, but would also<br>either enlarge the files significantly or break compatibility.<br><br>The existing format is optimised for small, non-negative integers. <br>Each row is stored using only as many bytes are required for the<br>largest value, where all values are treated as unsigned (i.e. negative<br>values always require 4 bytes). The integer
value used for nulls is<br>0x80000000 (i.e. INT_MIN, -2^31); embedding this value directly would<br>cause many files to always use 4 bytes per cell when 1 byte would<br>otherwise be enough.<br><br>We could change the encoding to be more friendly to embedded nulls,<br>but that would break compatibility with earlier versions. AFAICT, a<br>6.3 integer raster can still be read by 4.3 (assuming that it uses RLE<br>rather than zlib compression), with any nulls being read as zeroes.<br><br>-- <br>Glynn Clements <glynn@gclements.plus.com><br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Mon, 30 Apr 2007 16:14:39 -0400<br>From: Helena Mitasova <hmitaso@unity.ncsu.edu><br>Subject: Re: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4,<br> 6.0, 6.2 raster commands<br>To: Glynn Clements <glynn@gclements.plus.com><br>Cc: grassuser@grass.itc.it, Roy Sanderson<br> <R.A.Sanderson@newcastle.ac.uk>, GRASS developers list<br>
<grass-dev@grass.itc.it><br>Message-ID: <2A41DE5D-FA9F-495E-9B39-57258C82B42C@unity.ncsu.edu><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br>Glynn,<br><br>does the null implementation affect also the runs with rasters that <br>have no nulls<br>and there is no MASK present? As I have recently written, I have<br>noticed what seems to be totally unrelated changes in performance in<br>v.surf.rst compared the 4.3 - mostly along the line of changing to <br>G_ludcmp<br>from an internal lineq solver, but it may be somewhere else.<br><br>10x faster is a huge difference - it may be worthwhile to find out<br>whether it is true for integer maps without nulls and whether it<br>is really nulls slowing it down so badly.<br><br>There were many discussions about the null implementation and as <br>Glynn correctly<br>points out the main driver for the current design was to sacrifice <br>the performance<br>to preserve the backwards compatibility.
Wishes of old users (many of <br>whom<br>contributed funds to GRASS development) were given very high priority.<br><br>Helena<br><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>http://skagit.meas.ncsu.edu/~helena/<br><br><br><br>On Apr 30, 2007, at 2:17 PM, Glynn Clements wrote:<br><br>><br>> [CC to grass-dev]<br>><br>> Roy Sanderson wrote:<br>><br>>> I've been trying to persuade our users to stop working with Grass <br>>> 4.3 and<br>>> Grass 5.4 for some time now, and as I have to upgrade the OS on our<br>>> applications server have told them that they now have no choice.<br>>><br>>> However, a couple of users stated that they preferred to use Grass <br>>> 4.3 as<br>>> it was faster, and for large tasks, more stable than the newer <br>>> versions. I<br>>> checked this on a map of 52,000 rows by 28,000 columns
and <br>>> commands like<br>>> r.mapcalc, r.clump, r.volume operated about 10x faster in Grass <br>>> 4.3 than<br>>> the more recent versions.<br>>><br>>> This might simply arise from the age of the applications server OS <br>>> (still<br>>> running RH7.3), or because I've mis-configured the newer versions <br>>> of Grass.<br>>> For example, I did not compile Grass 5 or 6 with large-file support<br>>> enabled, although the file sizes are only around 180Mb, but the <br>>> speedy<br>>> performance of 4.3 vs 5.4, 6.0 and 6.2.1 surprised me. Perhaps <br>>> there's an<br>>> additional overhead associated with the introduction of nulls and<br>>> floating-points, which were major changes from 4.3 to 5.4. <br>>> However, the<br>>> performance difference is still present when working with integer <br>>> maps. As<br>>> I haven't benchmarked versions,
and also because personally I only <br><br>=== message truncated ===</grass-dev@grass.itc.it></R.A.Sanderson@newcastle.ac.uk></glynn@gclements.plus.com></hmitaso@unity.ncsu.edu></glynn@gclements.plus.com></R.A.Sanderson@newcastle.ac.uk></glynn@gclements.plus.com></tutey@o2.pl></dylan.beaudette@gmail.com></R.A.Sanderson@newcastle.ac.uk></blockquote><br><BR><BR><DIV><STRONG>Pawan Joshi</STRONG> </DIV> <DIV> </DIV> <DIV><BR><BR> </DIV><p> 
<hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>