Re: [GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux
On Thu, Aug 19, 2010 at 3:35 AM, Glynn Clements wrote: > > Helena Mitasova wrote: > >> this is the same problem here - the problem is with python2.4 that is used >> as default >> and that does not include ctypes so you need to make symlink in grass to >> make sure >> it looks for python2.6 (which I have also installed) or there may be some >> other solution - >> You cannot remove python2.4 because it is used for system management. >> I did not have time to get it fully resolved yet. > > ctypes can be added as a third-party module in Python 2.3 and 2.4 (it > doesn't work on versions prior to 2.3, and it's part of the standard > library in 2.5 onwards). > > http://pypi.python.org/pypi/ctypes/1.0.2 > > Note: it requires libffi. Indeed, it was as easy as this: root> easy_install ctypes Now it compiles also with Python2.4. > However, installing Python >= 2.5 is likely to be easier, and will > also help if there are other compatibility issues (I don't know how > much testing gets done with 2.4 nowadays). Well, I hesitate to break the existing installation on our cluster. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.sim.water buffer overflow
2010/8/18, Markus Neteler : > On Wed, Aug 18, 2010 at 8:31 AM, Hanlie Pretorius > wrote: >> Hi, >> >> I'm posting here because I had no reaction on the users email list. > > > (Hint: if you post an example for a sampe data set like Spearfish or > North Carolina, then it is way easier to reproduce for us...) > >> I'm using GRASS64 RC6 on Linux 10.04 (64-bit) and I'm trying to run >> r.sim.water on a catchment about 5000 km2 in size. >> >> I started with a very fine resolution in my region (00:00:00.18) and >> got the following: >> - >> GRASS 6.4.0RC6 (world_wgs84):~ > r.sim.water >> elevin=lieb_dem_25m_clipped dxin=lieb_dem_25m_clipped_dx >> dyin=lieb_dem_25m_clipped_dy rain_val=2.0 manin_val=0.1 >> infil_val=13.0 depth=rsimwater.depth.18s disch=rsimwater.disch.18s >> default nwalk=600505650, rwalk=600505650.00 >> Killed > > Here for NC: > > g.region -d res=1000 -p > r.slope.aspect elevation=elevation dx=elevation_dx dy=elevation_dy > r.sim.water elevin=elevation dxin=elevation_dx dyin=elevation_dy \ > rain_val=2.0 manin_val=0.1 infil_val=13.0 \ > depth=rsimwater.depth.18s disch=rsimwater.disch.18s > ... > WARNING: Infiltration exceeds the rainfall rate everywhere! No overland > flow. > ... > Number of iterations = 0 cells > Time step = 129663.85 s > GRASS 6.4.0svn (nc_spm_08):~ > > > So no crash. But my region had way less pixels. > >> >> >> Since this resolution gives about 300 million cells in the region, I >> progressively coarsened the resolution, but I get buffer overflows >> even with just 2736 cells in the region (resolution = 00:01:00) > > The question is; how big are the internal tmp files? > Did you compile GRASS with large file support (--enable-largefile)? > I did not compile GRASS myself - have not tried that before - so I just used the version as the Ubuntu package manager installed it. I will try to find out how to compile GRASS and then use to options to enable large file support and the debugging symbols. >> Below is an example of the error I got at a resolution of 1 minute. >> The output at all resolutions (except 00:00:00.18) is similar: > > Second possibility is a bug when having LatLong coordinates. I > used a metric system. > > ... >> Time step = 0.00 s >> *** buffer overflow detected ***: r.sim.water terminated >> === Backtrace: = > > We would need a full backtrace (maybe not posted to the list) > which requires GRASS compiled with debugging symbols. > >> I can run the Spearfish example as shown in the r.sim.water manual >> page and that region contains 2654802 cells. > > Could you prepare a LatLong example with public data? I will get the Spearfish dataset into a LatLong location and see what happens when I run r.sim.water on that. I could place the Spearfish latlong location on a temporary web site if needed. > >> My DEM is not rectangular and I'm setting the region to a vector file >> that is an irregular boundary. So, the DEM has NULL values outside the >> vector boundary but inside the region. Could this be a problem? > > I don't think so. > > Markus > Thanks for the help. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_open_cell_old: unable to open raster map
On Thu, Aug 19, 2010 at 4:54 AM, James McCreight wrote: > Thanks Glynn- > that's exactly the problem. I've never heard of ulimit (I try not to keep so > many files open!). SO glad I know! We have some documentation here: http://grass.osgeo.org/wiki/Memory_issues Please expand it, if needed. thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_open_cell_old: unable to open raster map
Thanks Glynn- that's exactly the problem. I've never heard of ulimit (I try not to keep so many files open!). SO glad I know! Cheers, James On Wed, Aug 18, 2010 at 8:11 PM, Glynn Clements wrote: > > James McCreight wrote: > > > I've been forced in to development by this bug (ie i have a only a vague > > idea of what I'm doing). Help greatly appreciated (need to work on thesis > > not bugs). > > > > Summary: > > > > I've generated a location and a mapset, in this mapset I have files named > > input_file.0001, ... , input_file., ... , input_file.3313 > > > > I'm running r.hydro.CASC2 (used to be in GRASS), which i've built from > gipe > > add-on package. > > When it gets to approximately =1016, i get (i'll use the real rast > and > > mapset names, in case they are relevant): > > > > WARNING: Unable to open raster map > > > > If it's happening after ~1000 files, I strongly suspect you're hitting > an OS limit on the number of open file descriptors. It's common to > have a limit of 1024 open files per process. > > Run "ulimit -n" in the shell to determine the soft limit. If this is > too low, use "ulimit -Hn" to determine the hard limit. The soft limit > is what the OS actually checks against; you can change the soft limit > with e.g. "ulimit -n 5000", but you cannot increase it above the hard > limit, and a non-root user cannot increase the hard limit. > > On systems which use PAM, these limits are set in the file > /etc/security/limits.conf and any files in the directory > /etc/security/limits.d. This file is read by PAM (specifically, the > pam_limits.so module) at login, which sets the limits before dropping > root privilege and switching to the logged in user. > > If you have the ability to change that file, a line such as: > >* hardnofile 5000 > > will increase the hard limit to 5000. The limit will take effect for > subsequent logins (you can run "login" in an xterm to get a shell with > the new limits if you don't want to quit your current desktop > session). > > -- > Glynn Clements > -- - ** James McCreight mccreigh @at@ colorado.edu NASA Earth Science Fellow PhD Candidate, Water Resources and Environmental Fluid Mechanics University of Colorado, Boulder cell: (831) 261-5149 VoIP (to cell): (720) 897-7546 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_open_cell_old: unable to open raster map
James McCreight wrote: > I've been forced in to development by this bug (ie i have a only a vague > idea of what I'm doing). Help greatly appreciated (need to work on thesis > not bugs). > > Summary: > > I've generated a location and a mapset, in this mapset I have files named > input_file.0001, ... , input_file., ... , input_file.3313 > > I'm running r.hydro.CASC2 (used to be in GRASS), which i've built from gipe > add-on package. > When it gets to approximately =1016, i get (i'll use the real rast and > mapset names, in case they are relevant): > > WARNING: Unable to open raster map > If it's happening after ~1000 files, I strongly suspect you're hitting an OS limit on the number of open file descriptors. It's common to have a limit of 1024 open files per process. Run "ulimit -n" in the shell to determine the soft limit. If this is too low, use "ulimit -Hn" to determine the hard limit. The soft limit is what the OS actually checks against; you can change the soft limit with e.g. "ulimit -n 5000", but you cannot increase it above the hard limit, and a non-root user cannot increase the hard limit. On systems which use PAM, these limits are set in the file /etc/security/limits.conf and any files in the directory /etc/security/limits.d. This file is read by PAM (specifically, the pam_limits.so module) at login, which sets the limits before dropping root privilege and switching to the logged in user. If you have the ability to change that file, a line such as: * hardnofile 5000 will increase the hard limit to 5000. The limit will take effect for subsequent logins (you can run "login" in an xterm to get a shell with the new limits if you don't want to quit your current desktop session). -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux
Helena Mitasova wrote: > this is the same problem here - the problem is with python2.4 that is used as > default > and that does not include ctypes so you need to make symlink in grass to make > sure > it looks for python2.6 (which I have also installed) or there may be some > other solution - > You cannot remove python2.4 because it is used for system management. > I did not have time to get it fully resolved yet. ctypes can be added as a third-party module in Python 2.3 and 2.4 (it doesn't work on versions prior to 2.3, and it's part of the standard library in 2.5 onwards). http://pypi.python.org/pypi/ctypes/1.0.2 Note: it requires libffi. However, installing Python >= 2.5 is likely to be easier, and will also help if there are other compatibility issues (I don't know how much testing gets done with 2.4 nowadays). -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] failing wxVdigit in 6.4svn
Hi, in a build of the latest 6.4 SVN on Linux (amd64 debian/stable) wxVdigit gives errors in the wxGUI output tab that it could not be found. a little while ago it was ok. more details to follow, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] G_open_cell_old: unable to open raster map
Greetings-
I've been forced in to development by this bug (ie i have a only a vague
idea of what I'm doing). Help greatly appreciated (need to work on thesis
not bugs).
Summary:
I've generated a location and a mapset, in this mapset I have files named
input_file.0001, ... , input_file., ... , input_file.3313
I'm running r.hydro.CASC2 (used to be in GRASS), which i've built from gipe
add-on package.
When it gets to approximately =1016, i get (i'll use the real rast and
mapset names, in case they are relevant):
WARNING: Unable to open raster map
The offended block of code in r.hydro.CASC2D is
if((radar_fd[nfile]=G_open_cell_old(radar_file[nfile],mapset))<0)
{
sprintf(buf,"cannot open [%s]\n", radar_file[nfile]);
G_fatal_error(buf);
exit(1);
}
But the file is right in place, looking all fine and dandy. I've also tried
copying input_file.1015 to input_file.1016 using both the gui and on command
line. I still get no error for 1015, only for 1016. Also, if i comment
I'm at a complete loss. Is there a bug in G_open_cell_old? Something which
suggests otherwise: if i comment out the above code, CASC2D apparently runs
until that same map is to be read by G_get_map_row(), at which point I dont
even get a warning, but a seg fault. )
Thanks in advance.
James
--
-
**
James McCreight mccreigh @at@ colorado.edu
NASA Earth Science Fellow
PhD Candidate, Water Resources and Environmental Fluid Mechanics
University of Colorado, Boulder
cell: (831) 261-5149
VoIP (to cell): (720) 897-7546
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux
Markus, this is the same problem here - the problem is with python2.4 that is used as default and that does not include ctypes so you need to make symlink in grass to make sure it looks for python2.6 (which I have also installed) or there may be some other solution - You cannot remove python2.4 because it is used for system management. I did not have time to get it fully resolved yet. The problem should go away with the next release of RHEL which is in beta and should use python 2.6 (I think), Helena On Aug 18, 2010, at 3:40 PM, Markus Neteler wrote: > Hi, > > since Helena mentioned a problem on enterprise Linux, I tried to compile 6.5 > on > Scientific Linux, a RHEL derivate. > > Indeed, I get this problem: > > make[1]: Entering directory > `/home/neteler/software/grass65_release/lib/python/ctypes' > GISRC=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc65 > GISBASE=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu > PATH="/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:$PATH" > PYTHONPATH="" > LD_LIBRARY_PATH="/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/lib::/home/neteler/binaries/lib/" > LC_ALL=C ./ctypesgen.py --cpp "gcc -E -DPACKAGE=\""grasslibs"\" > -DPACKAGE=\""grasslibs"\" > -I/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include" > -lgrass_datetime > /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/datetime.h > /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/P_datetime.h > -o date.py > Traceback (most recent call last): > File "./ctypesgen.py", line 36, in ? >import ctypesgencore > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/__init__.py", > line 51, in ? >import parser > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/__init__.py", > line 17, in ? >from datacollectingparser import DataCollectingParser > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py", > line 10, in ? >import ctypesparser > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/ctypesparser.py", > line 15, in ? >from cparser import * > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/cparser.py", > line 19, in ? >import preprocessor > File > "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/preprocessor.py", > line 14, in ? >import ctypes > ImportError: No module named ctypes > make[1]: *** [date.py] Error 1 > make[1]: Leaving directory > `/home/neteler/software/grass65_release/lib/python/ctypes' > make: *** [default] Error 2 > > I also tried on GRASS 7, same thing. > > SciLin 5.2 provides python2.4. > > A fix would be appreciated. > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
While I echo some of Helena's sentiments, I find that (surprisingly) even some of my students still prefer the TclTk interface of the wxPython one. That aside, it doesn't bother me if TclTk comes as a default on Mac and Linux, as this gives people a very smooth transition into the new GUI. They can easily turn it on as the default when they are ready, but they can start out with what they are more used to with prior versions. For MS Windows there really hasn't been a widely used prior version. So starting out with wxPython will make future updates easier. Beyond this, the Mac version works fine. TclTk nviz is a richer environment than the embedded wxPython one. The wxPython digitizing module works well. AFAICT, the rest works fine too. Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Aug 18, 2010, at 11:58 AM, Helena Mitasova wrote: > > as Hamish has noted the choice of the default GUI is decided by whoever does > the binary package (?). > So my plea was pretty much for William to make wxGUI default in his Mac > binary. > People who run linux or compile GRASS from source are generally used to > customizing so that is > not so much an issue. It is really for newcomers who download GRASS binary > and start GRASS > and then the first thing they have to deal with is to change GUI. > The biggest issue that the newcomers had with the TclTk GUI (and that was > solved in wxGUI) was > - "why the map is not displayed when I load it into gis manager?" > All of this made starting with GRASS on Mac unexpectedly more difficult than > on MSWindows. > > At this point our semester has already started so I will have to deal with it > , and if I understand > the process correctly, 6.4 can be released with TclTk as default but with MSW > and Mac binaries packaged > with wxGUI as default. Of course, I would much prefer if the release was with > wxGUI as default. > > I don't have enough expertise on ctypes but we have troubles with it on our > enterprise linux > when compiling, but that is just a local problem, > > Helena > > > On Aug 18, 2010, at 2:29 PM, Markus Neteler wrote: > >> On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton >> wrote: >>> On Aug 17, 2010, at 11:24 PM, >>> wrote: >> ... >>> >>> I have to agree with Hamish here. We have delayed for over a year. Getting >>> GRASS to run robustly on Windows is worth it. But I'm not convinced that >>> moving ctypes into 6.4 would be all that easy. Watching the issues for >>> Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as >>> is now. Let's release it and make it a bit better with 6.4.1 >> >> Please also post your opinion about (Mac, Linux): >> - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as >> default; >> - Do first RC7 with wxGUI as default, then release 6.4.0, don't change >> with 6.4.1. >> ? >> >> Markus >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux
Hi, since Helena mentioned a problem on enterprise Linux, I tried to compile 6.5 on Scientific Linux, a RHEL derivate. Indeed, I get this problem: make[1]: Entering directory `/home/neteler/software/grass65_release/lib/python/ctypes' GISRC=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc65 GISBASE=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu PATH="/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:$PATH" PYTHONPATH="" LD_LIBRARY_PATH="/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/lib::/home/neteler/binaries/lib/" LC_ALL=C ./ctypesgen.py --cpp "gcc -E -DPACKAGE=\""grasslibs"\" -DPACKAGE=\""grasslibs"\" -I/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include" -lgrass_datetime /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/datetime.h /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/P_datetime.h -o date.py Traceback (most recent call last): File "./ctypesgen.py", line 36, in ? import ctypesgencore File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/__init__.py", line 51, in ? import parser File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/__init__.py", line 17, in ? from datacollectingparser import DataCollectingParser File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py", line 10, in ? import ctypesparser File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/ctypesparser.py", line 15, in ? from cparser import * File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/cparser.py", line 19, in ? import preprocessor File "/home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/preprocessor.py", line 14, in ? import ctypes ImportError: No module named ctypes make[1]: *** [date.py] Error 1 make[1]: Leaving directory `/home/neteler/software/grass65_release/lib/python/ctypes' make: *** [default] Error 2 I also tried on GRASS 7, same thing. SciLin 5.2 provides python2.4. A fix would be appreciated. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
I'll follow whatever is decided. I probably don't need to set a default GRASS_GUI in the Mac startup (just let init.sh handle the default), except that I do need to make *some* assumption about a setting to work around an application focus issue in OSX Tiger. I'll see if I can figure out a less intrusive test for the GUI setting. On Aug 18, 2010, at 1:58 PM, Helena Mitasova wrote: > > as Hamish has noted the choice of the default GUI is decided by whoever does > the binary package (?). > So my plea was pretty much for William to make wxGUI default in his Mac > binary. > People who run linux or compile GRASS from source are generally used to > customizing so that is > not so much an issue. It is really for newcomers who download GRASS binary > and start GRASS > and then the first thing they have to deal with is to change GUI. > The biggest issue that the newcomers had with the TclTk GUI (and that was > solved in wxGUI) was > - "why the map is not displayed when I load it into gis manager?" > All of this made starting with GRASS on Mac unexpectedly more difficult than > on MSWindows. > > At this point our semester has already started so I will have to deal with it > , and if I understand > the process correctly, 6.4 can be released with TclTk as default but with MSW > and Mac binaries packaged > with wxGUI as default. Of course, I would much prefer if the release was with > wxGUI as default. > > I don't have enough expertise on ctypes but we have troubles with it on our > enterprise linux > when compiling, but that is just a local problem, > > Helena - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
as Hamish has noted the choice of the default GUI is decided by whoever does the binary package (?). So my plea was pretty much for William to make wxGUI default in his Mac binary. People who run linux or compile GRASS from source are generally used to customizing so that is not so much an issue. It is really for newcomers who download GRASS binary and start GRASS and then the first thing they have to deal with is to change GUI. The biggest issue that the newcomers had with the TclTk GUI (and that was solved in wxGUI) was - "why the map is not displayed when I load it into gis manager?" All of this made starting with GRASS on Mac unexpectedly more difficult than on MSWindows. At this point our semester has already started so I will have to deal with it , and if I understand the process correctly, 6.4 can be released with TclTk as default but with MSW and Mac binaries packaged with wxGUI as default. Of course, I would much prefer if the release was with wxGUI as default. I don't have enough expertise on ctypes but we have troubles with it on our enterprise linux when compiling, but that is just a local problem, Helena On Aug 18, 2010, at 2:29 PM, Markus Neteler wrote: > On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton > wrote: >> On Aug 17, 2010, at 11:24 PM, >> wrote: > ... >> >> I have to agree with Hamish here. We have delayed for over a year. Getting >> GRASS to run robustly on Windows is worth it. But I'm not convinced that >> moving ctypes into 6.4 would be all that easy. Watching the issues for >> Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as >> is now. Let's release it and make it a bit better with 6.4.1 > > Please also post your opinion about (Mac, Linux): > - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as > default; > - Do first RC7 with wxGUI as default, then release 6.4.0, don't change > with 6.4.1. > ? > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Wed, Aug 18, 2010 at 7:39 PM, Michael Barton wrote: > On Aug 17, 2010, at 11:24 PM, > wrote: ... > > I have to agree with Hamish here. We have delayed for over a year. Getting > GRASS to run robustly on Windows is worth it. But I'm not convinced that > moving ctypes into 6.4 would be all that easy. Watching the issues for > Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as > is now. Let's release it and make it a bit better with 6.4.1 Please also post your opinion about (Mac, Linux): - Release 6.4.0 with TclTK default GUI and switch in 6.4.1 to wxGUI as default; - Do first RC7 with wxGUI as default, then release 6.4.0, don't change with 6.4.1. ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
On Aug 17, 2010, at 11:24 PM, wrote: > Date: Tue, 17 Aug 2010 20:26:42 -0700 (PDT) > From: Hamish > Subject: Re: [GRASS-dev] 6.4.0 blocker bugs > To: GRASS developers list > Message-ID: <64190.6834...@web110015.mail.gq1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > 2010/8/12 Markus Neteler: >>> So, there's no need to delay 6.4.0 for ctypes. We can add it in >>> 6.4.1, > > this option has my vote. Release now, as-is, and add ctypes for 6.4.1. > (ok, I've just gotten off an airplane, gimme 24 hours for final tests > on linux and windowsXP now that swig is removed :) > > did swig/examples/ get moved away before the rm? > > >>> or even make a separate package which works with 6.4.0 > > no thanks, too messy. Just release 6.4.1 with it in 3-5 weeks +1 RC. > > > > > re. default GUI, again my vote is to release now, as-is. > aka don't make major code or policy changes in the last moments before > release, no matter how attractive it seems short-term. > > > I would note that we are default tcl/tk; only the "downstream" packagers > for WinGrass and Mac have decided to change it to Wx in their packages. > (Ok, with the possible exception of j...@osgeo4w downstream is mostly > just us anyway, but technically speaking..) > > actually WinGrass is only default as for the icon it sticks on the desktop. > from the menu there is a "grass64 -tcltk" option and a "grass64 -wxpython" > option. Each will technically reset the default GUI each time you call it. > > Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with > ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with > the wxGUI. > > Switching the GUI is very easy from the Config menu, and even if it is > step 1. it shows the user that other avenues exist if they run into a > problem with e.g. the wx digitizer tool. > > > thanks, > Hamish > I have to agree with Hamish here. We have delayed for over a year. Getting GRASS to run robustly on Windows is worth it. But I'm not convinced that moving ctypes into 6.4 would be all that easy. Watching the issues for Windows compiling of GRASS 7 is worrisome in this regard. 6.4 works fine as is now. Let's release it and make it a bit better with 6.4.1 Michael C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.sim.water buffer overflow
I am guessing it is the latlong but I would have to try it out, Helena Mitasova Associate Professor Department of Marine, Earth and Atmospheric Sciences North Carolina State University Raleigh, NC 27695 hmit...@unity.ncsu.edu On Aug 18, 2010, at 11:03 AM, Markus Neteler wrote: > On Wed, Aug 18, 2010 at 8:31 AM, Hanlie Pretorius > wrote: >> Hi, >> >> I'm posting here because I had no reaction on the users email list. > > > (Hint: if you post an example for a sampe data set like Spearfish or > North Carolina, then it is way easier to reproduce for us...) > >> I'm using GRASS64 RC6 on Linux 10.04 (64-bit) and I'm trying to run >> r.sim.water on a catchment about 5000 km2 in size. >> >> I started with a very fine resolution in my region (00:00:00.18) and >> got the following: >> - >> GRASS 6.4.0RC6 (world_wgs84):~ > r.sim.water >> elevin=lieb_dem_25m_clipped dxin=lieb_dem_25m_clipped_dx >> dyin=lieb_dem_25m_clipped_dy rain_val=2.0 manin_val=0.1 >> infil_val=13.0 depth=rsimwater.depth.18s disch=rsimwater.disch.18s >> default nwalk=600505650, rwalk=600505650.00 >> Killed > > Here for NC: > > g.region -d res=1000 -p > r.slope.aspect elevation=elevation dx=elevation_dx dy=elevation_dy > r.sim.water elevin=elevation dxin=elevation_dx dyin=elevation_dy \ >rain_val=2.0 manin_val=0.1 infil_val=13.0 \ >depth=rsimwater.depth.18s disch=rsimwater.disch.18s > ... > WARNING: Infiltration exceeds the rainfall rate everywhere! No overland > flow. > ... > Number of iterations = 0 cells > Time step = 129663.85 s > GRASS 6.4.0svn (nc_spm_08):~ > > > So no crash. But my region had way less pixels. > >> >> >> Since this resolution gives about 300 million cells in the region, I >> progressively coarsened the resolution, but I get buffer overflows >> even with just 2736 cells in the region (resolution = 00:01:00) > > The question is; how big are the internal tmp files? > Did you compile GRASS with large file support (--enable-largefile)? > >> Below is an example of the error I got at a resolution of 1 minute. >> The output at all resolutions (except 00:00:00.18) is similar: > > Second possibility is a bug when having LatLong coordinates. I > used a metric system. > > ... >> Time step = 0.00 s >> *** buffer overflow detected ***: r.sim.water terminated >> === Backtrace: = > > We would need a full backtrace (maybe not posted to the list) > which requires GRASS compiled with debugging symbols. > >> I can run the Spearfish example as shown in the r.sim.water manual >> page and that region contains 2654802 cells. > > Could you prepare a LatLong example with public data? > >> My DEM is not rectangular and I'm setting the region to a vector file >> that is an irregular boundary. So, the DEM has NULL values outside the >> vector boundary but inside the region. Could this be a problem? > > I don't think so. > > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.sim.water buffer overflow
On Wed, Aug 18, 2010 at 8:31 AM, Hanlie Pretorius wrote: > Hi, > > I'm posting here because I had no reaction on the users email list. (Hint: if you post an example for a sampe data set like Spearfish or North Carolina, then it is way easier to reproduce for us...) > I'm using GRASS64 RC6 on Linux 10.04 (64-bit) and I'm trying to run > r.sim.water on a catchment about 5000 km2 in size. > > I started with a very fine resolution in my region (00:00:00.18) and > got the following: > - > GRASS 6.4.0RC6 (world_wgs84):~ > r.sim.water > elevin=lieb_dem_25m_clipped dxin=lieb_dem_25m_clipped_dx > dyin=lieb_dem_25m_clipped_dy rain_val=2.0 manin_val=0.1 > infil_val=13.0 depth=rsimwater.depth.18s disch=rsimwater.disch.18s > default nwalk=600505650, rwalk=600505650.00 > Killed Here for NC: g.region -d res=1000 -p r.slope.aspect elevation=elevation dx=elevation_dx dy=elevation_dy r.sim.water elevin=elevation dxin=elevation_dx dyin=elevation_dy \ rain_val=2.0 manin_val=0.1 infil_val=13.0 \ depth=rsimwater.depth.18s disch=rsimwater.disch.18s ... WARNING: Infiltration exceeds the rainfall rate everywhere! No overland flow. ... Number of iterations = 0 cells Time step = 129663.85 s GRASS 6.4.0svn (nc_spm_08):~ > So no crash. But my region had way less pixels. > > > Since this resolution gives about 300 million cells in the region, I > progressively coarsened the resolution, but I get buffer overflows > even with just 2736 cells in the region (resolution = 00:01:00) The question is; how big are the internal tmp files? Did you compile GRASS with large file support (--enable-largefile)? > Below is an example of the error I got at a resolution of 1 minute. > The output at all resolutions (except 00:00:00.18) is similar: Second possibility is a bug when having LatLong coordinates. I used a metric system. ... > Time step = 0.00 s > *** buffer overflow detected ***: r.sim.water terminated > === Backtrace: = We would need a full backtrace (maybe not posted to the list) which requires GRASS compiled with debugging symbols. > I can run the Spearfish example as shown in the r.sim.water manual > page and that region contains 2654802 cells. Could you prepare a LatLong example with public data? > My DEM is not rectangular and I'm setting the region to a vector file > that is an irregular boundary. So, the DEM has NULL values outside the > vector boundary but inside the region. Could this be a problem? I don't think so. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error in r.out.xyz
Hi, 2010/8/18 António Rocha : > Hello Glynn > I'm using the r.out.xyz's Module GUI. So I'm not inserting the output > filename by-and but using the filebrowser. I was expecting that the path > would be adequate for the Script. TCL/TK GUI or wxGUI? Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.0 blocker bugs
Hi, 2010/8/18 Hamish : > 2010/8/12 Markus Neteler: >>> So, there's no need to delay 6.4.0 for ctypes. We can add it in >>> 6.4.1, > > this option has my vote. Release now, as-is, and add ctypes for 6.4.1. > (ok, I've just gotten off an airplane, gimme 24 hours for final tests > on linux and windowsXP now that swig is removed :) > > did swig/examples/ get moved away before the rm? > > >>> or even make a separate package which works with 6.4.0 > > no thanks, too messy. Just release 6.4.1 with it in 3-5 weeks +1 RC. what's difference RC7 now and in 2 two weeks 6.4.0? > re. default GUI, again my vote is to release now, as-is. > aka don't make major code or policy changes in the last moments before > release, no matter how attractive it seems short-term. > > > I would note that we are default tcl/tk; only the "downstream" packagers > for WinGrass and Mac have decided to change it to Wx in their packages. > (Ok, with the possible exception of j...@osgeo4w downstream is mostly > just us anyway, but technically speaking..) > > actually WinGrass is only default as for the icon it sticks on the desktop. > from the menu there is a "grass64 -tcltk" option and a "grass64 -wxpython" > option. Each will technically reset the default GUI each time you call it. > > Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with > ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with > the wxGUI. > > Switching the GUI is very easy from the Config menu, and even if it is > step 1. it shows the user that other avenues exist if they run into a > problem with e.g. the wx digitizer tool. Changing default GUI in 6.4.1 released in 3-5 weeks seems to be strange to me. The question is whether to change default GUI in 6.4. I cannot tell if wxGUI is robust enough. It should decide the community. To summarize: 6.4.0 release now and in 3-5 weeks release 6.4.1 with quite *major* changes (ctypes added, default GUI changes) seems to me as an overkill. Just my opinion. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error in r.out.xyz
Hello Glynn How are you executing the command? If you're using the bash shell, the backslash is significant to the shell, so you have to either use a forward slash: I'm using the r.out.xyz's Module GUI. So I'm not inserting the output filename by-and but using the filebrowser. I was expecting that the path would be adequate for the Script. r.out.xyz input=...@permanent output=C:/Test_areas/26B.txt or quote the filename: r.out.xyz input=...@permanent 'output=C:\Test_areas\26B.txt' or escape the backslashes: r.out.xyz input=...@permanent output=C:\\Test_areas\\26B.txt If you're using the Windows shell (cmd.exe), it shouldn't have any problems with backslashes. I will give a try. Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
