Thanks all for trying to help out with this and all information and suggestions, much appreciated!
It is probably not related to incremental compilation issues. I had those in the past, even though I always use make clean and re-run the configuration file. So since then I regularly do a completely clean compilation, i.e., removing the complete grass folder in /usr/local/bin and downloading the grass source files again rather then updating. I did so for the latest compilation too.I I'll try if I can find anything in the log files and try the suggestions of Soeren. I will also try to run the same calculations using a new mapset and new data, to rule out corrupt data. On Sat, Aug 3, 2013 at 4:02 AM, Glynn Clements <gl...@gclements.plus.com>wrote: > > Paulo van Breugel wrote: > > > Sorry, pushed the short cut sending the email off too early.. What I > wanted > > to ask is, is there any way I can find out what kind of error I am > getting? > > Now, the only message is "Error". > > There are only a few possible causes of "Error reading raster data", > namely an error from lseek(), read(), G_zlib_read() or GDALRasterIO(), > or a short count returned from read(). > > Any of these can be caused by corrupted data, but that would normally > be repeatable. > > G_zlib_read() is only applicable to floating-point maps, while > GDALRasterIO() is only applicable to GDAL-linked maps (r.external). > > If it's a hardware error, it will be logged by the kernel. The log > files are usually in /var/log, but which errors go in which files > depends upon the distribution. > > If you're compiling from source, be sure to run "make clean" between > "svn update" and "make". Incremental compilation isn't reliable in the > general case. If "svn update" updates the configure script, be sure to > re-run configure before doing anything else. > > -- > Glynn Clements <gl...@gclements.plus.com> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev