GEOS-Chem v8-01-02

From Geos-chem
Jump to: navigation, search

Overview

BETA RELEASE November 2008

What's new in this version

Contains everything in GEOS-Chem v8-01-01, with the following additions:

  • GEOS-5 0.5 x 0.666 degree nested-grid simulation for China/SE Asia
  • Improvements to the GEOS-3 1x1 nested-grid simulation for N. America
  • Modifications for using reprocessed GEOS-5 met fields (i.e. w/ corrected optical depths)
  • Several bug fixes and improvements for robustness, scientific algorithms, and diagnostics

Fixes to improve numerical stability

Numerical noise bug in upbdflx_mod.f

Obsolete.jpg

NOTE: Module upbdflx_mod.F was removed from GEOS-Chem. Stratospheric chemistry is now done in strat_chem_mod.F90.

Ray Nassar wrote:

The run I did last night confirmed that turning off "Use strat O3/NOy BC's" does change O3 and NOx at lower levels so I cannot turn this off for sensitivity tests if comparing to past runs.
I have tried the debugging approach which you have suggested and it indicates that the problem is coming from the triple loop:
        DO L = LMIN, LLPAR
        DO J = 1,    JJPAR
        DO I = 1,    IIPAR

           ! Skip over tropospheric boxes
           IF ( ITS_IN_THE_STRAT( I, J, L ) ) THEN

              ! PNOY = P(NOy) converted from [v/v/s] to [v/v]
              PNOY = STRATPNOY(J,L) * DTDYN

              ! Add [NOx] and [HNO3] to PNOY.
              ! PNOY is now the total [NOy] concentration
              PNOY = PNOY + STT(I,J,L,IDTNOX) + STT(I,J,L,IDTHNO3)

              ! Partition total [NOy] to [NOx], units are [v/v]
              STT(I,J,L,IDTNOX)  = PNOY * XRATIO(J,L)

              ! Partition total [NOy] to [HNO3], units are [v/v]
              STT(I,J,L,IDTHNO3) = PNOY * ( 1d0 - XRATIO(J,L) )

           ENDIF
        ENDDO
        ENDDO
        ENDDO
in the file upbdflx_mod.f. Since XRATIO can have a value of one, it means that numerical noise sometimes makes 1d0 - XRATIO(J,L) a negative number and then STT(I,J,L,IDTHNO3) becomes negative and triggers the error message. For the two instances where the difference is computed, I have now added the lines:
       ! Ray Nassar (2008-06-11) -------------------------------
       !
       ! The kludge below is to deal with errors which result
       ! from subtracting 1d0 - XRATIO(J,L). When XRATIO should
       ! be equal 1, the binary representation will have a
       ! finite error making it slightly more or less than 1.
       ! For XRATIO slightly more than 1, STT(I,J,L,IDTHNO3)< 0
       ! which triggers a CHECK_STT error message.
       !
       if (STT(I,J,L,IDTHNO3) <= 0d0) then
          STT(I,J,L,IDTHNO3) = 0d0
       endif
       !--------------------------------------------------------
immediately after the calculation of STT(I,J,L,IDTHNO3) and this fixes the problem! I think this will have to be fixed in the next version of the code.

Philippe Le Sager wrote:

Thanks for catching that. We will fix this simply with a
   MAX( ( 1d0 -  XRATIO(J,L) ), 1d-20) 
in place of
   ( 1d0 - XRATIO(J,L) ), 
since we want to have strictly positive concentration in the troposphere and some boxes switch b/w troposphere and stratosphere.

--Bob Y. 11:13, 12 June 2008 (EDT)
--Bob Yantosca (talk) 15:39, 16 November 2017 (UTC)

Out of bounds error for tagged_co_mod.f

Obsolete.jpg

NOTE: This fix will be introduced into v8-01-02.

NOTE: This code was removed from GEOS-Chem v10-01 and higher versions. Emissions in these versions are now handled by HEMCO.

Mike Barkley wrote:

I've downloaded the latest public release (v8-01-01) which compiles okay it straight out of the 'box' using the compiler options:
   # IFORT compilation options
   FFLAGS = -cpp -w -O2 -auto -noalign -convert big_endian

   # Compile command -- multiprocessor
   F90 = ifort $(FFLAGS) -openmp -Dmultitask
However, if you add the -CB compiler option to FFLAGS (which checks for array bounds) the error message, shown below, appears. Is this a coding error or a 'compiler bug'?
   Compiling geos in Makefile.ifort
   fortcom: Error: tagged_co_mod.f, line 630: Subscript #3 of the array EMISRR has value 1 
   which is less   than the lower bound of 2
              E_CO = EMISRR(IREF,JREF,1)
   ----------------------^
   compilation aborted for tagged_co_mod.f (code 1)
   make: *** [tagged_co_mod.o] Error 1

Philippe Le Sager replied:

This is a coding error that we recently found when trying to run the tagged CO simulation. Just replace the line 630 with:
    E_CO = EMISRR(IREF,JREF,IDECO)
and make sure that line 443 declares IDECO:
    USE TRACERID_MOD, ONLY : IDBFCO,  IDECO
Also there are updated files on my ftp that you may want to look at: ftp://ftp.as.harvard.edu/pub/exchange/phs/GEOS-Chem-UPDATE/
The updates mainly deal with (rare) computation issues (NaN or zero concentration). The fix for ND65(family diagnostic) is probably the most important, although quite simple (see chemdr.f).

NOTE: Also you will need to make sure to dimension the following arrays in CMN_O3 as follows:

!------------------------------------------------------------------------------
! Prior to 6/11/08:
! Redimension EMISR, EMIST to avoid errors in tagged CO (jaf, bmy, 6/11/08)
!     &   EMISR(IGLOB,JGLOB,2:NEMPARA), EMISRN(IGLOB,JGLOB,NOXLEVELS),   
!     &   EMIST(IIPAR,JJPAR,2:NEMPARA), EMISTN(IIPAR,JJPAR,NOXLEVELS)
!------------------------------------------------------------------------------
     &   EMISR(IGLOB,JGLOB,NEMPARA),  EMISRN(IGLOB,JGLOB,NOXLEVELS),   
     &   EMIST(IIPAR,JJPAR,NEMPARA),  EMISTN(IIPAR,JJPAR,NOXLEVELS)

!------------------------------------------------------------------------------
! Prior to 6/11/08:
! Redimension EMISRR to avoid errors in tagged CO (jaf, bmy, 6/11/08)
!     &   EMISRR (IIPAR,JJPAR,2:NEMPARA+NEMPARB),                        
!------------------------------------------------------------------------------
     &   EMISRR (IIPAR,JJPAR,NEMPARA+NEMPARB),                          
     &   EMISRRN(IIPAR,JJPAR,NOXEXTENT        )

This is to remove some historical baggage.

--Bob Y. 13:29, 30 June 2008 (EDT)
--Bob Yantosca (talk) 15:39, 16 November 2017 (UTC)

Jintai Lin replied on 2008/11/11:

You also need to update setemis.f for EMISRR. I simple change the code as follows. At Line 126:
     !REAL*8,  INTENT(IN) :: EMISRR(IIPAR,JJPAR,2:NEMPARA+NEMPARB)
     REAL*8,  INTENT(IN) :: EMISRR(IIPAR,JJPAR,NEMPARA+NEMPARB) ! Lin_20081107

Fixes for scientific algorithms

Quick fix for GEOS-5 optical depth

Obsolete.jpg

NOTE: This fix is now standard in GEOS-Chem v8-01-02.

NOTE: All GEOS-5 data files were reprocessed in 2009 to account for the optical depth fix. The code fix below is now obsolete.

To apply the "quick fix" described above in #5, please change the following lines in routine READ_A6 (in file read_a6_mod.f) from:

#elif defined( GEOS_5 )

      !------------------------------
      ! Special handling for GEOS-5
      !------------------------------

to:

#elif defined( GEOS_5 )

     !------------------------------
     ! Special handling for GEOS-5
     !------------------------------

     !%%%%% KLUDGE FOR GEOS-5
     !%%%%% OPTDEPTH is the total in-cloud optical depth so we need
     !%%%%% to multiply it by the cloud fraction as a quick fix
     !%%%%% (bmy, phs, 10/10/08)
     IF ( PRESENT( OPTDEPTH ) ) THEN
        OPTDEPTH = OPTDEPTH * CLDTOT
     ENDIF

This will make sure that the optical depth (which is in-cloud optical depth) gets multiplied by the cloud fraction.

Dylan Millet wrote:

This single modification (see above) appears to have changed the global annual mean OH in my simulation from 12.3 to 11.0 x 10^5 molec/cm3.

--Bob Y. 12:36, 14 October 2008 (EDT)
--Bob Yantosca (talk) 15:51, 16 November 2017 (UTC)

Corrected labeling of SOA quantities in carbon_mod.f

Colette Heald wrote:

I noticed previously that the parameters in (routine) SOA_PARA were confusingly ordered, but it's only today that I realized that in fact they are mis-labeled as well. The actual numbers are all perfectly correct but they should correspond to the information in Tables 3 and 4 for the categories of Table 1 of the Chung and Seinfeld (2002) paper. I have re-organized the code & comments for clarity (lines 1875-1939), they should read as:
     ! Average of ALPHA-PINENE, BETA-PINENE, SABINENE, D3-CARENE
     RALPHA(1,1) = 0.067d0            
     RALPHA(2,1) = 0.35425d0

     ! LIMONENE
     RALPHA(1,2) = 0.239d0
     RALPHA(2,2) = 0.363d0

     ! Average of TERPINENES and TERPINOLENE
     RALPHA(1,3) = 0.0685d0
     RALPHA(2,3) = 0.2005d0

     ! Average of MYRCENE, LINALOOL, TERPINENE-4-OL, OCIMENE
     RALPHA(1,4) = 0.06675d0
     RALPHA(2,4) = 0.135d0

     ! Average of BETA-CARYOPHYLLENE and and ALPHA-HUMULENE
     RALPHA(1,5) = 1.0d0
     RALPHA(2,5) = 0.0d0

     ! Using BETA-PINENE for all species for NO3 oxidation
     ! Data from Table 4 of Griffin, et al., JGR 104 (D3): 3555-3567 (1999)
     RALPHA(3,:) = 1.d0           

     ! Here we define some alphas for isoprene (dkh, bmy, 5/22/06)

     ! high NOX  [Kroll et al, 2005]
     !RALPHA(1,6) = 0.264d0
     !RALPHA(2,6) = 0.0173d0
     !RALPHA(3,6) = 0d0

     ! low NOX   [Kroll et al, 2006; Henze and Seinfeld, 2006]
     RALPHA(1,6) = 0.232d0
     RALPHA(2,6) = 0.0288d0
     RALPHA(3,6) = 0d0

     !=================================================================
     ! Equilibrium gas-particle partition coefficients of 
     ! semi-volatile compounds [ug-1 m**3]
     !=================================================================

     ! Average of ALPHA-PINENE, BETA-PINENE, SABINENE, D3-CARENE
     KOM(1,1) = 0.1835d0
     KOM(2,1) = 0.004275d0

     ! LIMONENE
     KOM(1,2) = 0.055d0
     KOM(2,2) = 0.0053d0

     ! Average of TERPINENES and TERPINOLENE
     KOM(1,3) = 0.133d0
     KOM(2,3) = 0.0035d0

     ! Average of MYRCENE, LINALOOL, TERPINENE-4-OL, OCIMENE
     KOM(1,4) = 0.22375d0
     KOM(2,4) = 0.0082d0

     ! Average of BETA-CARYOPHYLLENE and and ALPHA-HUMULENE
     KOM(1,5) = ( 0.04160d0 + 0.0501d0 ) / 2.d0
     KOM(2,5) = 0.0d0

     ! NOT APPLICABLE -- using BETA-PINENE for all species
     ! Data from Table 4 of Griffin, et al., JGR 104 (D3): 3555-3567 (1999)
     KOM(3,:) = 0.0163d0

--Bob Y. 10:02, 19 November 2008 (EST)

Double-substitution error in GET_ALK

Please see the following discussion on the sea salt aerosols page which describes a bug in the algorithm in routine GET_ALK (in seasalt_mod.f), and how to correct it.

--Bob Y. 14:46, 18 July 2008 (EDT)

Robustness fix for reading anthropogenic SO2 and NH3

Obsolete.jpg

NOTE: This code was removed from GEOS-Chem v10-01 and higher versions. Emissions in these versions are now handled by HEMCO.

Daven Henze wrote:

Hi team,
I was doing some GEOS-Chem simulations with a non-standard set of tracers, and I noticed that some of my emissions from SE Asia were being set to zero.
I found the source of this problem in sulfate_mod.f and made the updates shown below. This isn't so much of a bug fix as it is a small update to make the code more robust. You need to change the code in 3 places.
1. In subroutine READ_ANTHRO_SOx (in sulfate_mod.f):
                     ! Overwrite EDGAR SO2 w/ David Streets' [kg SO2/s]
                     !<<<<<<<<
                     ! BUG FIX: Hardwiring IDTSO2 = 26 can cause problems
                     !          when adding / removing species (dkh, 10/31/08)
                     ! OLD:
                     !EDG_SO2 = GET_STREETS_ANTHRO( I,  J,
                     !                              26, KG_S=.TRUE. )
                     ! NEW:
                     EDG_SO2 = GET_STREETS_ANTHRO( I,  J,
     &                                             IDTSO2, KG_S=.TRUE. )
                     !<<<<<<<
2. also in READ_ANTHRO_SOx
                     ! Overwrite GEIA SO2 w/ David Streets' SO2 [kg SO2/s]
                     !<<<<<<<<
                     ! BUG FIX: Hardwiring IDTSO2 = 26 can cause problems
                     !          when adding / removing species (dkh, 10/31/08)
                     ! OLD:
                     !ESO2_an(I,J,1) = GET_STREETS_ANTHRO( I, J, 26,
                     !                                    KG_S=.TRUE. )
                     ! NEW:
                     ESO2_an(I,J,1) = GET_STREETS_ANTHRO( I, J, IDTSO2,
     &                                                    KG_S=.TRUE. )
                     !<<<<<<<<
3. In READ_ANTHRO_NH3 (also in sulfate_mod.f):
               USE TRACERID_MOD, ONLY : IDTNH3

               ...

               ! Overwrite with David Streets emissions [kg NH3/s]
               !<<<<<<<<
               ! BUG FIX: Hardwiring IDTNH3 = 30 can cause problems
               !          when adding / removing species (dkh, 10/31/08)
               ! OLD CODE
               !ENH3_an(I,J) = GET_STREETS_ANTHRO( I, J, 30, KG_S=.TRUE.)
               !                                  KG_S=.TRUE.   )
               ! NEW CODE
               ENH3_an(I,J) = GET_STREETS_ANTHRO( I, J, IDTNH3,
    &                                            KG_S=.TRUE.   )
               !<<<<<<<< 

--Bob Y. 10:01, 3 November 2008 (EST
--Bob Yantosca (talk) 15:51, 16 November 2017 (UTC)

Minor bug in gasconc.f & calcrate.f

Obsolete.jpg

NOTE: these routines were removed in GEOS-Chem v11-01, when FlexChem was implemented.

Dylan Millet wrote:

I found what I believe to be a bug in the gasconc and calcrate routines related to dry deposition, in the loop over 1 .. NDRYDEP(NCS). For example, in gasconc.f:
DO 130 N = 1,NDRYDEP(NCS)
     NK = NTDEP(N)
...
The problem is that the loop needs to be over NUMDEP (the number of geos-chem dry dep species), not ndrydep (the number of dry dep reactions in globchem.dat). The elements of NTDEP are defined in setemdep.f according to a loop over NUMDEP.
So currently any species with a geos-chem dry dep ID > NDRYDEP will not be done in those loops. For example in my simulation NUMDEP =30 but NDRYDEP is only 12.
I changed the relevant lines in the two routines to a loop over numdep and it seems to work. This requires a "USE DRYDEP_MOD, ONLY : NUMDEP" line at the top of each.


Philippe Le Sager replied:

you are right. These 2 routines should loop over NUMDEP. In the actual standard code it does not make a difference, since the drydep tracers with a drydep reaction are the 10 first ones. But that could change, so this is definitively a coding error, and not just a typo.
Actually we should use a NUMDEP(NCS) variable to be rigorous, since we are interfacing with Jacobson's work here. However, we only use one regime (ncs=1), so this is not a problem.


The two lines that require modifications are: line 249 of calcrate.f and line 311 of gasconc.f. You basically need to replace

DO N = 1,NDRYDEP(NCS)

with

DO N = 1,NUMDEP

and make sure that you have

 USE DRYDEP_MOD,      ONLY : NUMDEP

--phs 15:21, 19 November 2008 (EST)
--Bob Yantosca (talk) 15:52, 16 November 2017 (UTC)

Minor bug in emfossil.f

Obsolete.jpg

NOTE: routine emfossil.F was removed from GEOS-Chem v10-01 and higher versions. Emissions in these versions are now handled by HEMCO.

Aaron van Donkelaar wrote:

I noticed a minor bug in emfossil.f when using CO from the Streets 2000 inventory. The ENDIF on line 454 (v7-04-12) should be moved up to before:
   ! Convert from molec/cm2/s to kg/box/timestep in order
   to be in the proper units for EMISRR array
   EMX(1) = STREETS * ( DTSRCE * AREA_CM2 ) / XNUMOL(NN)
Otherwise, any grid boxes where Streets CO is zero, GEOS-Chem will use GEIA/EDGAR instead. I don't imagine this would occur at any significant locations, so the over effect should be neglible, but it should be changed.

Bob Yantosca replied:

You are right, that definitely is a bug (but as you say, maybe a minor one). So here is the fix (here shown for BRAVO), but you need to apply this to the EMEP, STREETS, and BRAVO emissions sections in emfossil.:
       !--------------------------------------------------------------
       ! Get CO from BRAVO inventory over Europe
       !--------------------------------------------------------------

       ! If we are using BRAVO emissions ...
       IF ( LBRAVO ) THEN

          ! If we are over the Mexican region ...
          IF ( GET_BRAVO_MASK( I, J ) > 0d0 ) THEN

             ! Get BRAVO emissions
             BRAVO = GET_BRAVO_ANTHRO( I, J, NN )

             ! -1 indicates tracer NN does not have BRAVO emissions
             !-----------------------------------------------------------
             ! Prior to 11/19/08:
             ! Use more robust test to only screen out -1 values
             ! and not zero values (which could be valid emissions)
             ! (avd, phs, bmy, 11/19/08)                            
             !IF ( BRAVO > 0d0 ) THEN
             !-----------------------------------------------------------
             IF ( .not. ( BRAVO < 0d0 ) ) THEN

                ! Apply time-of-day factor
                BRAVO  = BRAVO * TODX

                ! Convert from molec/cm2/s to kg/box/timestep in order
                ! to be in the proper units for EMISRR array
                EMX(1) = BRAVO * ( DTSRCE * AREA_CM2 ) / XNUMOL(NN)

             ENDIF
          ENDIF
       ENDIF
Note that the IF test:
  IF ( .not. ( BRAVO < 0d0 ) ) THEN
is now robust, because it this avoids a direct equality test to a floating point number.

--Bob Y. 14:53, 19 November 2008 (EST)
--Bob Yantosca (talk) 15:52, 16 November 2017 (UTC)

Fix for mass balance of HNO3 and NIT

Please see the following discussion about a minor algorithmic fix that is needed to ensure mass balance of HNO3 and NIT on the sulfate aerosols page.

--Bob Y. 09:53, 20 November 2008 (EST)

Diagnostic fixes

Bug in ND43

Prasad Kasibhatla wrote:

We have run a full chem simualtion with v8-01-01 with the variable tropopause option. We save out daily average OH using the ND43 diagnostic. When I look at the 3 d OH fields in ctm.bpch, I find that at there are some unrealistically high values. Typically, values are ok as one goes up in the vertical, and then there is an unrealistically large values, and then 0's. For example, at i=8, j=10, on Jan 4, 2006 we get:
          K   OH
         ...
         11 436531.1
         12 1856526.
         13 1826474.
         14 1.9205676E+26
         15 0.0000000E+00
         16 0.0000000E+00
         17 0.0000000E+00
         18 0.0000000E+00
         19 0.0000000E+00
         20 0.0000000E+00
         21 0.0000000E+00
         22 0.0000000E+00

I assume this is some sort of bug in writing out the diagnostic and not a problem in the model itself. Any insights?

I dont' think the problem is with the ND45 counter affecting the ND43 counter, because we run with the following in the diagnostic menu

ND43: Chem OH,NO,HO2,NO2: 30 all
  ==> OH/HO2 time range :  0 24
  ==> NO/NO2 time range :  10 14
ND45: Tracer Conc's : 30 1 2 4 20
  ==> ND45 Time range   :      10 11 


Philippe Le Sager replied:

B[y] looking closely at the algorithms used in the code, I notice the following:
  • concentration are accumulated if boxes are not in the stratosphere (case of tests on JLOOP)
  • counters are incremented if boxes are in the troposphere
The two tests are slightly different, and one is not the exact logical NOT of the other. The stratosphere test is a "<= to tropopause pressure" test, the troposphere test is a strict ">". There is always numerical issues when there is an = in your tests, equality depending on the computer precision in representing number. The idea is summarized here: http://www.ibiblio.org/pub/languages/fortran/ch1-8.html#02
As you suggest when the tropopause is exactly between two boxes, this issue is raised and then the diagnostic (as written now) is wrong.
The best thing to do is to make the algorithm more robust. A couple of things can be done:
(1) we can improve the tests defined in the tropopause_mod.f. We can ensure that one test is the logical NOT of the other. We could also use an EPS value as show in the link above, but that would be more complicated than needed. I simply reduced the function ITS_IN_THE_STRAT to one line of code:
     IS_STRAT = .NOT.( ITS_IN_THE_TROP(I,J,L) )
(2) we can also make diag3.f more robust. So far we use an old trick to avoid a 0/0, knowing it should give zero: add +1d-20 to the denominator. A more rigorous approach is to use the safe_div routine (in erro_mod.f), but we will have to loop over each boxes. I used the WHERE routine instead, and replace:
           SELECT CASE ( N )

              ! OH
              CASE ( 1 )
                 SCALE_TMP3D(:,:,1:LD43) = FLOAT( CTOH ) + 1d-20
                 UNIT                    = 'molec/cm3'
                 
              ! NO
              CASE ( 2 )
                 SCALE_TMP3D(:,:,1:LD43) = FLOAT( CTNO ) + 1d-20
                 UNIT                    = 'v/v'

              ! HO2 (rvm, bmy, 2/27/02)
              CASE ( 3 )
                 SCALE_TMP3D(:,:,1:LD43) = FLOAT( CTHO2 ) + 1d-20
                 UNIT                    = 'v/v'

              ! NO2 (rvm, bmy, 2/27/02)
              CASE ( 4 )
                 SCALE_TMP3D(:,:,1:LD43) = FLOAT( CTNO2 ) + 1d-20
                 UNIT                    = 'v/v'

              ! NO3 (rjp, bmy, 1/16/03)
              CASE ( 5 )
                 SCALE_TMP3D(:,:,1:LD43) = FLOAT( CTNO3 ) + 1d-20
                 UNIT                    = 'v/v'

              CASE DEFAULT
                 CYCLE
           END SELECT

           DO L = 1, LD43
              ARRAY(:,:,L) = AD43(:,:,L,N) / SCALE_TMP3D(:,:,L)
           ENDDO
           
With:
           ! default units
           UNIT = 'v/v'


           SELECT CASE ( N )

              ! OH
              CASE ( 1 )
                 WHERE( CTOH /= 0 )
                    ARRAY(:,:,1:LD43) = AD43(:,:,1:LD43,N) /
    $                    FLOAT( CTOH )
                 ELSEWHERE
                    ARRAY(:,:,1:LD43) = 0.
                 ENDWHERE

                 UNIT = 'molec/cm3'
                 
              ! NO
              CASE ( 2 )
                 WHERE( CTNO /= 0 )
                    ARRAY(:,:,1:LD43) = AD43(:,:,1:LD43,N) /
    $                    FLOAT( CTNO )
                 ELSEWHERE
                    ARRAY(:,:,1:LD43) = 0.
                 ENDWHERE
                

              ! HO2 (rvm, bmy, 2/27/02)
              CASE ( 3 )
                 WHERE( CTHO2 /= 0 )
                    ARRAY(:,:,1:LD43) = AD43(:,:,1:LD43,N) /
    $                    FLOAT( CTHO2 )
                 ELSEWHERE
                    ARRAY(:,:,1:LD43) = 0.
                 ENDWHERE


              ! NO2 (rvm, bmy, 2/27/02)
              CASE ( 4 )
                 WHERE( CTNO2 /= 0 )
                    ARRAY(:,:,1:LD43) = AD43(:,:,1:LD43,N) /
    $                    FLOAT( CTNO2 )
                 ELSEWHERE
                    ARRAY(:,:,1:LD43) = 0.
                 ENDWHERE
                

              ! NO3 (rjp, bmy, 1/16/03)
              CASE ( 5 )
                 WHERE( CTNO3 /= 0 )
                    ARRAY(:,:,1:LD43) = AD43(:,:,1:LD43,N) /
    $                    FLOAT( CTNO3 )
                 ELSEWHERE
                    ARRAY(:,:,1:LD43) = 0.
                 ENDWHERE


              CASE DEFAULT
                 CYCLE

           END SELECT
Both of these solutions have now been incorporated into GEOS-Chem v8-01-02.

--phs 15:00, 19 November 2008 (EST)

Problem w/ ND65 diagnostic and dynamic tropopause

Obsolete.jpg

NOTE: The CSPEC array (and all other SMVGEAR arrays) were removed in GEOS-Chem v11-01, when FlexChem was implemented.

Yuxuan Wang wrote:

It looks like that it's the dynamic tropopause in v8-01-01 that causes the unrealistically high AD65 values (prod and loss rate of chemical families). When I turn off the dynamic tropopause in input.geos, the model gives AD65 that's reasonable and also comparable to my previous simulations with code version 7. I took a careful look of tropopause_mod.f, but couldn't find where the problem is.
Yuxuan

Philippe Le Sager wrote:

I think I found the root of your problem with P/L diagnostic. The line 606 (subroutine do_diag_pl, in diag_pl_mod.f):
          ! Zero each "fake" ND65 prod/loss family for next iteration
          CSPEC(JLOOP,IFAM(N)) = 0.0d0
is done too late in the code. Here is the full story:
At each time step, the CSPEC_FULL array is used to initialize the CSPEC array before entering SMVGEAR. CSPEC_FULL is filled with CSPEC after SMVGEAR. So it should account for the line 606 above, but it does not since the family P/L diagnostic is done after CSPEC_FULL has been updated.
The fix is easy. In chemdr.f you need to move the call to SAVE_FULL_TROP to the end of the routine, so CSPEC_FULL is updated after the P/L diagnostic.
Philippe

Yuxuan Wang wrote:

I just did a one-day test and it worked! P/L diagnostics now are at the right order of magnitude after I turned on the variable tropopause. That's indeed the fix. Thank you!!
Yuxuan

--Bob Y. 16:17, 3 June 2008 (EDT)
--Bob Yantosca (talk) 15:53, 16 November 2017 (UTC)

Albedo diagnostic in GEOS-4

NOTE: We are phasing out binary punch diagnostics output, in favor of netCDF output.

Lyatt Jaeglé wrote:

I was saving the daily albedo output in GEOS-Chem (v8-01-01) via diagnostic DAO-FLDS and found that the albedo is greater than 1. In fact, it seems to be a factor of 2 higher than it should be. [...] I was running an offline aerosol simulation. Is there a reason for the albedo output to be multiplied by two or is it a bug?

Philippe Le Sager replied:

This is a bug. ALBEDO is an I6 field in GEOS-3 but an A3 in GCAP, GEOS-4 and GEOS-5. The difference between models was not accounted for and ALBEDO was considered an I6 field in all cases. The fix is easy and will go in the next release. Around line 2996 in diag3.f, Case (14) should read:
              CASE ( 14 )

     #if   defined( GEOS_3 ) 
                 SCALEX = SCALE_I6 
     #else
                 SCALEX = SCALE_A3
     #endif 
                 UNIT   = 'unitless'

             CASE ( 15 )

Note that this bug was only affecting the diagnostic output. The Albedo value was correct within the code.

--phs 08:53, 3 September 2008 (EDT)

Pressure diagnostic : PS-PTOP vs. PEDGE

NOTE: We are phasing out binary punch diagnostics output, in favor of netCDF output.

There is some confusion about the pressure diagnostic in timeseries outputs and ND31 output. The data are correct but two different category names are used. Starting with v8-01-01, GEOS-Chem uses PEDGE-$ for ND31 instead of PS-PTOP. That gives you a 3D bottom-edge-pressure field instead of the surface pressure.

If you only want the surface pressure, use/request the first level only in the input.geos, and in any case use the </tt>PEDGE-$</tt> category name in GAMAP and your codes.

The timeseries diagnostics (ND48-49-50-51) still uses PS-PTOP. This is a bug yet to be fixed, since gamap_mod.f does not write a PS-PTOP category into diaginfo.dat anymore. Duncan gives a solution to access the pressure in those diagnostic:

Duncan Fairlie wrote:

I'm manually changing PEDGE-$ to PS-PTOP in the diaginfo.dat file generated by the model run, in order to read surface pressure generated by ND50.

--phs 12:12, 2 September 2008 (EDT)

NOTE: This has now been fixed in v8-01-02.

--Bob Y. 10:33, 16 December 2008 (EST)

Problem w/ ND65 diagnostic and dynamic tropopause

NOTE: We are phasing out binary punch diagnostics output, in favor of netCDF output.

Please follow this link to read about a problem with the ND65 diagostic and the dynamic tropopause, and how to fix it. This problem has now been fixed in GEOS-Chem v8-01-02.

--Bob Y. 10:05, 20 November 2008 (EST)

Minor bug in log file output

The log files from v8-01-01 runs give the GEOS4 data directory for the GEOS5 directory. This does not affect the runs, and has now been fixed in GEOS-Chem v8-01-02.

--phs 10:10, 7 May 2008 (EDT)