Does latin/longin work for both locations that pj_do_proj() is called,
or just the one in main.c? It looked like some additional calculations
were done in the rsunlib.c call.
Would you be able to write some additional code that uses latin/longin
for the rsunlib.c call? I fear screwing it up because I'm not sure
what it's doing there.
Thanks,
Seth
On Jun 9, 2010, at 9:19 PM, Jaro Hofierka wrote:
Markus Neteler wrote:
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?
Hi Seth,
Maybe Thomas Huld can answer this better than me, but just a small
explanation how it should work.
r.sun effectivelly needs latitude,longitude for every cell. So
intention with latin/longin rasters was to get these values in case
you don't have a projection defined in grass. If you have a
cartesian projection defined in grass, you can get lat/lon on the
fly (e.g. using pj_do_proj() or any other method). So if you are
able to read the lat/lon values for every cell by other method then
you can disable this call.
Jaro
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
