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

[Martin Losch]

Hi Jean-Michel,

your changes also work for me, I think it's better than my solution, thanks.

Martin

On Mar 14, 2011, at 11:54 PM, Jean-Michel Campin wrote:

> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel