Re: [GRASS-dev] GRASS GIS nightly builds
On Mon, Feb 25, 2013 at 2:49 AM, Newcomb, Doug doug_newc...@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.76S: 482704.72 | E: 580721.99W: 492486.01 | B: 1083.51T: 5558.44 I get the following 20ft resolution surface using v.usrf.bspline bspline surface: | |N: 693610S: 482260 Res: 19.99905375 |E: 580722W: 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: 693610S: 482260 Res: 19.99905375 |E: 580722W: 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS nightly builds
On Mon, Feb 25, 2013 at 6:14 AM, Hamish hamis...@yahoo.com wrote: Hi, for v.surf.bspline my plan was to put each of the data subregions in their own thread Be aware that the order of the subregions matters right now. You will need to rewrite lib/lidar and all modules that use the lidarlib in order to change that and be able to put subregions into their own threads. Be aware that disk I/O is not thread safe, you would need to read input data for each subregion into a separate temp file with a unique file descriptor per thread. Markus M ; for v.surf.rst my plan was to put each of the quadtree squares into their own thread. Since each thread introduces a finite amount of time to create and destroy, the goal is to make fewer, longer running ones. Anything more than ~ an order of mangnitude more that the number of cores you have is unneeded overhead. e.g., processing all satellite bands at the same time is a nice efficient win. If you process all 2000 rows of a raster map in 2000 just-an-instant-to-complete threads, the create/destroy overhead to thread survival time really takes its toll. Even as thread creation/destruction overheads become more efficiently handled by the OSs and compilers, the situation will still be the same. The interesting case is OpenCL, where your video card can run 500 GPU units.. Hamish ___ 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] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Keywords: location wizard |Platform: Unspecified Cpu: x86-64 | -+-- Comment(by glynn): Replying to [comment:8 mlennert]: Is there a possibility to call a Python equivalent of G_legal_name() ? I don't know whether there's anything already in wxGUI, but I've added a legal_name() function to grass.script.core. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1889#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Keywords: location wizard |Platform: Unspecified Cpu: x86-64 | -+-- Comment(by wenzeslaus): In r55231 I added some doc for r55229 but actually, I don't understand the issue completely. I know about ticked #1293 and I can see that functions G_legal_filename or G_check_input_output_name (file legal_name.c) are used only on a few places (according to grep and programming manual). There is some check in G_parser function because it is not possible to create map with dot or slash but probably G_legal_filename is not used. (There is a warning which is reported twice but that is another issue.) I've tried to create map with non-latin characters but I'm not able to do it. wxGUI fails with some bugs and command line (Bash Shell) does not accept my characters and it does some other things instead such as cleaning the line. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1889#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] georeferencing using GRASS 6.4.2 in Windows
My apologies if I am asking the wrong group the wrong questions, but I am new to GRASS, have uploaded a rasta file (tiff), have created a group file, and have then tried to use ‘georectify’ to begin a georeferencing sequence. The problem I have is that when I call up the group file, nothing displays. My web searches suggest that there might be an unresolved glitch in the GRASS/Windows interface that needs to be circumvented, but what might be done is beyond me at the moment. Any similar experiences, any guidance? Colin. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] georeferencing using GRASS 6.4.2 in Windows
My apologies if I am asking the wrong group the wrong questions, but I am new to GRASS, have uploaded a rasta file (tiff), have created a group file, and have then tried to use ‘georectify’ to begin a georeferencing sequence. The problem I have is that when I call up the group file, nothing displays. My web searches suggest that there might be an unresolved glitch in the GRASS/Windows interface that needs to be circumvented, but what might be done is beyond me at the moment. Any similar experiences, any guidance? can you try a more recent version? http://grass.osgeo.org/grass64/binary/mswindows/native/ = WinGRASS-6.4.3RC2-1-Setup.exe or http://grass.osgeo.org/download/software/ms-windows/ = SVN nightly winGRASS 6 builds - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/georeferencing-using-GRASS-6-4-2-in-Windows-tp5036990p5036999.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Geomorphons and extension manager
I'm having similar problems with the extension manage on the Mac currently and filed a bug report. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Feb 26, 2013, at 10:40 AM, grass-user-requ...@lists.osgeo.orgmailto:grass-user-requ...@lists.osgeo.org wrote: From: Robert Andrew Brown brown...@purdue.edumailto:brown...@purdue.edu Subject: [GRASS-user] Geomorphons and extension manager Date: February 26, 2013 10:20:42 AM MST To: grass-u...@lists.osgeo.orgmailto:grass-u...@lists.osgeo.org Cc: Phillip Owens prow...@purdue.edumailto:prow...@purdue.edu To whom it may concern, I am trying to use extension manager in grass to install geomrphons. However, I am having trouble with the extension manager(error below). I emailed the geomorphon developer Jarek Jasiewicz(See Below) and he suggest I contact the GRASS-Users forum. Please advise, -Robert Brown From: JASIEWICZ Jarosław jar...@amu.edu.plmailto:jar...@amu.edu.pl Subject: Re: Geomorphons Date: February 26, 2013 11:56:20 AM EST To: brown...@purdue.edumailto:brown...@purdue.edu On 02/26/2013 05:21 PM, brown...@purdue.edumailto:brown...@purdue.edu wrote: Dear Sir, I use grass on my Mac OS X 10.8.2. I have been trying to compile grass to install the add-on Geomorphons. However, it is overwhelming to compile grass from source code as I have very little experience compiling programs. When I saw that your Geomorphons algorithm was part of the grass 7.0 add-ons I was pleased and tried to use the extension manager to add it to my grass add-on repository, however, I get an several errors which I have posted below. Any Suggestions? # g.extension extension=r.geomorphon/ operation=add Fetching r.geomorphon/ from GRASS-Addons SVN (be patient)... Compiling... In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' In file included from geom.c:1: local_proto.h:1:20: error: stdlib.h: No such file or directory local_proto.h:2:20: error: string.h: No such file or directory local_proto.h:3:18: error: math.h: No such file or directory local_proto.h:4:27: error: grass/glocale.h: No such file or directory local_proto.h:5:23: error: grass/gis.h: No such file or directory local_proto.h:6:26: error: grass/raster.h: No such file or directory In file included from geom.c:1: local_proto.h:56: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:66: error: expected specifier-qualifier-list before 'RASTER_MAP_TYPE' local_proto.h:74: error: expected specifier-qualifier-list before 'CELL' local_proto.h:139: error: expected declaration specifiers or '...' before 'RASTER_MAP_TYPE' local_proto.h:140: error: expected ')' before '*' token geom.c: In function 'exposition': geom.c:146: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'extends': geom.c:206: warning: incompatible implicit declaration of built-in function 'fabs' geom.c: In function 'shape': geom.c:232: warning: incompatible implicit declaration of built-in function 'atan' geom.c:236: warning: incompatible implicit declaration of built-in function 'sin' geom.c:237: warning: incompatible implicit declaration of built-in function 'cos' lipo: can't figure out the architecture type of: /var/folder s/wc/2dv9njw93k3bfyy5ppkw022hgn/T//ccESKY4a.out make: *** [OBJ.x86_64-apple-darwin12.2.0/geom.o]
[GRASS-dev] [GRASS GIS] #1898: adding foss4g-na news item or link from the homepage
#1898: adding foss4g-na news item or link from the homepage --+- Reporter: hamish| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: Website Component: Website | Version: Keywords: foss4g, news |Platform: All Cpu: Unspecified | --+- Hi, since the method of administering the new homepage, or even what CMS it might be using, is completely unknown to me, I would request that whoever is now looking after that consider to add something about the upcoming FOSS4G-NA conference to the front page. - http://foss4g-na.org - http://foss4g-na.org/wp-content/themes/Archive/img/logo.png thanks a bunch, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/1898 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1762: g.extension fails again on Mac (was: g.extension fails again)
#1762: g.extension fails again on Mac ---+ Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.3 Component: Addons | Version: svn-releasebranch64 Keywords: |Platform: MacOSX Cpu: OSX/Intel | ---+ Comment(by hamish): Hi, Was this the shell script version from the command line, or the python version of g.extension from the wxGUI? Does installing a shell or python script addon (as opposed to a compiled C code one) work? Is Xcode installed? Do newer versions of Xcode include GNU make along with LLVM? Does the current MacGrass package ship the $GISBASE/include/ headers matching paths in $GISBASE/include/Make/*.make? thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1762#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: Problems uploading a group geareferencing rasta
-- Forwarded message -- From: Dr Colin Hindmarch colinhindma...@talktalk.net Date: Tue, 26 Feb 2013 22:08:48 - Subject: Problems uploading a group geareferencing rasta To: grass-dev-ow...@lists.osgeo.org Many thanks, I have sorted the problem by reloading the most up to date version of GRASS, and when I had a notice that I needed a “*.dill” file, I downloaded this then reloaded the new version of GRASS again. I am not sure what I did exactly, but it is up and running and letting get on with the stuff I know about. Again many thanks for all your advice. Colin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS nightly builds
Ok folks,
I am a bit confused now. After setting OMP_NUM_THREADS=1 and exporting, I
get
100%
v.surf.rst complete.
real 352m46.451s
user 341m14.196s
sys 2m16.477s
Over 100 minutes faster. So the multiple cores get in each other's way...
Recompiling without OpenMP.
Thanks!
Doug
On Mon, Feb 25, 2013 at 12:14 AM, Hamish hamis...@yahoo.com wrote:
Hi,
to test the efficiency (does 650% of the CPU go 6.5x as fast as
running 100% on a single core?) you can use the OMP_* environment
variables. from the bash command line:
# try running it serially:
OMP_NUM_THREADS=1
export OMP_NUM_THREADS
time g.module ...
# let OpenMP set number of concurrent threads to number of local CPU cores
unset OMP_NUM_THREADS
time g.module ...
then compare the overall system time to complete.
see http://grasswiki.osgeo.org/wiki/OpenMP#Run_time
if that is horribly inefficient, it will probably be more
efficient to run multiple (different) jobs serially, at the same
time. The bash wait command is quite nice for that, waits
for all backgrounded jobs to complete before going on.
for r.in.{xyz|lidar|mb} this works quite well for generating
multiple statistics at the same time, as the jobs will all want
to read the same part of the input file at the about the same
time, so it will still be fresh in the disk cache keeping I/O
levels low. (see the r3.in.xyz scripts)
for v.surf.bspline my plan was to put each of the data subregions
in their own thread; for v.surf.rst my plan was to put each of
the quadtree squares into their own thread. Since each thread
introduces a finite amount of time to create and destroy, the
goal is to make fewer, longer running ones. Anything more than ~
an order of mangnitude more that the number of cores you have is
unneeded overhead.
e.g., processing all satellite bands at the same time is a nice
efficient win. If you process all 2000 rows of a raster map in
2000 just-an-instant-to-complete threads, the create/destroy
overhead to thread survival time really takes its toll.
Even as thread creation/destruction overheads become more
efficiently handled by the OSs and compilers, the situation will
still be the same. The interesting case is OpenCL, where your
video card can run 500 GPU units..
Hamish
--
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior. Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] NViz - problem in the visualization of 3D objects
I have seen this problem - it is similar to issues with rendering the box point symbols and at some scales even for spheres. Carla, have you tried to move around the light - does it change anything? Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” On Feb 14, 2013, at 1:15 PM, Anna Kratochvílová wrote: On Thu, Feb 14, 2013 at 6:30 PM, Carla Rebelo crreb...@gmail.com wrote: Hi, I have footprint buildings and the height value (type double precision) of each footprint. v.info -t map=buildings@ nodes=250 points=0 lines=0 boundaries=243 centroids=88 areas=89 islands=8 faces=0 kernels=0 primitives=331 map3d=1 After the v.extrude step v.extrude --overwrite --verbose input=buldings@ output=buildings3D hcolumn=Height type=area v.info -t map=buildings3D@ nodes=646 points=0 lines=0 boundaries=0 centroids=0 areas=0 islands=0 faces=743 kernels=88 primitives=831 map3d=1 When I visualized the file 3D from NViz, I have seen some of the buildings with a black filling (it's black inside or the top of building is black) Is it a problem of rendering? Or a problem with the topology? Some of the buildings look ok? I've just tried a small example and it works for me . There could be a problem with the normal vectors of the faces. Unfortunately I don't know much about the topology of kernels. Regards, Anna Best regards, CR ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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
