[MITgcm-devel] [MITgcm-cvs] MITgcm/pkg/exf CVS Commit

[Jean-Michel Campin]

Hi Gael,

An other solution would be to disable zenithAngle dependence of
the albedo for cartesian & cylindrical grid (a stop in exf_check.F)

But I have other issues with the code you checked in last night:
1) plenty of tab ; unbalance single quote in comments.
2) no documentation new flag useExfZenithAngle (in EXF_PARAM.h)
   no documentation for all variables in COMMON /exf_zenith_angle_r/ 
   (EXF_FIELDS.h).
3) where to turn on the CPP options ALLOW_ZENITHANGLE,
  ALLOW_DIURNAL_ALBEDO ? ALLOW_DAILY_ALBEDO_AIM ?
  they should appear #undef in EXF_OPTIONS.h with some description.
4) in exf_zenithangle.F, line 211, what is this syntax: 
> #else ALLOW_DAILY_ALBEDO_AIM
5) why not having run-time parameter for those options:
  ALLOW_DIURNAL_ALBEDO ? ALLOW_DAILY_ALBEDO_AIM since the
  arrays are there anyway (in EXF_FIELDS.h) ?
6) why not updating exf_summary.F & exf_check.F ?
7) I don't like the name of the flag "useExfZenithAngle" :
 when it's true, it changes the albedo, so it should have a name
 that contains "albedo" in it. we talked about this.
8) dimensions nSx,nSy of array  "zen_albedo_table" are probably
  not necessary/un-safe; but waiting for cleaner version to check this.

In conclusion, it's a good thing that pkg/exf does not have many
different CPP options and very few run-time parameters, so that you
probably don't need to document them or check if they are consistent.
But I remember you were annoyed in the past to waste time on some 
similar inconsistent/undocumented things. So I guess, for you, this 
kind of "good programming standard" only apply to others.

Cheers,
Jean-Michel

On Tue, Apr 13, 2010 at 10:32:18AM +0200, Martin Losch wrote:
> Gael,
> 
> I have suggestion for the new zen_albedo code. This type of statement:
> >            LLLAT=yC(i,j,bi,bj)+91. _d 0
> > c ensure that it is in valid range		   
> > 	   LLLAT=max(LLLAT, 1._d 0)
> > 	   LLLAT=min(LLLAT, 181._d 0)
> > c store
> >            zen_albedo_pointer(i,j,bi,bj)=LLLAT
> will _not_ give you reasonable results for cartesian grids (because there yC is in m and typically ranges from 0 to 10^5 or 10^6), neither for cylindrical grids. Not that I think that people will excessively use cartesian grids with a latitude-dependent surface albedo, but I have once spent a long time on debugging pkg/dic, where the routine insol.F did something similar, and people actually tried to use the code on a cartesian grid and were surprised by the strange tracer distributions. My solution was this:
> > C latitude in radians
> >           lat=YC(1,j,1,bj)*deg2rad
> > C     latitute in radians, backed out from coriolis parameter
> > C     (makes latitude independent of grid)
> >           IF ( usingCartesianGrid .OR. usingCylindricalGrid )
> >      &         lat = asin( fCori(1,j,1,bj)/(2. _d 0*omega) )*deg2rad
> Maybe you can consider a similar solution for the zen_albedo code (I found a few places where yC/xC are assumed to be lon/lat)?
> 
> Martin
> 
> On Apr 13, 2010, at 8:57 AM, Gael Forget wrote:
> 
> > Update of /u/gcmpack/MITgcm/pkg/exf
> > In directory faulks.csail.mit.edu:/u/u2/gforget/MITgcm/pkg/exf
> > 
> > Modified Files:
> > 	EXF_FIELDS.h EXF_PARAM.h exf_ad_diff.list exf_init_fixed.F 
> > 	exf_radiation.F exf_readparms.F exf_summary.F 
> > Added Files:
> > 	exf_zenithangle.F exf_zenithangle_table.F 
> > Log Message:
> > account for the variation of albedo as a function of zenith angle
> > 
> > 
> > _______________________________________________
> > MITgcm-cvs mailing list
> > MITgcm-cvs at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-cvs
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel