Hi all.
I cannot get r.contour working. It always takes a lot of CPU, then
crashes. Anyone has more joy?
grass 7.0.1-2 from Debian sid.
Thanks.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
I cannot get r.contour working. It always takes a lot of CPU, then
crashes. Anyone has more joy?
grass 7.0.1-2 from Debian sid.I just used this yesterday without issue, but with 7.1. Are the region
settings correct and/or the increment between contours levels?
Mark
On Fri, Oct 16, 2015 at 5:32 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Hi all.
I cannot get r.contour working. It always takes a lot of CPU, then
crashes. Anyone has more joy?
grass 7.0.1-2 from Debian sid.
Please post your computational region settings (g.region -p).
Markus
Il 18/10/2015 11:48, Markus Neteler ha scritto:
On Fri, Oct 16, 2015 at 5:32 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Hi all.
I cannot get r.contour working. It always takes a lot of CPU, then
crashes. Anyone has more joy?
grass 7.0.1-2 from Debian sid.Please post your computational region settings (g.region -p).
Hi,
thanks for following this up. In fact, the region resolution was
unrealistically high, so it's my fault - sorry for the noise.
Nonetheless, there may be something interesting here:
* IMHO the module should exit more gracefully in case of too high
resolution, not crashing
* I did not use that particular location since long, and it is unclear
how the resolution got so high - if this would be due to some upgrades,
that would be unexpected and surprising. If I can collect more data on
this, I'll keep the list posted.
Thanks again.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
On Mon, Oct 19, 2015 at 9:01 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Il 18/10/2015 11:48, Markus Neteler ha scritto:
On Fri, Oct 16, 2015 at 5:32 PM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Hi all.
I cannot get r.contour working. It always takes a lot of CPU, then
crashes. Anyone has more joy?
grass 7.0.1-2 from Debian sid.Please post your computational region settings (g.region -p).
Hi,
thanks for following this up. In fact, the region resolution was
unrealistically high, so it's my fault - sorry for the noise.
Nonetheless, there may be something interesting here:
* IMHO the module should exit more gracefully in case of too high
resolution, not crashing
The problem is to "guess" how much memory resources are available
which change continuously (i.e. RAM is naturally static but its
allocation not).
* I did not use that particular location since long, and it is unclear
how the resolution got so high - if this would be due to some upgrades,
that would be unexpected and surprising. If I can collect more data on
this, I'll keep the list posted.
Just check the "history" file of the mapset. Some previously issued
command will have set the computational region.
A candidate might be a g.region vector=vmap with an additional
(unneeded) res=value call (maybe from "Processing"?).
Best
Markus
Il 19/10/2015 11:30, Markus Neteler ha scritto:
The problem is to "guess" how much memory resources are available
which change continuously (i.e. RAM is naturally static but its
allocation not).
sure - perhaps taking the total memory as an upper bound could mitigate
at least the most serious cases.
Just check the "history" file of the mapset. Some previously issued
command will have set the computational region.
A candidate might be a g.region vector=vmap with an additional
(unneeded) res=value call (maybe from "Processing"?).
right - interestingly enough, the history does not seem to be visible in
the current version of the grass qgis plugin - going to explore this.
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
On Mon, Oct 19, 2015 at 11:35 AM, Paolo Cavallini <cavallini@faunalia.it> wrote:
Il 19/10/2015 11:30, Markus Neteler ha scritto:
The problem is to "guess" how much memory resources are available
which change continuously (i.e. RAM is naturally static but its
allocation not).sure - perhaps taking the total memory as an upper bound could mitigate
at least the most serious cases.
In case it would be RAM + SWAP.
But to my limited knowledge it is not possible to easily know the
available memory on at least Windows (what I remember from past
discussions here).
Just check the "history" file of the mapset. Some previously issued
command will have set the computational region.
A candidate might be a g.region vector=vmap with an additional
(unneeded) res=value call (maybe from "Processing"?).right - interestingly enough, the history does not seem to be visible in
the current version of the grass qgis plugin - going to explore this.
thanks - it would be great to have it also there.
ciao
Markus