[MITgcm-devel] seaice velocity mask

[Martin Losch]

Hi,

picking up this thread again, Patrick and I sort of agreed that keeping this option in the code could be particularly helpful especially for the adjoint, as turning it on might damp adjoint sensitivities that would otherwise spread through the velocities fields across not-ice-covered areas (e.g. interhemispheric effect). Gael, what is your experience?

In general for forward modelling, I maintain, that this option should not be used and should not be default.

Martin

On Apr 29, 2010, at 10:34 AM, Martin Losch wrote:

> Gael, Patrick,
> 
> may I revive my April-Fools-Day email question about a to-be-introduced CPP flag ALLOW_SEAICE_RHSMASK? If you think it's a good idea, I can do this (I guess the benefits are mainly for the adjoint).
> 
> Martin
> 
> On Apr 1, 2010, at 2:54 PM, Martin Losch wrote:
> 
>> Gael,
>> 
>> I just went back and checked, that I actually had seaiceMaskU/V
>> initialised in seaice_init_fixed.F (Revision 1.4), but Patrick removed
>> this part (Revision 1.5), probably, because they are re-initialised in
>> seaice_ini_varia.F (maybe because it's easier to taf to recognize
>> dependencies?).
>> 
>> I suggest, that we add a flag ALLOW_SEAICE_MASKRHS (undefined by
>> default) that is put ifdefs around the update of seaiceMaskU/V in
>> seaice_dynsolver.F and also in seaice_ini_varia.F and re-introduce the
>> initialisation of the fields into seaice_ini_fixed.F. Will that have
>> negative consequences for the adjoint?
>> 
>> After this works I guess that these fields need not be stored anymore
>> (except when ALLOW_SEAICE_MASKRHS is defined) and these directives can
>> be either removed (with a warning when both ALLOW_TAMC_AUTODIFF and
>> ALLOW_SEAICE_MASKRHS are defined) or also put between #ifdef
>> ALLOW_SEAICE_MASKRHS.
>> 
>> What do you think? and what does Patrick think about this?
>> 
>> 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