[GRASS-user] r.sun use - automaticcaly stopped process ?

[Markus Metz]

On Tue, Apr 23, 2013 at 6:24 AM, Hamish <hamish_b at yahoo.com> wrote:
> simogeo wrote:
>> As said before, I use Ubuntu 12.04 in 64bits.The
>> wikipage <http://grasswiki.osgeo.org/wiki/Large_raster_data_processing>   mentions
>> only memory usage limits for 32bits system. After your
>> first reply Markus, I thought the 2^31 memory limit would
>> also maybe affect 64 bits systems.
> ...
>> With res=5 or res=1 it's working well but with the raster
>> resolution (0.2) the process is killed again.
>
> Hi,
>
> just looking in the code, I see a few things which might be
> suspicious in the INPUT_part() function,
>   https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.sun/main.c#L761
> maybe something there needs to be off_t instead?
>
> but mainly I think it's just that the module wants a lot of RAM,
> and the process gets killed when it asks for too much.
>
That's why there is the numpartitions option. Try r.sun
numpartitions=<a number > 1>

HTH,

Markus M

>
> here are some tests on a few months old 6.4.svn build
> (6.4.3svn.50937) on 64bit linux.
>
> # Mode 2 (integrated daily irradiation) at spearfish
> g.region rast=elevation.10m res=${*}
> r.sun -s elevation.10m lin=2.5 alb=0.2 day=172 \
>    beam_rad=b.172 diff_rad=d.172 \
>    refl_rad=r.172 insol_time=it.172
>
> as you can see, allocating >4gb RAM works ok for me, so it
> is likely not a LFS/32/64bit problem.
>
> rows:       27960
> cols:       37980
> cells:      1061920800
> -> in swap, >16gb RAM, (~19gb?)
>
> rows:       22368
> cols:       30384
> cells:      679629312
> -> 12gb
>
> rows:       18640
> cols:       25320
> cells:      471964800
> -> 8.8g
>
> rows:       13980
> cols:       18990
> cells:      265480200
> -> 5GB
>
> rows:       6990
> cols:       9495
> cells:      66370050
> -> 1.2g
>
> rows:       2796
> cols:       3798
> cells:      10619208
> -> 0.2gb  time: 37m42s
>
> plotting it out, memory use seems to grow linearly with
> number of cells. from earlier experiments, time does as well.
>
> by my calcs, a 60000x60000 cell region would want ~64gb RAM.
> However it would take a long-long time to get there, as in
> the last example above, a bit bigger than 3000x3000 cells took
> half an hour on a few months old fast i7 cpu w/ 16GB ram.
>
> I don't think Seth's GPU OpenCL acceleration is going to help
> there, since GPU RAM is often limited and the I/O to it a bottle-
> neck, and even 8 or 16x faster than it w/multithreading would
> take would still take too long for Mode 2 daily integration runs.
>
> So I think your best bet is to use a coarser resolution, then
> make it finer until you hit a time or RAM limit. Do you have
> that fine of a DEM anyway? LiDAR often being binned to 2m cell
> size,..
>
>
> Hamish
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user