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

[Seth Price]

For reference, this page seems to make a reasonable attempt at  
explaining the calculations:
http://re.jrc.ec.europa.eu/pvgis/solres/solmod3.htm

~Seth


On Jun 9, 2010, at 9:45 PM, Jaro Hofierka wrote:

>
>
> Seth Price wrote:
>> 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.
>
> In my opinion pj_do_proj() should be called only once, in main.c. I  
> don't see a real reason why it is also in rsunlib.c, so I believe it  
> should be commented out here. If I recall correctly rsunlib.c was  
> created by Thomas so I hope he can confirm this.
>
> Jaro
>
>
>>
>> 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
>>>>
>>
>>