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

[Martin Losch]

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