[Mitgcm-support] [Fwd: Re: TAF bug for tangent linear]

[mitgcm-support at dev.mitgcm.org]

-------- Original Message --------
Subject: Re: TAF bug for tangent linear
Date: Fri, 13 Sep 2002 13:08:21 +0200
From: Ralf Giering <Ralf.Giering at fastopt.de>
Organization: FastOpt
To: heimbach at MIT.EDU
References: <3D7F660E.6010904 at mit.edu> 
<200209121818.10604.Ralf.Giering at FastOpt.de> <3D80BC9B.6080100 at mit.edu>

Hi Patrick,

I found the bug and fixed it.

In addition TAF in forward mode was very slow on your code and needed a 
lot of
memory (14 minutes and 1.9Gbyte).
So, I also worked on the forward mode and was able to reduce time and space
resources by about a factor of 20 (44sec and 95Mbyte)!

The new version is already installed.

Thanks,
Ralf

P.S. I think the following flow directives are wrong, argument 3 is not
output!

cadj SUBROUTINE exch_uv_xyz_rl INPUT   = 1, 2, 3, 4
cadj SUBROUTINE exch_uv_xyz_rl OUTPUT  = 1, 2, 3
cadj SUBROUTINE exch_uv_xyz_rl ACTIVE  = 1, 2
cadj SUBROUTINE exch_uv_xyz_rl DEPEND  = 3, 4
cadj SUBROUTINE exch_uv_xyz_rl ADNAME  = adexch_uv_xyz_rl
cadj SUBROUTINE exch_uv_xyz_rl FTLNAME = exch_uv_xyz_rl

On Thursday 12 September 2002 06:10 pm, you wrote:
 > twain.lcs.mit.edu:/scratch/heimbach/ecco/MITgcm/adjoint/
 >
 > make ftltaf
 >
 > ergibt fuer den TAF-Aufruf:
 >
 > ~fastopt/bin/taf -forward -ftlmark g_ -i4 -r4 -flow taf_flow.log
 > -nonew_arg  -toplevel the_main_loop -input  '    xx_theta_dummy
 > xx_salt_dummy xx_tr1_dummy xx_hflux_dummy xx_sflux_dummy xx_tauu_dummy
 > xx_tauv_dummy xx_sst_dummy xx_sss_dummy xx_diffkr_dummy xx_kapgm_dummy
 > xx_efluxy_dummy xx_efluxp_dummy' -output 'fc' tamc_code.f
 >
 > Patrick
 >
 > Ralf Giering wrote:
 > > Hi Patrick,
 > >
 > > Das ist eher ein Bug.
 > > Kanst Du mir bitte path und command line geben.
 > >
 > > Ralf
 > >
 > > On Thursday 12 September 2002 05:52 pm, you wrote:
 > >>Hi Ralf,
 > >>
 > >>es gibt ein Problem mit Version 1.4.12 im forward mode
 > >>(auf twain):
 > >>
 > >>Segmentation fault
 > >>make: *** [ftlmodeltaf] Error 139
 > >>
 > >>reverse mode scheint OK zu sein.
 > >>Vielleicht out of memory?
 > >>
 > >>Patrick
 > >>
 > >>Ralf Giering wrote:
 > >>>Hi Patrick,
 > >>>
 > >>>That was indeed a general problem.
 > >>>I have fixed it by saving the input variables on auxiliary variables
 > >>>and reset the input variables before calling the linear routine the
 > >>>second time.
 > >>>
 > >>>I have not choosen the alternative, which is to recalculate the
 > >>>overwritten input variables because, in its extreme, that might 
require
 > >>>to recompute a lot from scratch. In your example the recomputation is
 > >>>trivial.
 > >>>
 > >>>In addtion TAF gives an information message to the user in this case.
 > >>>I have installed the new version TAF 1.4.12 on through and twain.
 > >>>
 > >>>Ralf
 > >>>
 > >>>On Wednesday 11 September 2002 05:49 pm, you wrote:
 > >>>>Hi Ralf,
 > >>>>
 > >>>>there is a problem with the forward mode of TAF
 > >>>>when exploiting self-adjointness.
 > >>>>
 > >>>>What happens is that in S/R g_solve_for_pressure
 > >>>>cg2d is called first to compute the g_... quantities
 > >>>>(g_cg2d_b,g_cg2d_x),
 > >>>>then called again to calculate the actual state
 > >>>>(cg2d_b,cg2d_x).
 > >>>>Before the second call the indices should be reset, thus
 > >>>>      firstresidual = 0.
 > >>>>      lastresidual = 0.
 > >>>>      numiters = cg2dmaxiters
 > >>>>but the reset is missing.
 > >>>>
 > >>>>The flow directive should have the information,
 > >>>>since the correct resetting is done in the adjoint code:
 > >>>>
 > >>>>C----------------------------------------
 > >>>>C subroutine  cg2d
 > >>>>C----------------------------------------
 > >>>>CADJ SUBROUTINE cg2d ADNAME  = cg2d
 > >>>>CADJ SUBROUTINE cg2d FTLNAME = cg2d
 > >>>>CADJ SUBROUTINE cg2d INPUT   = 1,2,3,4,5,6
 > >>>>CADJ SUBROUTINE cg2d OUTPUT  =   2,3,4,5
 > >>>>CADJ SUBROUTINE cg2d ACTIVE  = 1,2
 > >>>>CADJ SUBROUTINE cg2d DEPEND  =           6
 > >>>>
 > >>>>
 > >>>>Another issue (or, why I do all this) is that
 > >>>>I try to do forward mode vs. finite difference gradient checks.
 > >>>>Assuming that
 > >>>>   g_fc = (grad J)_(ith-component) * (delta xx)_(ith-component)
 > >>>>I should be able to recover (grad J)_(ith-component)
 > >>>>by setting
 > >>>>   (delta xx)_(ith-component) = 1.
 > >>>>(all others = 0.).
 > >>>>Well, I get the correct order of magnitude,
 > >>>>but not really correct gradients.
 > >>>>Do you have an idea what else could go wrong
 > >>>>(I've tried it with my above hand-fix).
 > >>>>
 > >>>>Cheers
 > >>>>Patrick

-- 
###################################################
  Dr. Ralf Giering
  FastOpt
  Martinistr. 21
  20251, Hamburg, Germany
  Tel. : +49 40 48096347
  Fax  : +49 40 48096357
  Email: Ralf.Giering at FastOpt.de
  URL  : http://www.FastOpt.de
###################################################

-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Patrick Heimbach     Massachusetts Institute of Technology
FON: +1/617/253-5259                    EAPS, Room 54-1518
FAX: +1/617/253-4464               77 Massachusetts Avenue
mailto:heimbach at mit.edu                 Cambridge MA 02139
http://www.mit.edu/~heimbach/                       U.S.A.