[MITgcm-devel] problem with maskInC and obcs-balancing in adjoint

Jean-Michel Campin jmc at ocean.mit.edu
Mon Mar 14 11:23:48 EDT 2011


Hi Martin,

My personal opinion is that we could put those 2nd calls
(in initialise_varia) to ini_depth, ini_masks_etc ...
within #ifdef ALLOW_DEPTH_CONTROL :

Those 2nd calls were added for this reason, and I think
there would be a better way to do this ALLOW_DEPTH_CONTROL,
because all the maskC,W,S are kept constant and only the hFac 
are modified; This is not different from rStar code, which is
entirely done within initialise_varia, and works for the adjoint.
So, until someone re-write this ALLOW_DEPTH_CONTROL thing,
we could agree that, for now, it's not compatible with obcs.

Now, you know better than me those issues (ALLOW_DEPTH_CONTROL)
but I can give it a try to check that my proposition works (which
I did not yet try).

And to finish, I don't remember of this:
> 3. As an alternative, one could re-introduce the "obcs-masks" 
that you have just removed a few versions ago.
can you tell us more ?

Cheers,
Jean-Michel

On Mon, Mar 14, 2011 at 02:28:40PM +0100, Martin Losch wrote:
> Hi Jean-Michel, Patrick,
> 
> I have the impression that something goes wrong with the balancing code in the adjoint.:
> The field maskInC has 1 on the open boundary, whereas they should have zeros (as set in obcs_init_fixed). The reason is that there is a ifdef ALLOW_AUTODIFF_TAMC block in initialise_varia, where ini_depth and ini_masks_etc are called, where maskInC is reset to its original value (1 on the boundary). I need to force TAF to call obcs_init_fixed again within this block. What is the preferred option?
> 1. show obcs_init_fixed to TAF (edit obcs_ad_diff.list)
> 2. use directives:
> CADJ SUBROUTINE OBCS_INIT_FIXED INPUT  = 1
> CADJ SUBROUTINE OBCS_INIT_FIXED OUTPUT =
> CADJ SUBROUTINE OBCS_INIT_FIXED REQUIRED
> (edit obcs_ad.flow)
> 3. As an alternative, one could re-introduce the "obcs-masks" that you have just removed a few versions ago.
> 
> 1 and 2 work, haven't tried 3 (because I do not like that option).
> 
> Martin
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel



More information about the MITgcm-devel mailing list