[GRASS-dev] Resolved - Error in GRASS GIS 7.0 database

Erick_Opiyo · November 25, 2014, 5:54am

Hi Nikos,

Thanks for the reply.

When I run g.region and I give any raster name as an option, I still got the same error. I didn’t try changing the t-b resolution, though.

But after further looking around I found out that the file “WIND” inside my mapset was being changed every time, whenever a file was being edited in the database.

When I looked at it I found two entries for t-b resolution, I thought it’s supposed to be locked only for edit by one process at a time? After removing the duplicate entry the error when away.

Erick

neteler · November 25, 2014, 10:48am

On Tue, Nov 25, 2014 at 6:54 AM, Erick Opiyo <osgis.dev@gmail.com> wrote:
...

But after further looking around I found out that the file "WIND" inside my
mapset was being changed every time, whenever a file was being edited in the
database.

Is it possible that you are somehow affected by
https://trac.osgeo.org/grass/ticket/2230

? (... and how old is your installation - see "g.version -g")

Markus

Erick_Opiyo · November 25, 2014, 1:27pm

version=7.0.0svn
date=2014
revision=61465
build_date=2014-07-31
build_platform=x86_64-unknown-linux-gnu

Should I upgrade?

neteler · November 25, 2014, 1:52pm

On Nov 25, 2014 2:27 PM, “Erick Opiyo” <osgis.dev@gmail.com> wrote:

version=7.0.0svn
date=2014
revision=61465
build_date=2014-07-31
build_platform=x86_64-unknown-linux-gnu

Should I upgrade?

Yes please.

Markus

Erick_Opiyo · November 25, 2014, 2:44pm

After the upgrade to grass 7.1.svn(2014)-r62856

Most of my initial python scripts can’t run, I get the error below.

Traceback (most recent call last):
File “phenology/cloud_filter/grass_modis_filter_MODIS.py”, line 13, in
l = dict.keys(g.parse_command(“g.mlist”,type=“rast”))
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 465, in parse_command
res = read_command(*args, **kwargs)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 422, in read_command
process = pipe_command(*args, **kwargs)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 397, in pipe_command
return start_command(*args, **kwargs)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 358, in start_command
return Popen(args, **popts)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 62, in init
subprocess.Popen.init(self, args, **kwargs)
File “/usr/lib/python2.7/subprocess.py”, line 679, in init
errread, errwrite)
File “/usr/lib/python2.7/subprocess.py”, line 1249, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

I guess, the command g.parse_command is no longer valid in grass 7.1. I have see in some forums, reference to a new grass python module pygrass.

I assume this is now the default interface of python to grass. I will go through it and see if I can refactor my codes to use pygrass.

Thanks

neteler · November 25, 2014, 2:47pm

On Tue, Nov 25, 2014 at 3:44 PM, Erick Opiyo <osgis.dev@gmail.com> wrote:

After the upgrade to grass 7.1.svn(2014)-r62856

I would consider to stick to the 7.0 release branch (I intended an
update of your existing 7.0 installation).

See
http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS7.0
To extract the current 7.0.0 release branch version (upcoming stable),
which continuously receives bugfixes, use the command:

  svn checkout https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0
grass70_release
  #Subsequent updates:
  svn up

Markus

Markus_Metz · November 25, 2014, 2:59pm

On Tue, Nov 25, 2014 at 3:44 PM, Erick Opiyo <osgis.dev@gmail.com> wrote:

After the upgrade to grass 7.1.svn(2014)-r62856

Most of my initial python scripts can't run, I get the error below.

g.mlist no longer exists, it has been renamed to g.list. Same for
g.mremove -> g.remove.

Traceback (most recent call last):
  File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 13, in
<module>
    l = dict.keys(g.parse_command("g.mlist",type="rast"))
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 465,
in parse_command
    res = read_command(*args, **kwargs)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 422,
in read_command
    process = pipe_command(*args, **kwargs)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 397,
in pipe_command
    return start_command(*args, **kwargs)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 358,
in start_command
    return Popen(args, **popts)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 62,
in __init__
    subprocess.Popen.__init__(self, args, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

I guess, the command g.parse_command is no longer valid in grass 7.1.

No, it is g.mlist that causes the problem. This is true for GRASS 7.0 and 7.1

Markus M

I have

see in some forums, reference to a new grass python module pygrass.

I assume this is now the default interface of python to grass. I will go
through it and see if I can refactor my codes to use pygrass.

Thanks

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Erick_Opiyo · November 25, 2014, 3:36pm

I have replaced g.mlist with g.list.

And now I have two versions of grass 7.0-r62941 and 7.1-r62932

But, now I get another wired error, shown below: For both 7.0 and 7.1

7.0

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.Filtered.tiff> exists
Traceback (most recent call last):
File “phenology/cloud_filter/grass_modis_filter_MODIS.py”, line 72, in
R3,R2,R4,R1,R5,E3), overwrite=False)
File “/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py”, line 465, in parse_command
res = read_command(*args, **kwargs)
File “/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py”, line 425, in read_command
return handle_errors(returncode, stdout, args, kwargs)
File “/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py”, line 308, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None [‘r.mapcalc’, ‘expression=…some long expression…)’] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.

