[MITgcm-devel] adseaice_lsr

[Martin Losch]

Hi there,

I have explored this problem a little more and have come up with a simple example based on the taf-documentation, where I use some termination criterion, similar to ours in seaice_lsr (doiter), see the attached code. 
When you use n=10  and x=0.2 (or smaller) the criterion to set doiter=.false. is qucikly reached. The adjoint is then never executed (because doiter=.false.) and x_ad = 0 (well,  4.59163468E-41 in my case). If you reset doiter=.true. (comment in line starting with CML), the result is different (x_ad = 2.67949190E-06). I think what we probably should do, replace the loop with a "do while" loop, doing this in the simple example gives: x_ad = 2.67948531E-06.

However, when I do this with lab_sea (replace
DO m=1,solv_max_iters
IF ( doiterate4u.and.doiterate4v) THEN
ENDIF
ENDDO
by
DO WHILE ( doiterate4u.and.doiterate4v)
ENDDO
) the experiment runs forever, probably because all the recomputations warnings about cvv, cuu, etc. become effective for the first time, because the adjoint of the iterative solver is really so expensive.

My conclusion is that the adjoint of seaice_lsr needs work. I am not sure if it matters much, but so far, I think all "adjoint seaice models" did no have any adjoint of the lsr-iteration.

Martin


On Sep 27, 2011, at 5:03 PM, Martin Losch wrote:

> Hi there, 
> 
> I have had this suspicion for quite some time now, but only because Jean-Michel cleaned up the seaice_lsr code considerably, the adseaice_lsr becomes vaguely comprehensible:
> 
> I think that the adjoint code of adseaice_lsr does not do, what it is supposed to do. In particular, when you run, e.g., ./testreport -adm -t lab_sea, you'll get taf-code for adseaice_lsr, that has a section:
> [ ... ]
> C ITERATION
>          do m = 1, solv_max_iters
> C RESET ADJOINT INPUT VARIABLES
> [ ... ] 
> C ADJOINT LOOP KERNEL
> C$taf INCOMPLETE cuu,cvv,uice,urt,utmp,vice,vrt,vtmp
>            print *, 'ml-adseaice_lsr', m, doiterate4u, doiterate4v
>            if (doiterate4u .or. doiterate4v) then
> [ here the adjoint stuff happens ]
>            endif
> [ ... ]
>        enddo
> [ ... ]
> The print statement that I put there, tells me that both doiterate4u and doiterate4v are always false and you'll never do any adjoint computations within the "adjoint" loop.
> 
> What do you think? It might have to do with the use of the CADJ ITERATION directive, which might need adjustment after Jean-Michel's changes. According to the TAF manual, it should look something like:
> C$TAF LOOP=iteration uice = sometape
> C$TAF LOOP=iteration vice = sometape
> otherwise (without "sometape") you get some recomputations (which are probably OK, too).
> What puzzles me is that apparently the results of the adjoint do not change, so we might have had this issue even before Jean-Michel's changes?
> 
> Martin
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itertst_ad.f.gz
Type: application/x-gzip
Size: 1517 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110928/79b37139/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itertst.f.gz
Type: application/x-gzip
Size: 360 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110928/79b37139/attachment-0001.gz>