[GRASS-dev] r.sun and pj_do_proj() calls

Glynn Clements glynn at gclements.plus.com
Wed Jun 9 12:00:01 EDT 2010


Seth Price wrote:

> I'm working on translating r.sun to OpenCL to run on the GPU, but I've  
> hit a bit of a snag. I'm hoping y'all can help or at least tell me  
> what I'm looking at.
> 
> The root of it is that I can't call pj_do_proj() from within the  
> OpenCL kernel, so I need to pass that in from the outside. For  
> example, on line 1824 of main.c in the current SVN has us calculating  
> the lat/long if we aren't passed in files latin and longin. So for the  
> OpenCL version I'll need to make latin and longin arrays ahead of time  
> instead of calculating it in the loop.
> 
> The problem is in rsunlib.c at line 250. How can I avoid this  
> pj_do_proj() call? I was thinking that because I have the lat/long  
> coordinates for all points, I can use that on lines 255 & 256,  
> effectively changing G_projection() to return PROJECTION_LL and  
> avoiding going into the 'if' statement. I don't know if that will  
> work, though. I really don't know what's going on here enough to feel  
> comfortable changing the calculation.
> 
> Suggestions? Code?

I don't know the answer to this. But if no-one else does either, r.sun
should be disabled. An error is preferable to silently producing wrong
answers.

Using different mechanisms for projection in different places looks
really suspicious. If there's a good reason for doing so, it should be
clearly documented. If there isn't a good reason, it should be fixed. 
If no-one knows whether it's right or wrong, the module should be
disabled until we do know.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list