Note: The line 72 in the file grass_modis_filter_MODIS.py starts with g.parse_command(“r.mapcalc”, expression=…

7.1

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.Filtered.tiff> exists
Traceback (most recent call last):
File “phenology/cloud_filter/grass_modis_filter_MODIS.py”, line 72, in
R3,R2,R4,R1,R5,E3), overwrite=False)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 465, in parse_command
res = read_command(*args, **kwargs)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 425, in read_command
return handle_errors(returncode, stdout, args, kwargs)
File “/usr/local/grass-7.1.svn/etc/python/grass/script/core.py”, line 308, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None [‘r.mapcalc’, ‘expression=…some long expression…)’] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.

Thanks

Erick

neteler · November 25, 2014, 3:41pm

On Tue, Nov 25, 2014 at 3:59 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

On Tue, Nov 25, 2014 at 3:44 PM, Erick Opiyo <osgis.dev@gmail.com> wrote:

After the upgrade to grass 7.1.svn(2014)-r62856

Most of my initial python scripts can't run, I get the error below.

g.mlist no longer exists, it has been renamed to g.list. Same for
g.mremove -> g.remove.

For an overview, see

http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Renamedmodules

Markus

lucadelu · November 25, 2014, 3:42pm

On 25 November 2014 at 16:36, Erick Opiyo <osgis.dev@gmail.com> wrote:

I have replaced g.mlist with g.list.

And now I have two versions of grass 7.0-r62941 and 7.1-r62932

But, now I get another wired error, shown below: For both 7.0 and 7.1

7.0

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.Filtered.tiff> exists
Traceback (most recent call last):
  File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 72, in
<module>
    R3,R2,R4,R1,R5,E3), overwrite=False)
  File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
465, in parse_command
    res = read_command(*args, **kwargs)
  File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
425, in read_command
    return handle_errors(returncode, stdout, args, kwargs)
  File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
308, in handle_errors
    returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['r.mapcalc',
'expression=.......some long expression.....)'] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.

Note: The line 72 in the file grass_modis_filter_MODIS.py starts with
g.parse_command("r.mapcalc", expression=.....

7.1

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.Filtered.tiff> exists
Traceback (most recent call last):
  File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 72, in
<module>
    R3,R2,R4,R1,R5,E3), overwrite=False)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 465,
in parse_command
    res = read_command(*args, **kwargs)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 425,
in read_command
    return handle_errors(returncode, stdout, args, kwargs)
  File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 308,
in handle_errors
    returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['r.mapcalc',
'expression=.......some long expression.....)'] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.

can I suggest you to use the python interface to r.mapcalc [0]

http://grass.osgeo.org/grass71/manuals/libpython/script.html#script.raster.mapcalc

parse_command it should be used only to read the output of module
using the '-g' flag for shell style output, not to run modules that
are doing analysis

Thanks
Erick

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

martinl · November 25, 2014, 3:47pm

Hi,

2014-11-25 16:36 GMT+01:00 Erick Opiyo <osgis.dev@gmail.com>:

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.Filtered.tiff> exists
Traceback (most recent call last):
File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 72, in
<module>
R3,R2,R4,R1,R5,E3), overwrite=False)

overwrite=True

?

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

Erick_Opiyo · November 25, 2014, 4:06pm

@Luca,

I will try the python interface out.

@Martin,

If I set overwrite=True, then it would make my script overwrite an already processed images, I’m executing the script a numbers of times to match my machine CPU load average and the overwrite check, makes sure that a subsequent process skips an already processes image from a previously executed process.

I tried python multiprocess module, but it was slower than executing one process, so to fasten the process, since I’m processing almost 2 TB MODIS images, I have opted to execute the script a number of times.

Erick

martinl · November 25, 2014, 4:25pm

Hi,

2014-11-25 17:06 GMT+01:00 Erick Opiyo <osgis.dev@gmail.com>:

If I set overwrite=True, then it would make my script overwrite an already
processed images, I'm executing the script a numbers of times to match my
machine CPU load average and the overwrite check, makes sure that a
subsequent process skips an already processes image from a previously
executed process.

well, but it's related to the error

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.
Filtered.tiff> exists
...

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

annakrat · November 25, 2014, 6:49pm

On Tue, Nov 25, 2014 at 11:25 AM, Martin Landa <landa.martin@gmail.com>
wrote:

Hi,

2014-11-25 17:06 GMT+01:00 Erick Opiyo <osgis.dev@gmail.com>:

> If I set overwrite=True, then it would make my script overwrite an
already
> processed images, I'm executing the script a numbers of times to match my
> machine CPU load average and the overwrite check, makes sure that a
> subsequent process skips an already processes image from a previously
> executed process.

well, but it's related to the error

ERROR: output map <MOD13Q1.h16v05.2000081.EVI.
Filtered.tiff> exists

if you want to ignore it, you can catch the exception:

from grass.exceptions import CalledModuleError
...

try:
# call mapcalc
except CalledModuleError:
pass

Anna

...

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev