[MITgcm-devel] ptracers
Chris Hill
cnh at mit.edu
Thu Oct 23 19:37:50 EDT 2003
You're right anything is possible! But I would try 3 first.
> -----Original Message-----
> From: mitgcm-devel-bounces at mitgcm.org
> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Patrick Heimbach
> Sent: Thursday, October 23, 2003 11:27 PM
> To: MITgcm-devel at mitgcm.org
> Subject: Re: [MITgcm-devel] ptracers
>
>
> 1 and 2 may mess up the flow dependencies though,
> depending on how TAF does them.
> I'll try it incrementally.
> -p.
>
> Chris Hill wrote:
> > That's great. Lets hope that 3 fixes it.
> >
> > 1 and 2 will be tidied up. Its very unlikely they could
> ever cause a
> > problem as is because all references within the routines and lower
> > down in the call trees are only to the dummy args and there are no
> > refs to the common members. However, it is messy and unecessary to
> > have the global refs visible so it should be cleaned up.
> >
> > Chris
> >
> >
> >>-----Original Message-----
> >>From: mitgcm-devel-bounces at mitgcm.org
> >>[mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of
> Patrick Heimbach
> >>Sent: Thursday, October 23, 2003 10:51 PM
> >>To: MITgcm-devel at mitgcm.org
> >>Subject: [MITgcm-devel] ptracers
> >>
> >>
> >>Hi there,
> >>
> >>I'm copying this message from Ralf.
> >>He was looking into why the derivative code
> >>of ptracers gave wrong gradient checks.
> >>
> >>I'll hopefully check in the modif's tomorrow
> >>together with AD-related modif.s for genmake2.
> >>
> >>We need to discuss point 2.
> >>
> >>-Patrick
> >>
> >>--------------------------------------------------
> >>
> >>Hi,
> >>
> >>I have worked on the problem in the ptracer adjoint.
> >>Thereby I found three problematic things in the code.
> >>The third one causes the adjoint to be wrong.
> >>
> >>Please find enclosed my changes to the code which fixes 1)
> >>and 3) but not 2).
> >>
> >>Ralf
> >>
> >>
> >>1) Aliasing problem in ptracers_forcing.F
> >>
> >>C !INTERFACE:
> >>==========================================================
> >> SUBROUTINE PTRACERS_FORCING(
> >> I bi,bj,k,iTracer,
> >> U gPtracer,
> >> I myIter,myTime,myThid )
> >>
> >>C !DESCRIPTION:
> >>C Adds sources and sinks of passive tracers to the
> tendancy arrays
> >>
> >>C !USES:
> >>===============================================================
> >> IMPLICIT NONE
> >>#include "SIZE.h"
> >>#include "EEPARAMS.h"
> >>#include "PTRACERS.h"
> >>#include "PARAMS.h"
> >>#include "FFIELDS.h"
> >>#include "GRID.h"
> >>
> >>It is not necessary to include PTRACERS.h and it even
> >>violates the Fortran standard. Thats because the variable
> >>gPtr is passed as argument and becomes dummy argument
> >>gPtracer. Now there are local arrays gPtr and gPtracer being
> >>the same array! This aliasing is not allowed if one of them
> >>is modified, which is the case here.
> >>Fix: just remove #include PTRACERS.h .
> >>
> >>
> >>2) Similar in GAD_CALC_RHS, gTracer is dummy argument and is
> >>aliased to gS by the call in calc_gs and aliased to gT by the
> >>call in calc_gt. But here
> >> #include "DYNVARS.h"
> >>cannot be removed since the arrays UVEL, VVEL, and WVEL are needed.
> >>Fix: not as simple, split DYNVARS.h, pass UVEL, VVEL, and
> >>WVEL, or use tracerIdentity to identify which array is to be
> >>used instead of dummy argument ptracer.
> >>
> >>
> >>3) In ptracers_integrate.F there is a local array rFlx which
> >>is only initialized for k.EQ.Nr . My guess it that it is
> >>updated for all k.lt.Nr . But in this case it must either be
> >>saved or declared in thermodynamics and passed as argument to
> >>ptracers_integrate (similar to fVerS in thermodynamics)
> >>otherwise its not initialised and used if not k.EQ.Nr !
> >>
> >>C rFlx :: vertical flux
> >> INTEGER i,j,iTracer
> >> INTEGER iMin,iMax,jMin,jMax
> >> INTEGER kUp,kDown,km1
> >> _RL rFlx(1-OLx:sNx+OLx,1-OLy:sNy+OLy,2,PTRACERS_num)
> >> LOGICAL calcAdvection
> >>CEOP
> >>
> >>C Loop over tracers
> >> DO iTracer=1,PTRACERS_numInUse
> >>
> >>C Initialize vertical flux to zero and set no-flux across k=Nr+1
> >> IF (k.EQ.Nr) THEN
> >> DO j=1-Oly,sNy+Oly
> >> DO i=1-Olx,sNx+Olx
> >> rFlx(i,j,1,iTracer)=0.
> >> rFlx(i,j,2,iTracer)=0.
> >> ENDDO
> >> ENDDO
> >> ENDIF
> >>
> >>
> >>--
> >>###################################################
> >>Dr. Ralf Giering
> >>NEW ADDRESS:
> >>FastOpt, Schanzenstr. 36, 20357 Hamburg, Germany
> >>Tel.: +49 40 48096347
> >>Fax : +49 40 48096357
> >>Email: Ralf.Giering at FastOpt.de
> >>URL : http://www.FastOpt.de
> >>###################################################
> >>
> >>_______________________________________________
> >>MITgcm-devel mailing list
> >>MITgcm-devel at mitgcm.org
> >>http://dev.mitgcm.org/mailman/listinfo/mitgcm-> devel
> >>
> >
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> --
> Patrick Heimbach ........................... M.I.T
> 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
_______________________________________________
MITgcm-devel mailing list
MITgcm-devel at mitgcm.org
http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list