3031 Views 8 Replies Latest reply: Oct 30, 2007 12:01 PM by wputman
Currently Being Moderated

## GEOS-5 met fields in GEOS-CHEM

I am importing the latest email discussion with GEOS-CHEM folks on the use of GEOS-5 met fields...

Original Post:

At 04:26 PM 10/22/2007, Bob Yantosca wrote:

Hi all,

Bob Yantosca here from Harvard.  I have a couple of questions regarding your implementation of advection in the GMI model.

We have an ongoing project that will likely result in the complete rewriting of GEOS-Chem for ESMF/MAPL implementation, and possibly a port to the IBM BlueGene/L platform.  Because this will take a long time, and because we have several users who need to work with GEOS-Chem in the "here-and-now", in the interim we are trying to make our existing transport code work with the new GEOS-5 met fields.

Our existing GEOS-Chem transport code is the version that from S-J Lin and Kevin Yeh, from 2002, see the files at

ftp ftp.as.harvard.edu

cd pub/exchange/bmy/geos_chem_tpcore

get tpcore_fvdas_mod.f90

get transport_mod.f90

This is the same transport code that we have successfully used with the GEOS-4 meteorology in GEOS-Chem.  This version of TPCORE expects U and V winds, plus the surface pressures at the midpt and end of the transport timestep.

In the GEOS-4 met, it was easy to compute the 3-D pressure field, with the following formula:

P(I,J,L) = A(L) + ( B(L) * Psurface(I,J) )

where A(L) and B(L) were the same for all vertical levels (L) and Psurface(I,J) is the true surface pressure at horizontal location (lon,lat) = (I,J).  So given the dynamic surface pressure, it was easy to compute the 3-D surface pressure field.

However, in GEOS-5 (operational data v5.01), we are not given A's and B's anymore.  We are given the 6-hr averaged pressures at level edges (PLE).  So what we have done is to create a 3-D pressure grid such that the 6-hr average pressure edges are scaled to the instantaneous 3-D pressure field.  (This is done up until the 176.93 hPa level edge, where the grid transforms from terrain-following to isobaric...everything from 176.93 to the atm. top at 0.01hPa is on isobaric pressure levels, regardless of geographic location).

So we do a scaling such as:

``````
! Ratio of distances:
!   ( Inst sfc prs - 176.93 hPa ) / ( 6hr sfc prs - 176.93 hPa )
RATIO = ( PSURF(I,J) - 176.93d0 ) / ( PLE(I,J,1) - 176.93d0 )

IF ( L &lt; 32 ) THEN

! For L &lt; 32, we need to readjust the pressure edges by the
! ratio of the instantaneous to 6-hr avg surface pressures
PEDGE = ( ( PLE(I,J,L) - 176.93d0 ) * RATIO ) + 176.93d0

ELSE

! For L=32 and above, all of the pressure edges
! are constant for all (lon,lat) locations (I,J).
PEDGE = PLE(I,J,L)

ENDIF
``````

and then we feed these pressures into our version of TPCORE.

I should also mention that both the U, V winds and the pressure edge fields have been regridded from the 0.5 x 0.667 to either 2 x 2.5 or 4 x 5.  I am not sure if that will also introduce an further instability or numerical error.  There wasn't much else that we could have done anyway.

Our existing TPCORE does run with GEOS-5 but it does seem that the strat-trop exchange is much slower than in GEOS-4.  I've attached a PPT file with several figures.  The result of Rn simulations suggest a weaker STE.  Also, our tagged Ozone (synoz) run shows very little Ox being brought down from the stratosphere.

Yuxuan Wang and I are looking at the code.  We think there may be a problem with how TPCORE induces vertical transport near the 176.93 hPa boundary.  We're still investigating.

Questions:

Have you started working with the GEOS-5 met fields yet in the GMI model?  If so, are you using the operational data set (0.5 x 0.667) or MERRA (1 x 1.25)?

Do you know if GMAO has released a newer version of the transport code?  I know they were working on something for a while but I am not aware of the status.  (I will follow up with them separately).  I think that GMAO is working with mass fluxes in their new code, but we have a version that takes in winds.

Are you aware of any issues with the pressure scaling that we are doing?  It seems like the logical thing to do.  However, would this cause a problem with pressure divergence?

We would appreciate any feedback you can give us.  We do not really have much transport experience on our end, and we are working with a 3rd party code, so it's difficult for us to sort things out.

Thanks much,

Bob Y.

#### More Like This

• Retrieving data ...