<div dir="ltr"><div><br><br>On Fri, Dec 29, 2017 at 5:07 PM, Dylan Beaudette <<a href="mailto:dylan.beaudette@gmail.com">dylan.beaudette@gmail.com</a>> wrote:<br>><br>> Hi everyone,<br>><br>> First of all, thanks in advance for the r.sun.daily module which is a<br>> nice replacement for my amateurish attempts over the last 12 years.<br>><br>> I am currently working on an annual beam radiance map for a large<br>> geographic region, at 30m res: 70,953 x 46,964 cells. This is far too<br>> large for a single pass of r.horizon or r.sun on my machine so I have<br>> split the data into 5,000 x 5,000 cell tiles with 100 cells of<br>> overlap. This seems to be sufficient for my purposes and the edge<br>> effects are tolerable.<br>><br>> At 8-15 minutes / tile / day (r.sun) and 54 tiles this job calls for<br>> multiple CPU cores. All of the parallel processing that I use is (as<br>> far as I know) contained within the same region.<br>><br>><br>> I have had good success with running r.horizon in parallel via GNU<br>> parallel like this:<br>><br>> # 1: start angle<br>> # 2: angle step<br>> # 3: elevation tile<br>> seq 0 $step 330 | parallel --gnu --progress "bash make-hz-maps.sh {}<br>> $step $elev"<br>><br>> Which is just a wrapper around r.horizon and run in parallel "within" tiles.<br>><br>> Next, I run r.sun.daily (8 CPU cores) within tiles:<br>><br>> r.sun.daily --overwrite elevation=$elev aspect=$asp slope=$slope \<br>> start_day=1 end_day=365 beam_rad=$beam horizon_basename=hzangle<br>> horizon_step=$step nprocs=8<br>><br>><br>> The r.sun.daily modules finishes without error about 50-60% of the<br>> time, results look good. The other 50-40% of the the time I get this:<br>><br>><br>> ERROR: Error uncompressing raster data for row 2605 of<br>>        <r_sun_crop8255_beam_rad_tmp_352><br>> *** buffer overflow detected ***: g.message terminated<br>> ======= Backtrace: =========<br>> /lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7f8b9a70129f]<br>> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f8b9a79c83c]<br>> /lib/x86_64-linux-gnu/libc.so.6(+0x10d710)[0x7f8b9a79b710]<br>> /lib/x86_64-linux-gnu/libc.so.6(+0x10cc19)[0x7f8b9a79ac19]<br>> /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0xbc)[0x7f8b9a70961c]<br>> /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1cc5)[0x7f8b9a6d9905]<br>> /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7f8b9a79aca4]<br>> /usr/local/grass-7.5.svn/lib/<a href="http://libgrass_gis.7.5.svn.so">libgrass_gis.7.5.svn.so</a>(+0x1343c)[0x7f8b9aa6a43c]<br>> /usr/local/grass-7.5.svn/lib/<a href="http://libgrass_gis.7.5.svn.so">libgrass_gis.7.5.svn.so</a>(G_fatal_error+0xbf)[0x7f8b9aa6accf]<br>> g.message(main+0x254)[0x400dd4]<br>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f8b9a6aff45]<br>> g.message[0x400ea2]<br>><br>><br>> I can't seem to replicate the problem, as subsequent runs with the<br>> same parameters and in the same tile are successful! This leads me to<br>> think that:<br>><br>> * some aspect of this approach is not thread safe<br>> * there is something wrong with my computer<br>> * there is a subtle bug in the raster writing / reading code when<br>> invoked in parallel<br>><br>><br>> I have encountered similar raster reading errors in the past,<br>> typically in the context of parallel processing:<br>><br>> <a href="https://trac.osgeo.org/grass/ticket/2762">https://trac.osgeo.org/grass/ticket/2762</a><br>><br>> <a href="https://trac.osgeo.org/grass/ticket/2764">https://trac.osgeo.org/grass/ticket/2764</a><br>><br>> <a href="http://osgeo-org.1560.x6.nabble.com/Error-reading-raster-data-for-row-xxx-only-when-using-r-series-and-t-rast-series-td5229569i20.html">http://osgeo-org.1560.x6.nabble.com/Error-reading-raster-data-for-row-xxx-only-when-using-r-series-and-t-rast-series-td5229569i20.html</a><br>><br>> <a href="https://lists.osgeo.org/pipermail/grass-dev/2015-July/075691.html">https://lists.osgeo.org/pipermail/grass-dev/2015-July/075691.html</a><br>><br>><br>> Here is some information on my system and version of GRASS:<br>><br>>  ./configure  --enable-64bit --with-libs=/usr/lib --without-pthread<br>> --without-odbc --without-mysql --with-readline --with-cxx<br>> --enable-largefile --with-freetype<br>> --with-freetype-includes=/usr/include/freetype2 --with-sqlite<br>> --with-python --with-geos=/usr/local/bin/geos-config --without-opencl<br>> --with-opencl-includes=/usr/include/CL/ --with-postgres<br>> --with-postgres-includes=/usr/include/postgresql/<br>> --with-postgres-libs=/usr/lib/<br>> --with-proj-share=/usr/local/share/proj/<br>><br>> version=7.5.svn<br>> date=2017<br>> revision=r71964<br>> build_date=2017-12-21<br>> build_platform=x86_64-pc-linux-gnu<br>> build_off_t_size=8<br>><br>><br>> Any ideas?<br><br></div>Please try the patch attached to ticket #2764 helps to get closer to the problem.<br><div><br></div><div>Markus M</div><div><br></div><div>><br>> I haven't had a chance to inspect the maps in question as r.sun.daily<br>> deletes the intermediate pieces on error.<br>><br>> Thanks!<br>> Dylan<br>> _______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><br><br></div></div>