[MITgcm-devel] 'stop in exf_interp.F: value of filePrec not allowed'

[Patrick Heimbach]

I did a test, commenting the block in seaice_growth following

C Now melt snow if there is residual heat left in surface level
C Note that units of YNEG and SEAICE_SALT are m of ice
c          IF(RESID_HEAT(I,J).GT.ZERO.AND.
c     &         HSNOW(I,J,bi,bj).GT.ZERO) THEN
c           GHEFF(I,J)=MIN(HSNOW(I,J,bi,bj)/SDF/ICE_DENS,
c     &         RESID_HEAT(I,J))
c           YNEG(I,J,bi,bj)=YNEG(I,J,bi,bj)+GHEFF(I,J)
c           HSNOW(I,J,bi,bj)=HSNOW(I,J,bi,bj)-GHEFF(I,J)*SDF*ICE_DENS
c           SEAICE_SALT(I,J)=SEAICE_SALT(I,J)-GHEFF(I,J)
c          ENDIF

The mismatch between g77 and ifort reduced from
Y Y Y Y  6  9 10  8  7  9 13  9  6  8  9  5  8  8  9  6  8 FAIL  lab_sea
to
Y Y Y Y  9 10 12 13 12 13 16 14 11 12 12 10 12 12 11 10 12 FAIL  lab_sea

i.e. it's a critical part of the code
(but removal of it still leaves some discrepancies).

Removal of this block also reconciles adj. vs. f.d. gradients.
I also tried to replace ZERO by 1. _d -4
but that didn't do anything.
Not sure whether one increase that threshold further meaningfully
(I reckon unit is in meter).

-p.



On Dec 15, 2006, at 9:40 AM, Martin Losch wrote:

> Hi Patrick,
> I'll check in that fix with area, and  you can decide how to do the  
> storing and loop arrangement.
>
> M.
>
> On 15 Dec 2006, at 15:36, Patrick Heimbach wrote:
>
>>
>> Martin,
>>
>> On Dec 15, 2006, at 9:24 AM, Martin Losch wrote:
>>
>>> Patrick, sorry, me again:
>>> if the initialization of AREA(:,:,3,:,:) cause (small) problems I  
>>> would be happy to change this to a local array (makes more sense  
>>> to me anyway):
>>>
>>> instead of
>>> AREA(I,J,3,bi,bj) = MAX(A22,AREA(I,J,2,bi,jb)
>>> do
>>> areaLoc(I,J) = MAX(A22,AREA(I,J,2,bi,jb)
>>> and leave the field AREA alone at this point (it's not really  
>>> clean to abuse AREA(3) anyway).
>>>
>>> What do you think?
>>
>> Yep, would be cleaner.
>>
>> Re. heffm, it's a good question.
>> It either points to a problem, or,
>> since heffm is passed through several levels of S/R calls,
>> TAF doesn't keep track, and conservatively assumes activity
>> (I've seen such behaviour in the past).
>> Not sure...
>>
>> Looking in the adjoint code, it looks benign, i.e.
>> it's really only read-fro/written-to common once
>> (no other occurences such as generation of adheffm).
>>
>> -p.
>>
>>
>>
>>> Martin
>>>
>>> On 15 Dec 2006, at 15:16, Martin Losch wrote:
>>>
>>>> Patrick,
>>>>
>>>> why do you have to store HEFFM in seaice_model.F (this is the  
>>>> land mask for the seaice model and should really be replaced by  
>>>> maskC(i,i,1,bi,bj)). Doesn't this point to something strange?
>>>>
>>>> I just hope that is wasn't too difficult the fix the adjoint ...
>>>>
>>>> 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
>>
>> ---
>> Dr 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

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