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

[Markus Neteler]

On Wed, Jun 9, 2010 at 6:00 PM, Glynn Clements <glynn at gclements.plus.com> wrote:
>
> 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.

For sure. I have added the authors in bcc who may have suggestions.

> 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.

The first thing to do may be contacting the authors... done with this email.

Markus