Hello,
I am using Grass 7.0 through Python and Pygrass (from outside Grass without starting it) on Linux (Debian GNU/Linux 7.6 (wheezy)) .
I don’t understand why Grass seems to get stuck on the following Python command :
r.composite(red=“B4”,green=“B3”,blue=“B2”,output=“mycomposite”,quiet=QUIET,overwrite=OVR)
Here is the information message coming from Grass :
Creating color table for output raster map… 0…6…12…18…25…31…37…43…50…56…62…68…75…81…87…93…100 Writing raster map … 0…
I checked the process and memory usage and apparently Grass uses about 100% of the CPU time and only uses half of the memory available.
Would there be a way to have more debug / warning information to understand what Grass is doing?
Thanks
Pietro2
February 11, 2015, 9:42am
2
Dear Pierric,
On Wed, Feb 11, 2015 at 10:02 AM, Pierric de Laborie
I don't understand why Grass seems to get stuck on the following Python
r.composite(red="B4",green="B3",blue="B2",output="mycomposite",quiet=QUIET,overwrite=OVR)
Have you tried to run the same command in BASH in a normal GRASS
if yes, can you run a python interpreter inside the GRASS shell and
Just some ideas to understand where could be the problem.
All the best
Pietro
I have just tried to start the same command from the GRASS shell (same machine and same GRASS database and location) and it gets stuck also.
GRASS 7.0.0svn (222):~/Grass_test > r.composite red=B5@PERMANENT green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
Running the same command in GRASS GUI (command shell) on Windows works fine and creates a composite in a few seconds. I am starting to think that it is due to the way I installed Grass on this Linux machine (I used the following link http://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Wheezy )
Thanks
···
2015-02-11 10:42 GMT+01:00 Pietro <peter.zamb@gmail.com >:
Dear Pierric,
On Wed, Feb 11, 2015 at 10:02 AM, Pierric de Laboriepierric.delaborie@gmail.com > wrote:
I don’t understand why Grass seems to get stuck on the following Python
r.composite(red=“B4”,green=“B3”,blue=“B2”,output=“mycomposite”,quiet=QUIET,overwrite=OVR)
Have you tried to run the same command in BASH in a normal GRASS
if yes, can you run a python interpreter inside the GRASS shell and
Just some ideas to understand where could be the problem.
All the best
Pietro
Pietro2
February 11, 2015, 11:15am
4
On Wed, Feb 11, 2015 at 11:51 AM, Pierric de Laborie
Running the same command in GRASS GUI (command shell) on Windows works finehttp://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Wheezy
you can have more info setting g.gisenv set="DEBUG=1" up to 5 I guess.
http://grasswiki.osgeo.org/wiki/GRASS_Debugging
Pietro
Dear Pietro,
I ran the same command with the highest level of verbose. Unfortunately it didn’t give much more information when blocking at the problematic step.
I also started the same command from GRASS GUI on another debian machine and it got stuck also. It is like the installation on Debian Wheezy doesn’t fully work (?)
GRASS 7.0.0svn (222):~/Grass_test > g.gisenv set=“DEBUG=5”
D1/1: G_set_program_name(): g.gisenv
GRASS 7.0.0svn (222):~/Grass_test > r.composite red=B5@PERMANENT green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
D1/5: G_set_program_name(): r.composite
···
2015-02-11 12:15 GMT+01:00 Pietro <peter.zamb@gmail.com >:
On Wed, Feb 11, 2015 at 11:51 AM, Pierric de Laboriepierric.delaborie@gmail.com > wrote:
Running the same command in GRASS GUI (command shell) on Windows works finehttp://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Wheezy
you can have more info setting g.gisenv set=“DEBUG=1” up to 5 I guess.
http://grasswiki.osgeo.org/wiki/GRASS_Debugging
Pietro
Dear Pierric,
g.region -p
It should be identical to the raster maps you are trying to compose.
g.region rast=B5
Best regards
2015-02-11 13:55 GMT+01:00 Pierric de Laborie <pierric.delaborie@gmail.com>:
Dear Pietro,
I ran the same command with the highest level of verbose. Unfortunately it
I also started the same command from GRASS GUI on another debian machine and
GRASS 7.0.0svn (222):~/Grass_test > g.gisenv set="DEBUG=5"
D1/1: G_set_program_name(): g.gisenv
GRASS 7.0.0svn (222):~/Grass_test > r.composite red=B5@PERMANENT
D1/5: G_set_program_name(): r.composite
2015-02-11 12:15 GMT+01:00 Pietro <peter.zamb@gmail.com>:
On Wed, Feb 11, 2015 at 11:51 AM, Pierric de Laboriehttp://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_7_on_Debian_Wheezy
you can have more info setting g.gisenv set="DEBUG=1" up to 5 I guess.
http://grasswiki.osgeo.org/wiki/GRASS_Debugging
Pietro
_______________________________________________http://lists.osgeo.org/mailman/listinfo/grass-user
This one input raster is huge. 840,000x394,000 = 331,000,000,000 pixels. That’s probably not what you want. If you have your region set to match this raster (rather than the others, which seem to be normal size) then that would certainly cause the machine to lock up.
···
On 11/02/2015 14:55, Pierric de Laborie wrote:
Dear Pietro,
I ran the same command with the highest level of verbose. Unfortunately it didn’t give much more information when blocking at the problematic step.
I also started the same command from GRASS GUI on another debian machine and it got stuck also. It is like the installation on Debian Wheezy doesn’t fully work (?)
GRASS 7.0.0svn (222):~/Grass_test > g.gisenv set=“DEBUG=5”
D1/1: G_set_program_name(): g.gisenv
GRASS 7.0.0svn (222):~/Grass_test > r.composite red=B5@PERMANENT green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
D1/5: G_set_program_name(): r.composite
Thanks for your input. This was probably the reason why. Grass defaulted the region to the raster with the highest resolution.
···
2015-02-12 9:23 GMT+01:00 Micha Silver <micha@arava.co.il >:
On 11/02/2015 14:55, Pierric de Laborie wrote:
Dear Pietro,
I ran the same command with the highest level of verbose. Unfortunately it didn’t give much more information when blocking at the problematic step.
I also started the same command from GRASS GUI on another debian machine and it got stuck also. It is like the installation on Debian Wheezy doesn’t fully work (?)
GRASS 7.0.0svn (222):~/Grass_test > g.gisenv set=“DEBUG=5”
D1/1: G_set_program_name(): g.gisenv
GRASS 7.0.0svn (222):~/Grass_test > r.composite red=B5@PERMANENT green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
D1/5: G_set_program_name(): r.composite
This one input raster is huge. 840,000x394,000 = 331,000,000,000 pixels. That’s probably not what you want. If you have your region set to match this raster (rather than the others, which seem to be normal size) then that would certainly cause the machine to lock up.
I wonder if there is any idea/intention to built in kind of a check mechanism for modules applicable to raster data. This, and the Εxtent concept as well, are most frequent problems/inattentions.
Nikos
On 12.02.2015 10:33, Pierric de Laborie wrote:
Thanks for your input. This was probably the reason why. Grass defaulted
2015-02-12 9:23 GMT+01:00 Micha Silver <micha@arava.co.il>:
On 11/02/2015 14:55, Pierric de Laborie wrote:
Dear Pietro,
I ran the same command with the highest level of verbose. Unfortunately
I also started the same command from GRASS GUI on another debian machine
GRASS 7.0.0svn (222):~/Grass_test >* g.gisenv set="DEBUG=5" *
D1/1: G_set_program_name(): g.gisenv
GRASS 7.0.0svn (222):~/Grass_test > * r.composite red=B5@PERMANENT
D1/5: G_set_program_name(): r.composite
This one input raster is huge. 840,000x394,000 = 331,000,000,000 pixels.
_______________________________________________http://lists.osgeo.org/mailman/listinfo/grass-user
--
On Thu, Feb 12, 2015 at 3:33 AM, Pierric de Laborie <
Grass defaulted the region to the raster with the highest resolution.
GRASS is not doing anything like that. The computation region is always set