[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