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

[Seth Price]

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