[MITgcm-devel] thsice_get_exf

[Patrick Heimbach]

Hi there,

a quick question:
Is there any fancy reason in S/R thsice_calc_thickn
not to declare array sizes explicitly as, e.g.
       _RL iceMask(1-OLx:sNx+OLx,1-OLy:sNy+OLy)
instead of currently
       _RL iceMask(siLo,SiHi,sjLo,sjHi)

TAF seems to choke on some of the indices, not yet sure why.
Problem goes away if I just put the indices explicitly.

-p.


On Oct 16, 2010, at 8:31 AM, Martin Losch wrote:

> Hi Jean-Michel,
>
> as it is now thsice_solve4temp vectorizes to about 84% (because  
> this loop within the iteration does not vectorize). While that's  
> not as good as it could be (normally 99% is easily reached), I do  
> not see it as a major problem. Obviously this loop could be more  
> efficient following your suggestions, but currently this routine  
> uses about 0.6% of the total time in my tests (only 100 timesteps),  
> after coming down from 4.2%, so I am quite OK with this right now.  
> Maybe add this later, if I get annoyed by incredibly slow sea ice  
> (o: but I don't think that this will become an issue.
>
> Martin
>
> On Oct 15, 2010, at 8:38 PM, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> I did remove those initialisations. Can't have them since they will
>> reset valid output when Tsrf had already converged (iceFlag=F).
>>
>> But I have a remark about your check-in message of  
>> thsice_solve4temp.F
>> (and tag-index) regarding iterate4Tsf :
>> I was suspecting it could cause some complications with TAF so
>> I disable it with "#ifndef ALLOW_AUTODIFF_TAMC".
>> I have a question: Could you compare the timing you get
>> when you disable this iterate4Tsf (like what is done with
>> ALLOW_AUTODIFF_TAMC, similar to your #ifdef SEAICE_VECTORIZE_LSR)
>> with the timing you currently have ? If with bring a good speed-up,
>> it could be added with an #ifdef ???_VECTORIZE_??? option.
>>
>> Cheers,
>> Jean-Michel
>>
>> On Fri, Oct 15, 2010 at 06:02:16PM +0200, Martin Losch wrote:
>>> Hi Jean-Michel,
>>>
>>> an interesting problem remains: initializing the output variables
>>>         flxExcSw(i,j) = 0. _d 0
>>>         dFlxdT  (i,j) = 0. _d 0
>>>         evapLoc (i,j) = 0. _d 0
>>>         dEvdT   (i,j) = 0. _d 0
>>> in the beginning of the routine thsice_get_exf, breaks the  
>>> verification experiment. I do not see why. Do you have any idea?  
>>> (and Patrick will need that for the adjoint, I am pretty sure)
>>>
>>> Have a good weekend.
>>>
>>> Martin
>>>
>>> On Oct 15, 2010, at 4:04 PM, Jean-Michel Campin wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> You are right and we can get rid off those lines/cases.
>>>> Or may be just to comment them out (to emphasis the
>>>> differences between ocean and sea-ice/snow) ?
>>>> As you prefer.
>>>>
>>>> Cheers,
>>>> Jean-Michel
>>>>
>>>> On Fri, Oct 15, 2010 at 03:37:18PM +0200, Martin Losch wrote:
>>>>> Hi Jean-Michel,
>>>>>
>>>>> could you check for me the following parts of thsice_get_exf:
>>>>> We have:
>>>>>        IF ( hSnow(i,j).GT.3. _d -1 ) THEN
>>>>>          iceornot=2
>>>>>         ELSE
>>>>> 	           iceornot=1
>>>>>         ENDIF
>>>>> So that iceornot == 0 never happens. But then we have
>>>>>                 IF ( iceornot.EQ.0 ) THEN
>>>>> 	           lath  = flamb
>>>>> 	           qsat_fac = cvapor_fac
>>>>> 	           qsat_exp = cvapor_exp
>>>>> 	          ELSE
>>>>> 	           lath  = flamb+flami
>>>>> 	           qsat_fac = cvapor_fac_ice
>>>>> 	           qsat_exp = cvapor_exp_ice
>>>>> 	          ENDIF
>>>>> which will always be the second case, right? Similarly:
>>>>> C--- Upward long wave radiation
>>>>> 	          IF ( iceornot.EQ.0 ) THEN
>>>>> 	            emiss = ocean_emissivity
>>>>> 	          ELSEIF (iceornot.EQ.2) THEN
>>>>> 	            emiss = snow_emissivity
>>>>> 	          ELSE
>>>>> 	            emiss = ice_emissivity
>>>>> 	          ENDIF
>>>>> Where emiss will always be snow or ice_emissivity, but never  
>>>>> ocean, correct?
>>>>>
>>>>> Can we get rid of the iceornot==0 option (otherwise I'll have  
>>>>> to introduce more 2d fields for lath and emiss, which I want to  
>>>>> avoid)
>>>>>
>>>>> Martin
>>>>>
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach