[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