[MITgcm-devel] thsice_get_exf
Jean-Michel Campin
jmc at ocean.mit.edu
Sat Oct 16 10:54:12 EDT 2010
Hi Patrick,
There might have been some reason (which I forgot), but now
it seems safe to declare all the argument arrays in
thsice_calc_thickn with fixed size (if it's better for TAF).
Cheers,
Jean-Michel
On Sat, Oct 16, 2010 at 10:20:30AM -0400, Patrick Heimbach wrote:
>
> 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
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list