[MITgcm-devel] thsice_get_exf

[Martin Losch]

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