Using wingrass 7 svn here and I'm seeing an error in v.surf.rst saying
that the input window changed while reading maps.
Below is the entire command output. The strip of data I'm
interpolating is in a diagonal orientation so I believe that's why I'm
seeing a lot of warnings about "taking too long to find points". I'm
also using a mask. I believe Carlos Grohmann mentioned the same
problem back in feb/2011 [1]
(Sun Jun 10 10:40:11 2012)
v.surf.rst -z input=ground_11_01@PERMANENT layer=1 elev=dtm11_daniel
maskmap=duke_mask@PERMANENT tension=50. smooth=2
Reading features from vector map ...
Strip exists with insufficient data
Ignoring 148872 points (too dense)
Number of points from vector map 248952
Number of points being used 100080
Bitmap mask created
Processing segments...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
G_ludcmp() failed! n=0 d=0.00
G_ludcmp() failed! n=0 d=0.00
G_ludcmp() failed! n=0 d=0.00
ERROR: Input window changed while maps are open for read
(Sun Jun 10 11:06:42 2012) Command finished (26 min 30 sec)
On Sun, Jun 10, 2012 at 11:15 AM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:
Hi all,
Using wingrass 7 svn here and I'm seeing an error in v.surf.rst saying
that the input window changed while reading maps.
Below is the entire command output. The strip of data I'm
interpolating is in a diagonal orientation so I believe that's why I'm
seeing a lot of warnings about "taking too long to find points". I'm
also using a mask. I believe Carlos Grohmann mentioned the same
problem back in feb/2011 [1]
(Sun Jun 10 10:40:11 2012)
v.surf.rst -z input=ground_11_01@PERMANENT layer=1 elev=dtm11_daniel
maskmap=duke_mask@PERMANENT tension=50. smooth=2
Reading features from vector map ...
Strip exists with insufficient data
Ignoring 148872 points (too dense)
Number of points from vector map 248952
Number of points being used 100080
Bitmap mask created
Processing segments...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
Taking too long to find points for interpolation - please change the
region to area where your points are. Continuing calculations...
G_ludcmp() failed! n=0 d=0.00
G_ludcmp() failed! n=0 d=0.00
G_ludcmp() failed! n=0 d=0.00
ERROR: Input window changed while maps are open for read
(Sun Jun 10 11:06:42 2012) Command finished (26 min 30 sec)
does the output look ok?
what if you change your region slightly? (e.g. round it outwards to nice
whole numbers with 'g.region -a res=100' followed by resetting back to
your original resolution with 'g.region res=$orig')
If you compiled grass7 with OpenMP support, try 'make distclean' +
recompiling without and see if you still get the error. You might be able
to try the same without recompiling by doing
export OMP_NUM_THREADS=1
on the command line before v.surf.rst (on the same command line shell).
the specific error messages is from lib/rst/interp_float/matrix.c
+ lib/gmath/lu.c. I guess a matrix with 0 elements counts as 'singular'
and so can't be decomposed. (and so I suspect it is happening before the
OpenMP pragmas are reached, so that could be a red herring)
The output did look fine.
I reduced the region a bit and rounded the resolution and now I don't
see the message. But I'm almost sure that my old region settings had
round resolution and coordinates.
As for compiling, I'm using the WinGrass 7 binaries so I can't do much
about it. I don't have a build environment set up in my win machine.
Daniel
On Mon, Jun 11, 2012 at 2:09 AM, Hamish <hamish_b@yahoo.com> wrote:
Daniel wrote:
As an update, if I remove the mask raster option, the interpolation
finishes ok but it gives me the message at the end...
does the output look ok?
what if you change your region slightly? (e.g. round it outwards to nice
whole numbers with 'g.region -a res=100' followed by resetting back to
your original resolution with 'g.region res=$orig')
If you compiled grass7 with OpenMP support, try 'make distclean' +
recompiling without and see if you still get the error. You might be able
to try the same without recompiling by doing
export OMP_NUM_THREADS=1
on the command line before v.surf.rst (on the same command line shell).
the specific error messages is from lib/rst/interp_float/matrix.c
+ lib/gmath/lu.c. I guess a matrix with 0 elements counts as 'singular'
and so can't be decomposed. (and so I suspect it is happening before the
OpenMP pragmas are reached, so that could be a red herring)