[MITgcm-devel] fortran 77 syntax with TAF version 2.1.6

Matthew Mazloff mmazloff at ucsd.edu
Fri Apr 15 06:48:00 EDT 2011


Hello,

Not sure about the syntax with f77...version 2.1.6 seems correct (most  
consistent) to me.  Or, since previous versions just saved the whole  
variable when
  STORE theta(:,:,k,bi,bj)
was requested these could just be changed to
  STORE theta
and this would be compatible with older versions.

Or, since the only issue is with the convective adjustment code -- can  
we just remove the problematic aspect of the code?  The adjoint  
variables should never be used to judge if convective mixing is  
necessary --  it would be odd to think that if the density sensitivity  
was larger near the surface it should be mixed more.  It should be the  
forward state that is sent to FIND_RHO_2D and used for  
CONVECTIVE_WEIGHTS.  I am not sure this is happening though....I  
haven't checked the adjoint code, but I see no reason to expect an  
asymmetry...so I suspect this code is problematic to begin with

On the same note -- I have a question about kpp.  It was brought to my  
attention that ROMS saves the diff and visc as determined from kpp  
with the forward state to mix its adjoint variables -- this seems the  
correct thing to do.  There is an asymmetry with this package -- the  
adjoint variables should not be used to determine what the diff and  
visc are.  So could we, or are we, doing something similar?  It was my  
impression that because kpp is off in the adjoint, that the adjoint  
variables are always mixed with background values...

I suppose we can chat more about this at the meeting...

-Matt




On Apr 15, 2011, at 2:01 AM, Ralf Giering wrote:

> Hi Jean-Michel,
>
> In case of a store-directive using a user-defined tape:
>
> CADJ STORE theta(:,:,k,bi,bj) = tapelev_ini_bibj_k,
> CADJ &     key = kkey, byte = isbyte
>
> The call to adread should look like this:
>
>           call adread ( mythid,
>      &            'tapelev_ini_bibj_k_4_the_main_loop_theta',40,12,
>      $4,theta(1,1,k,bi,bj),8,(1+snx+olx-(1-olx))*(1+sny+oly-(1-oly)),
>      $kkey )
>
> TAF version <=2.1.5 stores the whole array not the part specified.
> TAF version   2.1.6 uses Fortran-90 syntax even if no -f90 option is  
> given.
> TAF version   2.1.7 (just installed) should generate the code shown.
>
> Thank you,
> Ralf
>
> On Wednesday 13 April 2011, Jean-Michel Campin wrote:
> > Hi Ralf,
> >
> > The store directive that causse this g77 problem is
> > in MITgcm/model/src/convective_adjustment_ini.F,
> > inside a k loop, lines 135-136:
> > > CADJ STORE theta(:,:,k,bi,bj) = tapelev_ini_bibj_k,
> > > CADJ &     key = kkey, byte = isbyte
> >
> > I did not see any warning regarding non f77-standard code
> > (but I could have missed it).
> >
> > And you are right, nowadays most of the fortran compilers accept
> > f90 syntax, so it might not be a serious limitation.
> > Will see what Patrick says.
> >
> > Thanks,
> > Jean-Michel
> >
> > On Wed, Apr 13, 2011 at 04:45:39PM +0200, Ralf Giering wrote:
> > > Hi Jean-Michel,
> > >
> > > What is the corresponding store directive?
> > >
> > > Usually TAF generates only Fortran-90 code if the option -f90 or  
> -f95 is given.
> > > In some cases TAF gives an error message if it cannot generate  
> code that conforms to FORTRAN-77 standard.
> > >
> > > Most Fortran compilers support Fortran-90 syntax nowadays.
> > > Since TAF can handle more cases when allowed to generate  
> Fortran-90
> > > its recommended to use TAF option -f90 whenever possible.
> > >
> > > Cheers,
> > > Ralf
> > >
> > > On Wednesday 13 April 2011, Jean-Michel Campin wrote:
> > > > Hi Ralf,
> > > >
> > > > I have problems to compile the code that TAF version 2.1.6
> > > > returns when I try to use the g77 compiler (which does not
> > > > know about F90 syntax). here is an example:
> > > >
> > > > with version 2.1.6:
> > > >           call adread ( mythid,
> > > >      &            'tapelev_ini_bibj_k_4_the_main_loop_theta', 
> 40,12,
> > > >      $4,theta(:,:,k,bi,bj),8,(1+snx+olx-(1-olx))*(1+sny+oly-(1- 
> oly)),
> > > >      $kkey )
> > > >
> > > > g77 gives this type of error message:
> > > > > ad_taf_output.f:10259:
> > > > >         $4,theta(:,:,k,bi,bj),8,(1+snx+olx-(1-olx))*(1+sny 
> +oly-(1-oly)),
> > > > >            1     2
> > > > > Null element at (1) for array reference at (2)
> > > > > ad_taf_output.f:10259:
> > > > >         $4,theta(:,:,k,bi,bj),8,(1+snx+olx-(1-olx))*(1+sny 
> +oly-(1-oly)),
> > > > >            1     2
> > > > > Too few elements (4 missing) as of (2) for array reference  
> at (1)
> > > > > ad_taf_output.f:10259:
> > > > >         $4,theta(:,:,k,bi,bj),8,(1+snx+olx-(1-olx))*(1+sny 
> +oly-(1-oly)),
> > > > >            1     2
> > > > > Invalid token at (2) in expression or subexpression at (1)
> > > >
> > > > and if I compare with version 2.1.5:
> > > >           call adread ( mythid,
> > > >      &            'tapelev_ini_bibj_k_4_the_main_loop_theta', 
> 40,12,
> > > >      $4,theta,8,(1+snx+olx-(1-olx))*(1+sny+oly-(1- 
> oly))*nr*nsx*nsy,kkey
> > > >      $)
> > > > which was passing through g77 without any problem.
> > > >
> > > > My question: is there a TAF (staf) option that would produce
> > > > code that does not rely on f90 syntax ? or should I give up
> > > > trying to use g77 ?
> > > >
> > > > Thanks,
> > > > Jean-Michel
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
>
> -- 
> ###################################################
>  Dr. Ralf Giering
>  FastOpt GmbH
>  Lerchenstr. 28a, 22767 Hamburg, Germany
>  Tel.: +49 40 48096347
>  Fax : +49 40 48096357
>  Email: Ralf.Giering at FastOpt.de
>  URL  : http://www.FastOpt.de
>  Handelsregister Amtsgericht Hamburg, HRB 103390
>  Geschäftsführer: Ralf Giering, Thomas Kaminski
> ###################################################

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110415/6ade17ab/attachment-0001.htm>


More information about the MITgcm-devel mailing list