GEOS-Chem v8-02-03

From Geos-chem
Revision as of 18:05, 9 October 2009 by Bmy (Talk | contribs) (IFORT 11)

Jump to: navigation, search

Overview

BETA RELEASE TBD -- still in testing

Will contain everything in GEOS-Chem v8-02-02, plus:

  • Kpp chemical solver package (Adrian Sandu group @ Virginia Tech group)
  • ICOADS ship emissions (Chulkyu Lee)
  • Use of GEOS-5 ozone columns (C. Carouge, still in validation)
  • Removal of support for obsolete SGI and COMPAQ compilers
  • Updated CH4 offline simulation (K. Wecht, C. Pickett-Heaps)
  • Updated makefile structure (G-C support team)

Previous issues now resolved in v8-02-03

Corrected Bond et al BC/OC emissions

Eric Leibensperger (eml@seas.harvard.edu) wrote:

The carbon_200905 data were generated with buggy code and generated bogus files. The files in carbon_200905 SHOULD NOT be used.
In addition, my previous statements that the Cooke overwrites over the US led to a high bias in BC and OC was WRONG. I think Cooke should still be the default (meaning in input.geos, the use Cooke line should be defaulted as T, rather than F).

The corrected files are now contained in the carbon_200909 directories. You may obtain these from:

ftp ftp.as.harvard.edu
cd /pub/geos-chem/data/GEOS_1x1/carbon_200909
mget *
cd /pub/geos-chem/data/GEOS_2x2.5/carbon_200909
mget *
cd /pub/geos-chem/data/GEOS_4x5/carbon_200909
mget *

GEOS-Chem v8-02-03 now points to the corrected files in carbon_200909.

The files in the previous directory carbon_200905 have been deleted from the FTP server. The carbon_200905 directory is now a symbolic link to carbon_200909.

Bob Yantosca has archived the carbon_200905 directories in case anyone needs to do a test with these files for backwards compability in model development. Please contact him directly if you need to use these files. It is recommended to migrate directly to the files in carbon_200909.

Reference:

Bond, T.C. et al.: Historical emissions of black and organic carbon aerosol fromenergy-related combustion, Global Biogeochem. Cycles, 21, GB2018, 1850-2000, doi: 10.1029/2006GB002840, 2007.

--Bob Y. 13:32, 21 September 2009 (EDT)

Several bug fixes in sulfate_mod.f

Philippe Le Sager (plesager@seas.harvard.edu) wrote:

I realized the SO4 derived from Canadian CAC inventory was ignored in v8-02-02, because of a typo. Jenny Fisher pointed out that SO4 derived from BRAVO was not accounted for. Paul Hezel provided a fix for diagnostic ND05, which now correctly records P(SO2) from OH. Paul also found out that the P(MSA) from DMS above the PBL was not accounted for.
All these bugs have been fixed. A patch is available for GEOS-Chem v8-02-02 and earlier versions:
   ftp ftp.as.harvard.edu
   cd pub/geos-chem/patches/v8-02-02
   get sulfate_mod.f
This fix has been standardized in GEOS-Chem v8-02-03.

--phs 16:57, 24 August 2009 (EDT)

Missing NOx data in S.E.-Asia

Data outside China from the Streets NOx inventory have been missing. The Streets_NOx_FF_2004_monthly.generic.1x1 files should be used only to provide monthly variations.

If you are using GEOS-Chem v8-02-02 or earlier, please update your code with the patch on the ftp site:

  ftp ftp.as.harvard.edu
  cd pub/geos-chem/patches/v8-02-02
  get streets_anthro_mod.f

This fix has been standardized in GEOS-Chem v8-02-03.

--phs 14:14, 19 August 2009 (EDT)

Mis-calculation of Courant numbers in tpcore_fvdas_mod.f90

I found that the Courant numbers where not calculated for the second band of latitude and the second last one in tpcore_fvdas_mod.f90. So crap values were used instead at these locations.

If you are using GEOS-Chem v8-02-02 or earlier, please update your code with the patch on the ftp site:

  ftp ftp.as.harvard.edu
  cd pub/geos-chem/patches/v8-02-02
  get tpcore_fvdas_mod.f90

This fix has been standardized in GEOS-Chem v8-02-03.

--Ccarouge 11:10, 18 August 2009 (EDT)

Format problem in planeflight_mod.f

Jingqiu Mao reported a problem in the plane.log output files, in which it looked like some tracers had abnormally large values.

Philippe Le Sager (plesager@seas.harvard.edu) wrote:

I found a solution. The problem is that Fortran output in ASCII switches between 2 formats:
   1.234E-12
   1.234-12
Correct, the E can disappear. And that confuses IDL. With the format specified by planeflight_mod.f (line 1237), it happens when the exponent is less than -100.
To keep the routine general, you can force the number of digit in the exponent with a 'e' in the format descriptor as follows:
   y = -1.233d-122
   write(6, '(es10.3)'   ), y   ! what is used now
   write(6, '(es11.3e3)' ), y   ! what we should use instead
   write(6, '(es12.3e4)' ), y
gives
   -1.233-122
   -1.233E-122
   -1.233E-0122
So replace (es10.3) with (es11.3e3) line 1237 of planeflight_mod.f and that should fix it.

--Bob Y. 11:35, 13 July 2009 (EDT)

Minor fixes in wet deposition

Bob Yantosca (yantosca@seas.harvard.edu) wrote:

(1) In subroutine RAINOUT (in wetscav_mod.f), I think we need to apply a separate conversion factor for NH3 (i.e. as is now done in subroutine COMPUTE_F). So we'd need to change the lines:
    REAL*8, PARAMETER    :: CONV = 8.27042925126d-1
to:
    ! CONV_H2O2 = 0.6 * SQRT( 1.9 ), used for the ice to gas ratio for H2O2
    ! 0.6 is ( sticking  coeff H2O2  / sticking  coeff  water )
    ! 1.9 is ( molecular weight H2O2 / molecular weight water )
    REAL*8, PARAMETER :: CONV_H2O2 = 8.27042925126d-1

    ! CONV_NH3 = 0.6 * SQRT( 0.9 ), used for the ice to gas ratio for NH3
    ! 0.6 is ( sticking  coeff  NH3 / sticking  coeff  water )
    ! 0.9 is ( molecular weight NH3 / molecular weight water )
    REAL*8, PARAMETER :: CONV_NH3  = 5.69209978831d-1
and then change these acccordingly:
    ELSE IF ( N == IDTH2O2 ) THEN

       ! Compute ice to gas ratio for H2O2 by co-condensation
       ! (Eq. 9, Jacob et al, 2000)
       IF ( C_H2O(I,J,L) > 0d0 ) THEN
          !------------------------------------------------------
          ! Prior to 7/20/09
          ! Now multiply by CONV_H2O2 (bmy, 7/20/09)
          !I2G = ( CLDICE(I,J,L) / C_H2O(I,J,L) ) * CONV
          !------------------------------------------------------
          I2G = ( CLDICE(I,J,L) / C_H2O(I,J,L) ) * CONV_H2O2
       ELSE
          I2G = 0d0
       ENDIF

    ...

    ELSE IF ( N == IDTNH3 ) THEN

       ! Compute ice to gas ratio for NH3 by co-condensation
       ! (Eq. 9, Jacob et al, 2000)
       IF ( C_H2O(I,J,L) > 0d0 ) THEN
          !--------------------------------------------------
          ! Prior to 7/20/09
          ! Now multiply by CONV_NH3 (bmy, 7/20/09)
          !I2G = ( CLDICE(I,J,L) / C_H2O(I,J,L) ) * CONV
          !--------------------------------------------------
          I2G = ( CLDICE(I,J,L) / C_H2O(I,J,L) ) * CONV_NH3
       ELSE
          I2G = 0d0
       ENDIF
Havala gave us the fix for separate CONV_H2O2 and CONV_NH3 factors for subroutine COMPUTE_F. But then we may have never thought to also apply this to subroutine RAINOUT, which subroutine, where the algorithm is similar. In any case, this is a simple fix.
(2) In subroutine COMPUTE_F, for NH3 we have:
          ! F is the fraction of NH3 scavenged out of the updraft
          ! (Eq. 2, Jacob et al, 2000)
          F(I,J,L) = 1d0 - EXP( -K * BXHEIGHT(I,J,L) / Vud(I,J) )
Note that BXHEIGHT(I,J,L) is used in the equation. However, almost all of the other non-aerosol tracers in COMPUTE_F use:
          ! Distance between grid box centers [m]
          TMP = 0.5d0 * ( BXHEIGHT(I,J,L-1) + BXHEIGHT(I,J,L) )

          ! F is the fraction of NH3 scavenged out of the updraft
          ! (Eq. 2, Jacob et al, 2000)
          F(I,J,L) = 1d0 - EXP( -K * TMP / Vud(I,J) )
So in other words TMP is the distance between grid box centers rather than the distance between grid box edges.
There is a comment:
   !  (7 ) Now set F=0 in the first level for all tracers.  Also now
   !        compute the distance between grid box centers and use that in
   !        in Eq. 10 from Jacob et al, 2000 to compute F. (hyl, bmy, 1/24/02)
It may have been that we just never switched BXHEIGHT to TMP in the IF block for NH3 tracer, I don't recall. It is probably not terrible as-is...but we may want to change that to be consistent w/ what is used for the other tracers.

Hongyu Liu (hyl@nianet.org) replied:

Regarding item (2) above, you're right that we need to be consistent throughout the code by using the distance between the grid centers. Using the BXHEIGHT makes almost no difference numerically, according to my test with radionuclide simulations conducted 10 years ago.

--Bob Y. 10:49, 20 July 2009 (EDT)

Minor fixes for IBM XLF compiler

Gabriel Morin (gabrielmorin@gmail.com) wrote:

In ocean_mercury_mod.f, replace line 491:
          EF     = MAX( (0.63 - 0.02 * TC), 0.0) ! keep export > 0
by the line:
          EF     = MAX( (0.63d0 - 0.02d0 * TC), 0.0d0) ! keep export > 0
In lightning_nox_mod.f, replace line 1441:
    CC = MAX( CCTHICK * 1d-3, 5.5 )
by the line:
    CC = MAX( CCTHICK * 1d-3, 5.5d0 )

--Bob Y. 11:35, 13 July 2009 (EDT)

Minor fixes in gamap_mod.f

Dylan Millet (dbm@umn.edu) wrote:

There's a minor bug in gamap_mod.f. In the ND28 section, MOLC for ALD2 is given as 3 instead of 2.

Bob Yantosca (yantosca@seas.harvard.edu) wrote:

Junhua Liu found a bug in the gamap_mod.f. If you use GEOS-4 then the mass flux variable is "ZMMU"; however, the name "CLDMAS" gets printed out to the tracerinfo.dat file.

These bugs have now been corrected.

--Bob Y. 14:04, 9 October 2009 (EDT)

Outstanding issues not yet resolved in v8-02-03

IFORT 11

At this time, GEOS-Chem is not compatible with version 11 of the Intel Fortran Compiler (aka IFORT 11). The Tsinghua U. group has been collaborating with Intel Tech Support on this matter. More information to follow.

IFORT 11.1 may be a better compiler version than IFORT 11.0. However, the GEOS-Chem Support Team has not been able to test this at this time.

--Bob Y. 14:05, 9 October 2009 (EDT)