- 1 Overview
- 2 Previous issues now resolved in v8-02-02
- 3 Outstanding issues not yet resolved in v8-02-02
BETA RELEASE -- RELEASE DATE 08 Jun 2009
Contains everything in GEOS-Chem v8-02-01 plus the following updates:
- Non-local Planetary Boundary Layer scheme for GEOS-5 only, developed by Jintai Lin.
Note: This is an option in input.geos
- BOND inventory for BC and OC with monthly variations, prepared by Eric Leibensperger.
With the non-local PBL scheme, the emissions and dry deposition are not uniformly distributed in the PBL anymore. All surface emissions and dry deposition are considered as fluxes in the PBL code and not as reactions in the chemistry. Only airborne emissions (lightning and aircraft) are kept as reactions for the chemistry (however, their small surface contribution is moved to the PBL scheme code as other emissions). These changes are necessary because the PBL scheme uses the emission and dry deposition fluxes to calculate the non-local terms.
Lin, J.-T., D. Youn, X.-Z. Liang, and D. J. Wuebbles (2008), Global model simulation of summertime U.S. ozone diurnal cycle and its sensitivity to PBL mixing, spatial resolution, and emissions, Atmos. Environ., doi:10.1016/j.atmosenv.2008.08.012.
Previous issues now resolved in v8-02-02
The following user-reported bugs have now been corrected in v8-02-02:
Bug with ND52 diagnostic
The ND52 diagnostic for gamma(HO2) doesn't work if you ask to output a subset of levels. You need to add a check on the levels when calculating AD52. You need to change the following lines in calcrate.f:
IF ( ND52 > 0 ) THEN ! Archive gamma HO2 in AD52 AD52(IX,IY,IZ) = & AD52(IX,IY,IZ) + DUMMY3(KLOOP) ENDIF
IF ( ND52 > 0 ) THEN ! Archive gamma HO2 in AD52 IF ( IZ <= LD52 ) THEN AD52(IX,IY,IZ) = & AD52(IX,IY,IZ) + DUMMY3(KLOOP) ENDIF ENDIF
This bug was solved in v8-02-02.
--Ccarouge 16:51, 16 June 2009 (EDT)
EPA/NEI inventory: reset other species to zero
Havala O. T. Pye (firstname.lastname@example.org) wrote:
- Hi all,
- I've noticed a potential problem with how the EPA NEI99 inventory is used in EMFOSSIL.
- My understanding is that ANTHROEMS reads in anthropogenic emissions and puts them in the EMISR array. If a regional inventory is available, EMFOSSIL should override the EMISR values and update EMISRR.
- Emissions for ALD2 and many of the new dicarbonyl species are not in the EPA inventory so they get reset to zero over the U.S. I suggest changing the default value (lines 1269 and 1315, epa_nei_mod.f) in GET_EPA_ANTHRO to -1d0 and using a check like the other regional inventories in emfossil.f (starting line 574, excerpt below).
!-------------------------------------------------------------- ! Get CO & Hydrocarbons from EPA/NEI inventory over the USA !-------------------------------------------------------------- ! If we are using EPA/NEI99 emissions ... IF ( LNEI99 ) THEN ! If we are over the USA ... IF ( GET_USA_MASK( I, J ) > 0d0 ) THEN ! Get EPA/NEI emissions (and apply time-of-day factor) EPA_NEI = GET_EPA_ANTHRO( I, J, NN, WEEKDAY ) ! hotp fix for species not present (hotp 5/28/09) IF ( .not. ( EPA_NEI < 0d0 ) ) THEN ! apply time of day factor EPA_NEI = EPA_NEI * TODX ! Convert from molec/cm2/s to kg/box/timestep in order ! to be in the proper units for EMISRR array EMX(1) = EPA_NEI * ( DTSRCE * AREA_CM2 ) & / XNUMOL(NN) ENDIF ENDIF ENDIF
--Ccarouge 11:50, 29 May 2009 (EDT)
Scale factor for oceanic acetone for GEOS5 2x2.5
It seems the scale factor for the oceanic source of acetone was never defined for GEOS5 2x2.5. Old versions of the code would use a value of 1. But with version 8-02-01, the scale factor is not defined and the compilation would choke on it.
About this problem, Daniel wrote (email@example.com):
- You can do the GEOS-5 scaling simply on the basis of surface area, i.e., 1 for 4x5 and 0.25 for 2x2.5. No need to worry about differences in sea surface T and wind speeds - they will have only a very small effect and this oceanic source is very uncertain anyway.
So if you want to use GEOS-5 with a resolution 2x2.5 you need to change the following lines in acetone_mod.f:
#elif defined( GEOS_5 ) #if defined( GRID05x0666 ) && defined ( NESTED_CH ) ! GEOS-5 0.5 x 0.667, scaled to 4x5 (dan, 11/6/08) ! This scale factor produces too little acetone. (tmf, 3/05/09) !REAL*8, PARAMETER :: SCALE_FACTOR = 0.0008d0 REAL*8, PARAMETER :: SCALE_FACTOR = 0.015369d0 #elif defined( GRID4x5 ) REAL*8, PARAMETER :: SCALE_FACTOR = 0.9551d0 #endif
#elif defined( GEOS_5 ) #if defined( GRID05x0666 ) && defined ( NESTED_CH ) ! GEOS-5 0.5 x 0.667, scaled to 4x5 (dan, 11/6/08) ! This scale factor produces too little acetone. (tmf, 3/05/09) !REAL*8, PARAMETER :: SCALE_FACTOR = 0.0008d0 REAL*8, PARAMETER :: SCALE_FACTOR = 0.015369d0 #elif defined( GRID4x5 ) REAL*8, PARAMETER :: SCALE_FACTOR = 0.9551d0 #elif defined( GRID2x25 ) REAL*8, PARAMETER :: SCALE_FACTOR = 0.25d0 #endif
This value for the SCALE_FACTOR will be added to the next version.
--Ccarouge 14:38, 28 May 2009 (EDT)
Bug with PRIVATE declaration in sulfate_mod.f
In SRCNH3 (in sulfate_mod.f), please replace the PRIVATE declaration line 4939 (in v8-02-01) :
!$OMP+PRIVATE( I, J )
with the PRIVATE declaration :
!$OMP+PRIVATE( I, J, AREA_CM2, EPA_AN, EPA_BF, CAC_AN )
and in SRCSO4 please change the PRIVATE declaration in line 4690 (in v8-02-01) from:
!$OMP+PRIVATE( I, J, AREA_CM2, EPA_AN, EPA_BF )
!$OMP+PRIVATE( I, J, AREA_CM2, EPA_AN, EPA_BF, CAC_AN )
In both cases the CAC_AN variable has to be added to the PRIVATE declaration.
--Ccarouge 10:22, 28 May 2009 (EDT)
Bug with online 2ndary aerosol
Replace line 412 of aerosol_mod.f:
IF ( IDTSOAM ) THEN
IF ( IDTSOAM > 0 ) THEN
This is a bug in GEOS-Chem v8-02-01 release. However, it is more of a matter of Fortran style. The expression in parentheses in the IF statement should be a logical expression and not an integer expression, as is the case above. Some compilers (e.g. PGI) will always choke on this. However, other compilers (e.g. IFORT) will evaluate the expression as TRUE if the integer IDTSOAM is nonzero. This will be fixed in the following release.
--phs 09:56, 28 May 2009 (EDT)
Bug for dust in ND48
Colette L. Heald (firstname.lastname@example.org) wrote:
- I was making changes in the AOD calculation in my version of the code and noticed that in diag48 the dust AOD is not properly scaled from 1000 nm to :400 nm. I believe line 543 (in v8-01-04) should be changed from:
Q(L) = ODMDUST(I,J,L,R)
Q(L) = ODMDUST(I,J,L,R) * SCALE400nm
--Ccarouge 12:07, 4 June 2009 (EDT)
Outstanding issues not yet resolved in v8-02-02
Tracers apparently omitted in ND38, ND39, ND44 diagnostics
Prasad Kasibhatla (email@example.com) wrote:
- I am having an apparent problem with the ND38, ND39, and ND44 diag output in GC v8-02-02. I run fullchem simulation with thefollowing set in input.geos:
ND38: Cld Conv scav loss: 30 all ND39: Wetdep scav loss : 30 all ND44: Drydep flx/vel : 1 all
- When I ran with these setting in v8-01-01, the ctm.bpch file contained ND38 and ND39 output for tracer numbers 7, 8, 20, 24, and 26-43. Now in v8-02-02 the output is being written out only for tracer numbers 7,8, 20, and 24.
- Similarly, ND44 output in v8-01-01 was being written out for tracers 1, 2, 3, 7, 8, 15, 16, 17, 20, 22, 26-43. Now in v8-02-02, output for tracers 29-43 in not being written out.
- Any ideas as to what might have changed?
Bob Yantosca (firstname.lastname@example.org) replied:
- The quick fix is to just list all the tracer #'s explicitly for the ND38, ND39, ND43 diagnostics:
ND38: Cld Conv scav loss: 47 7 8 20 24 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 ND39: Wetdep scav loss : 47 7 8 20 24 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 ... ND43: Chem OH,NO,HO2,NO2: 1 1 2 3 7 8 15 16 17 20 22 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
- The diag3.f file was modified (by Claire Carouge) to just print out tracer #'s that are expliclitly requested for certain diagnostics. I believe that this was in response to another bug that was reported recently.
--Bob Y. 10:32, 23 June 2009 (EDT)
Claire Carouge (email@example.com) replied:
- For all diagnostics, when using the 'all' keyword in input.geos, GEOS-Chem "replaces" it by the N first consecutive tracers for the run, N being the maximum number of tracers for a given diagnostic. So for any diagnostic where 'all' means a subset of non-consecutive tracers, the 'all' keyword shouldn't work and the list of tracers should be given instead.
--Ccarouge 10:18, 10 July 2009 (EDT)