[MITgcm-devel] Re: seaice_evp

Patrick Heimbach heimbach at MIT.EDU
Thu Jun 7 11:39:59 EDT 2007


Hi Martin,

your change of yesterday in seaice_evp.F messed up the adjoint again.
I had thought that you'd implement changes such as to leave computation
unchanged in case of ALLOW_AUTODIFF.
Changing to
             IF ( deltaC .GT. 0. _d 0 ) deltaC = SQRT(deltaC)
makes gradient rise by 10 orders of magn.

I understand using the former lines
             deltaC = SQRT(MAX(deltaC,SEAICE_EPS_SQ))
will cause deltaC to be non-zero where it wasn't before.
That's reasonable, but the above should be treated differently then:
             IF ( deltaC .GT. 0. _d 0 )
      &           deltaC = SQRT(MAX(deltaC,SEAICE_EPS_SQ))

In this case your argument (Delta = 0 gets replaced by SEAICE_EPS)
doesn't hold anymore since it Delta remains zero where it was before,
and unless SEAICE_EPS is chosen badly, it should work.

What speaks against implementing it this way?

-Patrick

PS:
Could we reduce the code and reference output update turnaround
from maybe daily to weekly...?



On Jun 2, 2007, at 2:17 PM, Martin Losch wrote:

> Hi Patrick,
>
> during the last three days, the only things that changed (other  
> than diagnostics) are these:
>   - add new parameter SEAICE_evpTauRelax as an alternative
>     to SEAICE_elasticParm (that should not have any effect on the  
> adjoint)
>   - add a cap on AREA after advecting AREA if seaice_growth is not  
> called (this happens at the end of seaice_advdiff and is only  
> within IF (usePW79thermodynamics) THEN/ENDIF and not any #ifdefs,  
> this may actually be the problem, but then I would expect a store  
> of AREA just before that part of the code should help?)
>
> Martin
>
>
> On 2 Jun 2007, at 12:32, Patrick Heimbach wrote:
>
>> Martin,
>> not sure, I might have missed it earlier.
>> There's probably some change in the recompute structure
>> within the seaice package.
>> Probably some change within last ~3 days.
>> I can look at it later, but was surprised by it yesterday,
>> (and by the fact that so many vars. needed extra store)
>> and needed to check in the other changes of yesterday
>> (and ran into a - benign TAF bug).
>> Cheers
>> -p.
>>
>> On Jun 2, 2007, at 2:01 AM, Martin Losch wrote:
>>
>>> Since when does seaice need much more storing? Maybe I can help,  
>>> since I am probably the culprit?
>>>
>>> Martin
>>>
>>> On 2 Jun 2007, at 00:20, Patrick Heimbach wrote:
>>>
>>>> Update of /u/gcmpack/MITgcm/model/src
>>>> In directory forge:/tmp/cvs-serv32108/model/src
>>>>
>>>> Modified Files:
>>>> 	do_oceanic_phys.F
>>>> Log Message:
>>>> Seaice_model suddenly needs much more storing.
>>>> Don't have time to check what has changed (again).
>>>>
>>>> _______________________________________________
>>>> MITgcm-cvs mailing list
>>>> MITgcm-cvs at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>>>
>>> _______________________________________________
>>> 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





More information about the MITgcm-devel mailing list