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

Jean-Michel Campin jmc at ocean.mit.edu
Mon Mar 14 18:54:15 EDT 2011


Hi Martin,

OK, you are right, I did not check before writing this. 

But I tried a 1rst step solution (keeping the ini_cg2d & ini_gc3d 
2nd call in initialise_varia.F and removing the most anoying ones), 
and it seems to work for me.
I will likely check-in those changes, and then if you could try 
in your set-up the OBCS balance with the adjoint, to see if it
works ?

Thanks,
Jean-Michel

On Mon, Mar 14, 2011 at 04:45:37PM +0100, Martin Losch wrote:
> Hi Jean-Michel,
> 
> I'd be happy with your solution, but actually, these calls:
> CALL INI_HFAC( myThid )
> CALL INI_DEPTHS( myThid )
> CALL INI_MASKS_ETC( myThid )
> were introduced in revision 1.48 with the comment "Changes in initialisation needed for NLFS adjoint". Only in revision 1.49, the depth_control stuff is added to the main branch. As far as I remember, these calls are here because TAF needs (or at that time needed) to see the full initialization of the the fields that are then partially updated in, e.g., update_masks_etc
> I hope that your solution still works, I'd be happy, if you can test this.
> 
> with removed masks I meant this:
> <http://mitgcm.org/viewvc/MITgcm/MITgcm/pkg/obcs/OBCS.h?r1=1.26&r2=1.27>
> but I realize now that this is not exactly that same stuff.
> 
> M.
> 
> On Mar 14, 2011, at 4:23 PM, Jean-Michel Campin wrote:
> 
> > 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
> > 
> > _______________________________________________
> > 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



More information about the MITgcm-devel mailing list