On Wed, Jun 9, 2010 at 6:00 PM, Glynn Clements <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
