[GRASS-user] Simultaneous r.horizon processes

[Daniel Lee]

Hi Collin, Collin,

Alright, that's a lot of great input to respond to so get ready for it ;)

there is OpenCL GPU accel. support, but it has not yet been
> merged into grass 7. (mea culpa)
>

Okay, that's great to know. Has the project made any progress since last
year? Our software go-to guy, Johannes, had been working on it with Seth,
who had done a lot of work on it during GSoC at some point, but the last
I'd heard about it was that it still had some problems when run on a
graphic card. I believe it wasn't sure whether the problem was the old
graphic card that was being used or something in the code itself. On an
Intel processor it seemed to run okay, but neither of them wanted to
consider the version final at the point that I was still informed.


> for r.sun being run 365 (or whatever) times in a row the "poor
> man's" method is fine, in fact the r3.in.xyz script in addons
> is perhaps the most efficient multi-CPUing in grass to date.
> (to my surprise)
>

That's reassuring - I know what I've been doing up till now isn't very
elegant, but at least I can implement it ;)


> I've just read through the r.horizon code in devbr6 and I don't
> see anything which makes the module unable to be run multiple
> times in the same mapset. (no external region setting, no
> generically named temp files, no gratuitous use of grass library
> global variables)   ... are you running under NFS or similar as
> addressed by Markus's script? aka maybe the trouble is rooted
> elsewhere?
>

No, the process was running locally on my machine, pretty straightforward.
I really think the problem is with RAM; as you note below.


> 72000x72000, how much ram does r.horizon use?
> maybe processes are being killed as you run out of RAM.
> in that case set max num of parallel jobs so that it fits
> into memory without going into swap space instead of num of CPUs.
> and error handling in the script (test for '$? -ne 0') could
> help try failing runs again.
>

It definitely uses way too much RAM; Colin thinks that it's ~10GB /
r.horizon process, which means that one process would be too much for my
little machine with 8GB. I like your idea of programming recursively for $?
ne 0, that shouldn't be too hard.


> FWIW I've tentatively given up on using r.horizon, see the "r.sun
> commissioning trials" trac ticket and wiki page. since sun
> placement changes each day, and for sub degree placement of the
> sun you need so many horizon maps as to make the loading of them
> all more expensive than just re-calculating it on-the-fly but
> with the exact placement. (I generally try for slow exactness
> instead of fast processing time though, YMMV)
> but maybe I don't correctly understand what r.horizon is doing..
>

True, true. I guess for the time I'll just stick with r.sun -s. It is a
shame though, because I have to spatially partition the area. Collin has a
good suggestion down below on something that would be great, but for me it
sounds like a great idea that won't be implemented soon enough to use in
this project ;)

Is there any optimization tricks that we could do with either r.horizon or
> its equivalent in r.sun?  For example, distant mountains do not need to be
> in 0.5 meter resolution, as with Daniel's dataset, or 2 meters in mine.
>  10-30 meters is sufficient to provide shading 10km away.  It would be
> orders of magnitude faster to specify a 'regional' map for large scale
> topographic shading which would then be overlaid with a smaller tile of
> high resolution elevation.
>

The mentioned great suggestion - just reading that makes my mouth water ;)

I really want to just use r.sun and never use r.horizon again, but unless I
> can get access to a cluster with 10GB ram per node, I can't.  It just takes
> too long to process.
>

That's exactly my situation too.

Wow, I may have done the math wrong, but I think you would need ~10GB of
> RAM per r.horizon process to run your map without constraining the area.
> So, I would be inclined to agree with Hamish that you may be RAM
> constrained.   I have had some success using g.region to "tile" my dataset
> into rectangles that are long east-west  (sunrise-sunset) and short
> north-south (summer-winter), but I had to make sure I had at least 25%
> overlap to cover edge effects.


Yup, I think you're right. I guess it's back to g.region for the time
being, then overlapping my tiles and taking the lower values.

In any case a big thank you to everybody for the contributions and ideas.
Time to fire up my IDE ;) Wish ya'll a nice weekend...

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20120421/99275b05/attachment.html