GEOS-Chem v9-01-01

From Geos-chem
Jump to: navigation, search

Contents

Overview

History

The table below shows the previous, current, and successive versions of GEOS-Chem:

Previous version This version Next version
GEOS-Chem v8-03-02 GEOS-Chem v9-01-01 GEOS-Chem v9-01-02
PUBLIC RELEASE 07 Sep 2010 PUBLIC RELEASE Feb 10 2011
RE-RELEASED ON 07 Jun 2011
PUBLIC RELEASE 28 Nov 2011
View v9-01-01 benchmark history View v9-01-02 benchmark history

--Bob Y. 10:21, 16 January 2014 (EST)

What's new in this version

GEOS-Chem v9-01-01 contains the following new features:

Feature Type Submitted by Benchmark
(1 Month)
Status
Capability to run with GMAO MERRA met fields Structural Bob Yantosca (Harvard) v9-01-01 Approved 07 Jun 2011
Improvements to algorithms for convective updraft scavenging and wet deposition Science Helen Amos (Harvard)
Bess Corbitt (Harvard)
" " " "
Updated volcanic SO2 emissions from Aerocom Science Jenny Fisher (Harvard) " " " "
Allow both washout and rainout to occur when new precipitation forms Science Qiaoqiao Wang (Harvard) " " " "
Updated lightning parameterization and fix for cloud-top-height algorithm Science Lee Murray (Harvard) " " " "
Now use proper units for snow depth in dust emissions module Bug Fix GEOS-Chem Support Team " " " "
Important bug fixes for ship emissions Bug Fix Geert Vinken (T.U. Eindhoven) " " " "
Fixes to correct errors in diagnostic archival and reporting Bug Fix Chris Holmes (UC Irvine)
Jaegun Jung (Environ Corp.)
" " " "
Ability to start simulations at times other than 0h GMT Structural GEOS-Chem Support Team " " " "
Fix to prevent division-by-zero errors in module sulfate_mod.f Bug Fix Jamin Koo (MIT) " " " "
Ability to run offline simulations on the GEOS-5 72-layer grid Structural GEOS-Chem Support Team " " " "
Updates to improve execution efficiency in the non-local PBL mixing module Structural GEOS-Chem Support Team " " " "
Corrected typos in modules megan_mod.f and edgar_mod.f Bug Fix Dylan Millet (U. Minnesota)
GEOS-Chem Support Team
" " " "
Several post-release patches to fix issues that were identified after the initial release of v9-01-01. Bug Fix Various " " " "

--Bob Y. 16:53, 8 September 2011 (EDT)

New data directories

The following new data directories have been added for GEOS-Chem v9-01-01. You will have to download the directories relevant to your simulation. (For example, if you are not using the nested grid simulations, or if you are not using the mercury simulation, you don't have to download those.)

You can download these directories with anonymous FTP or the Wget utility. For instructions, please see Chapter 2.4, Downloading the GEOS-Chem shared data directories in the GEOS-Chem Online User's Guide.

GEOS_0.5x0.666_CH/lightning_NOx_201101    # China/SE Asia nested-grid
GEOS_0.5x0.666_NA/lightning_NOx_201101    # N. American nested-grid
GEOS_2x2.5/lightning_NOx_201101           # 2 x 2.5 fullchem simulation
GEOS_4x5/lightning_NOx_201101             # 4 x 5 fullchem simulation

GEOS_1x1/CO2_201003                       # CO2 simulation only
GEOS_2x2.5/CO2_201003                     # CO2 simulation only
GEOS_4x5/CO2_201003                       # CO2 simulation only

GEOS_1x1/volcano_SO2_201010               # Global full-chemistry simulations

GEOS_1x1/mercury_201002                   # Hg simulation only
GEOS_4x5/mercury_201007                   # Hg simulation only

GEOS_1x1/EMEP_200911/EMEP_mask.geos.1x1   # Corrected mask for EMEP ship emissions

--Bob Y. 14:24, 11 February 2011 (EST)

Post-release patches

We were not able to fix these issues until after the release of v9-01-01 (10 Feb 2011). We have since created software patches to correct each of these issues. Each of these patches are now contained in the re-release of v9-01-01 (07 Jun 2011).

Double counting of biofuel emissions over Asia

Obsolete.jpg

This code was removed from GEOS-Chem v10-01 and newer versions. All biofuel emissions are now implemented via the HEMCO emissions component.

  • Designated as: v9-01-01-Patch-biofuel
  • Applied: 2011-02-18
  • Author: Claire Carouge
  • Signed off by: Bob Yantosca

I found a bug in biofuel_mod.f about Streets emissions. Initially we used Streets 2000 for years <= 2005, then Streets 2006 for year >= 2006. But this was changed because of discrepancies in the total emissions between 2005 and 2006. So now we use Streets 2000 for years <=2000 and Streets 2006 for years >= 2001. The problem is that Streets 2006 contains biofuels and not Streets 2000. So in biofuel_mod.f, there is to change the following lines to avoid double counting biofuel emissions over Asia:

           !-----------------------------------------------------------
           ! If we are over SE ASIA and are using Streets 2006 (that is
           ! emission year is GE 2006), set BIOFUEL to zero since they
           ! are already accounted for (phs, 3/17/08)
           !-----------------------------------------------------------
           IF ( LSTREETS .and. ( SIM_YEAR >= 2006 ) ) THEN

to

           !-----------------------------------------------------------
           ! If we are over SE ASIA and are using Streets 2006 (that is
           ! emission year is GE 2001), set BIOFUEL to zero since they
           ! are already accounted for (phs, 3/17/08)
           !-----------------------------------------------------------
           IF ( LSTREETS .and. ( SIM_YEAR >= 2001 ) ) THEN

The modification for Streets was done in v8-03-01, so the modification should be done for everyone using versions v8-03-01 and later. We shall release a patch for v9-01-01 and standardize the fix in v9-01-02.

--Ccarouge 17:55, 17 February 2011 (EST)
--Bob Yantosca (talk) 16:02, 16 November 2017 (UTC)

Updated CO2 emissions

Obsolete.jpg

This code was removed from GEOS-Chem v10-01 and higher versions. All emissions are now handled by HEMCO.

  • Designated as: v9-01-01-Patch-CO2
  • Applied: 2011-02-25
  • Author: Ray Nassar
  • Signed off by: Bob Yantosca

New CO2 emissions from CDIAC were made available after the v9-01-01 release. We issued a patch so that users of the CO2 simulation could utilize these new emissions in their GEOS-Chem simulations right away. For more information, please see this wiki post.

--Bob Y. 15:26, 6 April 2011 (EDT)
--Bob Yantosca (talk) 16:03, 16 November 2017 (UTC)

Typos in vdiff_mod.f90

  • Designated as: v9-01-01-Patch-VDIFF
  • Applied: 2011-03-25
  • Author: Jintai Lin
  • Signed off by: Bob Yantosca

Jintai Lin pointed out that some lines of code were not properly rendered when we cleaned up vdiff_mod.f90 for GEOS-Chem v9-01-01. The corrected code is now contained in the re-release of v9-01-01 (07 Jun 2011).

Also, to provide better compatibility with the PGI compiler, we now force all numbers in vdiff_mod.f90 to use the double-precision "D" exponents (i.e. replace instances of 0.0 with 0.0d0, etc.). This will prevent compilation errors for the PGI compiler. (For more information about double-precision exponents, please see the GEOS-Chem Style Guide.)

--Bob Y. 14:46, 7 June 2011 (EDT)

Negative tracer caused by DO_MERRA_CONVECTION

  • Designated as: v9-01-01-Patch-Conv
  • Applied: 2011-04-06
  • Author: May Fu
  • Signed off by: Bob Yantosca

This patch is now present in the re-release of v9-01-01 (07 Jun 2011).

May Fu wrote:

I've been having trouble running the v9-01-01 MERRA benchmark. All my attempts consistently halted at July 13 19:30.
I dug a little deeper and found a few possible bugs in the DO_MERRA_CONVECTION subroutine in convection_mod.f. The codes describing the accumulation of washout fluxes for aerosol and trace gases are different from those in wetscav_mod.f and don't make sense. I changed the codes to match the algorithms used in wetscav_mod.f and the simulation finished successfully.
We need to change 3 lines of code in DO_MERRA_CONVECTION:
   ! "Washout of aerosol tracers" section

   !T0_SUM = LOST + WETLOSS                 ! original
   T0_SUM = T0_SUM + WETLOSS                ! May Fu's fix

   ! "Washout of non-aerosol tracers" section
 
   !WETLOSS = MASS_WASH * WASHFRAC          ! original
   WETLOSS = MASS_WASH * WASHFRAC - T0_SUM  ! May Fu's fix

   . . .

   !T0_SUM = WETLOSS                        ! original
   T0_SUM = T0_SUM + WETLOSS                ! May Fu's fix

Helen Amos replied:

[I ran a] 1-yr (2004) mercury simulation with your changes to convection_mod.f, [which] completed successfully. I ran a control simulation for 2004 that is the exact same, minus the three changes made to convection_mod.f mentioned in the previous email. The differences in simulated wet deposition are very small. Annual global wet deposition for the control simulation is 3684 Mg and for the simulation with your changes the global wet deposition is 3770 Mg. Results for US wet deposition compared to observations from the MDN (Mercury Deposition Network) are plotted for the two simulations, and again you'll notice that the differences are subtle.

May Fu wrote:

The largest impact of the fix is that without it, my simulation simply won't run. It may not have come up in your Hg simulation because the small errors may not be noticeable for all tracers under all circumstances. For example, without the second change I made, the total WETLOSS will still be positive as long as WASHFRAC is not very close to unity. Indeed, as I mentioned, without the fix I can still run for August and September, 2005. I imagine as more people start using the MERRA code, it will become more apparent a problem.
I also did a comparison of my run (with fix) again the merra benchmark. The difference is not very large quantitatively, but there is a significant difference in the vertical profiles for soluble tracers. The bottom line is the code as it is mis-calculates the wet deposition and should be fixed.

--Bob Y. 14:47, 6 April 2011 (EDT)

Omitted code in Hg simulation

  • Designated as: v9-01-01-Patch-Hg
  • Applied: 2011-04-13
  • Authors: Chris Holmes, Jenny Fisher
  • Signed off by: Bob Yantosca

For a full description of the errors that were fixed, please see this entry on the Mercury wiki page.

--Bob Y. 10:52, 25 July 2011 (EDT)

Patches to correct errors in diagnostic printout

Two patches were issued to correct errors which had prevented certain diagnostic quantities from being saved out to disk properly.

Drydep and wetdep diagnostics

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

  • Designated as: v9-01-01-Patch-diags
  • Applied: 2011-05-26
  • Author: Bob Yantosca
  • Signed off by: Bob Yantosca

In diag3.f: In the ND44 (drydep) diagnostic, only do the special handling of isoprene-mechanism tracers if we are doing a full-chemistry simulation. This was being applied to all simulations and it caused certain tracers not to be saved to the bpch file.

In input_mod.f: For ND17, ND18, ND37, ND38, ND39 (wetdep) diagnostics, set N_TMP = N_TRACERS. Otherwise, this will cause the first 32 tracers--Bob Y. 11:00, 7 June 2011 (EDT) to print out and skip the rest.

--Bob Y. 11:00, 7 June 2011 (EDT)

Time-in-tropopause diagnostic

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

  • Designated as: v9-01-01-Patch-ND54
  • Applied: 2011-05-27
  • Author: Bob Yantosca
  • Signed off by: Bob Yantosca

The ND54 diagnostic (time-in-tropopause) is updated in diag1.f, which is called every chemistry timestep (e.g. 60 min). However, when we save out the data to disk in diag3.f, we divide by the wrong scale factor:

        SCALEDYN   = DBLE( GET_CT_DYN()  ) + 1d-32
        SCALEDIAG  = DBLE( GET_CT_DIAG() ) + 1d-32
        ...
    
            DO L = 1, LD54
               ARRAY(:,:,L) = AD54(:,:,L) / SCALEDYN
            ENDDO
   

This results in the ND54 diagnostic being precisely twice as small as it should be. The maximum value is 0.5 instead of 1.

The fix is to simply to divide by SCALEDIAG (which is updated each chemistry timestep) instead of SCALEDYN.

--Bob Y. 11:00, 7 June 2011 (EDT)

Patches to correct errors in wet deposition

Two patches were applied to correct bugs in the wet deposition algorithm.

Only apply error trap for MERRA met fields

  • Designated as: v9-01-01-Patch-wetdep_fix
  • Applied: 2011-05-26
  • Author: Bob Yantosca
  • Signed off by: Bob Yantosca

Bob Yantosca wrote:

I have found the problem in the v9-01-01 scavenging. The following block of code is present in v9-01-01 but not in v8-03-02:
   ! Check if WASHFRAC = NaN or WASHFRAC < 0.1 %
   !
   ! If WASHFRAC = NaN, then DSTT = NaN and SAFETY trips because
   ! tracer concentrations must be finite.WASHFRAC = NaN when F = 0.
   ! When less than 0.1% of a soluble tracer is available for washout
   ! DSTT < 0 and SAFETY trips.  (Helen Amos, 20100928)
   IF ( IT_IS_NAN( WASHFRAC ) ) THEN
      CYCLE
   ELSEIF ( WASHFRAC < 1D-3 ) THEN
      CYCLE
   ENDIF
This IF block is an error trap that Helen Amos and I added to skip over pathological conditions when using the MERRA met fields. However, if this IF block is applied when using GEOS-5, we end up skipping washout for some grid boxes where we should really be doing washout. I believe this results in the discrepancy that we are seeing in the soluble tracers between v8-03-02 and v9-01-01.
The fix is to only apply this IF block if we are using MERRA met fields (i.e. to block it out with an #ifdef statement).

--Bob Y. 11:17, 7 June 2011 (EDT)

Apply washout to the correct fraction of the grid box

  • Designated as: v9-01-01-Patch-washout
  • Applied: 2011-05-27
  • Author: Qiaoqiao Wang
  • Signed off by: Qiaoqiao Wang

The following changes were applied:

  1. In subroutine DO_WASHOUT_ONLY (of wetscav_mod.f), we only wash out tracer from the area of the grid box that is actually undergoing washout (F_WASHOUT) instead of from the total precipitating area of the grid box (F_WASHOUT + F_RAINOUT). We adjust the WASHFRAC variable (i.e. fraction of tracer lost to washout) accordingly.
  2. Also in subroutine DO_WASHOUT_ONLY, we correct DSTT (i.e. the array which holds the mass removed from the column by wet scavenging) to account for the wet scavenging loss due to rainout in the same grid box.

--Bob Y. 11:17, 7 June 2011 (EDT)

Better representation of SO2 aqueous chemistry

  • Designated as: v9-01-01-Patch-AqSO2
  • Applied: 2011-05-27
  • Authors: Lin Zhang, Jenny Fisher
  • Signed off by: Bob Yantosca

The following updates were added to improve the representation of aqueous SO2 chemistry in sulfate_mod.f:

For GEOS-5 and MERRA met fields:

LWC (liquid water content, as computed directly from the GEOS-5/MERRA quantity QL) is a grid-box averaged quantity. To improve the representation of sulfate chemistry, we divide LWC by the cloud fraction and compute sulfate chemistry based on the LWC within the cloud. We get the appropriate grid-box averaged mass of SO2 and sulfate by multiplying these quantities by FC AFTER computing the aqueous sulfur chemistry within the cloud.

For GEOS-3, GEOS-4, GCAP:

LWC as returned from the GET_LWC function is the in-cloud liquid water content. To improve the representation of sulfate chemistry, we use this LWC to compute the aqueous sulfate chemistry. We then get the appropriate grid-box averaged mass of SO2 and sulfate by multiplying by FC AFTER computing the aqueous sulfur chemistry within the cloud.

--Bob Y. 12:59, 7 June 2011 (EDT)

1-year benchmark simulations

Complete information about all 1-year benchmark simulations is now posted on a separate GEOS-Chem v9-01-01 benchmark history wiki page.

--Bob Y. 12:02, 24 June 2011 (EDT)

Previous issues now resolved in v9-01-01

Patches from v8-03-02

The following bug fix patches from v8-03-02 are now standardized in v9-01-01:

  1. Transport fix for GEOS-5 nested grid simulations at 0.5° x 0.666°
  2. Typo in globchem.dat affecting yield of isoprene nitrates
  3. Updated KPP solver files (to account for the isoprene nitrate changes in globchem.dat)
  4. The parallelization problem in routine setemis.f that caused GEOS-Chem to scale poorly.
  5. The error that caused ND49 diagnostic files to not be closed at the proper time.

--Bob Y. 10:20, 12 November 2010 (EST)

Bug fix in dust_mod.f

The incorrect units for the SNOMAS field in dust_mod.f have been corrected in v9-01-01. This bug affected simulations done with GEOS-5.

--Bob Y. 12:25, 17 May 2011 (EDT)

Bug fix for biofuels in EPA/NEI05

Obsolete.jpg

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

A bug in the EPA/NEI05 emissions code was found prior to the release of GEOS-Chem v9-01-01. Long story short: when the EPA/NEI05 option is selected, the wrong biofuel emissions inventory is used over the continental USA.

This bug will be fixed in v9-01-01 and higher versions. For a complete description, please see this post on our EPA/NEI05 wiki page.

--Bob Y. 11:29, 8 February 2011 (EST)
--Bob Yantosca (talk) 16:03, 16 November 2017 (UTC)

Important bug fixes for ship emissions

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

Geert Vinken has submitted a couple of important fixes for ship emissions. These have been added to v9-01-01. For more information, please see the following links:

  1. Bug fix for ship emissions in emfossil.f
  2. Updated mask for EMEP ship emissions

--Bob Y. 15:35, 10 January 2011 (EST)

Fixes to correct errors in diagnostic archival and reporting

Duplicate diagnostics

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

Chris Holmes wrote:

I turned on diagnostics ND14-15 (convection and BL mixing) and ND24-26 (U/V/W transport fluxes), plus the other diagnostics that are on by default. I ran the simulation for 1 day. The ctm.bpch output contains *two* copies of ND14-15 and ND24-26 outputs. The other diagnostics appear normal.

In fact, the diagnostics are not written twice in the ctm.bpch file. The problem is a double definition of the categories of these diagnostics in gamap_mod.f. These diagnostics appear then twice in diaginfo.dat with two different offsets (3000 and 4000). GAMAP will then print these diagnostics twice. The fix is to comment one definition of these diagnostics in gamap_mod.f. Please comment the lines with the 4000 offset (see the SPACING * 4) in gamap_mod.f:

!      N           = N + 1
!      CATEGORY(N) = 'CV-FLX-$'
!      DESCRIPT(N) = 'Upward flux from wet conv'
!      OFFSET(N)   = SPACING * 4
!
!      N           = N + 1
!      CATEGORY(N) = 'TURBMC-$'
!      DESCRIPT(N) = 'Upward flux from PBL mixing'
!      OFFSET(N)   = SPACING * 4
!
!      N           = N + 1
!      CATEGORY(N) = 'EW-FLX-$'
!      DESCRIPT(N) = 'E/W transport flux'
!      OFFSET(N)   = SPACING * 4
!
!      N           = N + 1
!      CATEGORY(N) = 'NS-FLX-$'
!      DESCRIPT(N) = 'N/S transport flux'
!      OFFSET(N)   = SPACING * 4
!
!      N           = N + 1
!      CATEGORY(N) = 'UP-FLX-$'
!      DESCRIPT(N) = 'Up/down transport flux'
!      OFFSET(N)   = SPACING * 4

--Ccarouge 14:58, 21 September 2010 (EDT)

Fix ND15 for non-local PBL scheme

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

Chris Holmes wrote

When the non-local PBL mixing is on the TURBMC-$ diagnostic appears to save the mass tendency (kg/s) due to *all* boundary layer processes, i.e. PBL mixing + emission + dry deposition. It is supposed to be the tendency due to mixing alone.

This will be fixed in version 9-01-01 so that ND15 only output the PBL mixing and free troposphere diffusion, if any.

--Ccarouge 10:46, 24 September 2010 (EDT)
--Bob Y. 12:29, 24 June 2011 (EDT)

PEDGE-$ in timeseries diagnostics

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

Jaegun Jung wrote:

When I read PEDGE-$ in the ND49 tsYYYYMMDD.bpch files, only the first layer has significant values. From the second to the top layer, there are all zeros. According to the GEOS-Chem website, it says that ND49 still outputs PS-PTOP which is supposed to be available at the first layer. I think this feature still in ND49.

Bob Yantosca wrote:

Yes, you are correct. At present, the ND49 diagnostic is just saving out the Psurface - PTOP quantity at the surface model level. This is just historical baggage and nobody has cleaned it up since. The Psurface - PTOP quantity only really made sense for pure-sigma grids (like GEOS-1, GEOS-STRAT, and GEOS-3), since the sigma coordinate depends on this term. Therefore this diagnostic is now obsolete.
I have just modified the timeseries diagnostics (ND48, ND49, ND50, ND51, ND51b) so that they now save out the quantity PEDGE-$ (pressure at the bottom edge of each requested level) instead of Psurface - PTOP. This will be included in v9-01-01.

--Bob Y. 16:31, 12 November 2010 (EST)

Starting runs at times other than 00 GMT

Obsolete.jpg

NOTE: In GEOS-Chem v10-01 and higher versions, MEGAN biogenic emissions are now handled by HEMCO.

The MEGAN v2.1 biogenic emissions reads in several days of A3 data before the first timestep of a G-C simulation. In routine DO_OPEN_A3 (which determines if it is the right time to open a new file), we have this IF statement:

     LOGICAL, SAVE :: FIRST    = .TRUE.
        ...   
     ! Open A-3 file if it's 01:30 GMT,  or on the first call
     IF ( NHMS == 013000 .or. FIRST ) THEN
        DO_OPEN = .TRUE.
        ...
   

Therefore, when MEGAN was turned on, FIRST was set to .FALSE. because we were reading more than one day of A3 data. This caused the IF statement above to fail if we wanted to start a G-C simulation at any other time than 00 GMT.

The quick fix was to introduce an optional logical flag RESET, such that:

     ! Reset the FIRST flag if
     IF ( PRESENT( RESET ) ) THEN
        IF ( RESET ) FIRST = .TRUE.
     ENDIF
   

This makes sure that the FIRST flag is not affected by the prior A3 reads by the MEGAN emissions.

We now call OPEN_A3_FIELDS with RESET=.TRUE. from main.f for the very first time we read in the A3 data (before the time-stepping loop).

The analogous fix was also made for the MERRA reading code in merra_a1_mod.f.

Further fixes were also added as follows:

  1. Modify GET_FIRST_A3_TIME (a3_read_mod.f) to pick the first A3 data time based on the initial NYMD/NHMS
  2. Modify GET_FIRST_A6_TIME (a6_read_mod.f) to pick the first A6 data time based on the initial NYMD/NHMS
  3. Add routine GET_FIRST_I6_TIME (i6_read_mod.f) to pick the first I6 data time based on initial NYMD/NHMS
  4. Modify GET_I6_TIME (i6_read_mod.f) to find the proper I6 data time for the "6-hours-ahead" I6- data
  5. In main.f, now compute NSECb and ELAPSED_TODAY as the elapsed time since the start of the day (not the start of a GEOS-Chem simulation). This makes the interpolated fields in routine INTERP (dao_mod.f) work properly for non-00 GMT start times.

--Bob Y. 16:24, 27 September 2010 (EDT)
--Bob Yantosca (talk) 16:03, 16 November 2017 (UTC)

Fix to prevent div-by-zero in sulfate_mod.f

Jamin Koo discovered a potential source for a division-by-zero error in routine CHEM_SO2 (in sulfate_mod.f). To prevent this error, we modified the IF statements where the terms L2S and L3S are computed.

We changed the lines:

IF ( IS_SAFE_EXP( XX ) ) THEN

to:

IF ( IS_SAFE_EXP( XX ) .and. ABS( XX ) > 0d0 ) THEN

When computing the term L2S, the term XX = SO2_ss - H2O20. If SO2_ss = H2O20 = 0 (a rare but potentially possible condition), then XX = 0 and the denominator of the equation that defines L2S will go to zero. This will cause a div-by-zero condition, which may generate an Infinity or NaN value. Such denormal values can propagate through the code, adversely affecting other computations.

Therefore, when XX = 0, we skip over the "IF" portion of the statement to the "ELSE" block, where L2S is assigned a default value.

This error can also happen in the computation of L3S. In this case XX = SO2_ss - O3. Therefore, if SO2_ss = O3 = 0, then the div-by zero condition occurs. Rewriting the IF statement as described above solves the problem.

--Bob Y. 14:52, 12 November 2010 (EST)

Running offline simulations on the GEOS-5 72L grid

If you try to run one of the Offline chemistry simulations on the GEOS-5 72-level vertical grid, you may encounter an error such as this:

CHECK_VAR_TROP: LLTROP is set too low!
MAX TROPOSPHERE LEVEL =  39 and LLTROP =  38
STOP in TROPOPAUSE_MOD.F!!!

Please see this post on our Dynamic Tropopause wiki page for a full description of how this issue was corrected.

--Bob Y. 14:58, 30 November 2010 (EST)

Fixes to improve efficiency in vdiff_mod.f90

We have made several minor fixes in module vdiff_mod.f90 (i.e. the non-local PBL mixing scheme) in order to avoid parallelization errors and achieve better memory management. The fixes include:

  1. Use better method to flip arrays in vertical
  2. Retire the UPSIDEDOWN subroutine.
  3. Initialize local arrays at top of subroutine
  4. Replace instances of as2(I,J,1,NN) with as2_scal(I,J,NN) to avoid parallelization errors
  5. Combine flipping vertical dimension of AS2 with unit conversion from v/v -> kg/kg
  6. Only call routine SETEMIS if we are doing a full-chemistry simulation
  7. Define constants with the PARAMETER tag, for safety's sake
  8. In subroutine VDIFFDR, pre-save the results of the function calls ITS_A_*_SIM to local variables outside of the parallel DO loops.
  9. Minimize dependency on the NCS variable from SMVGEAR comode.h common blocks
  10. Updated comments

--Bob Y. 15:46, 10 January 2011 (EST)

[Jintai Lin] Mar 25, 2011 -- Update: I caught some errors in this newly updated vdiff_mod.f90. I have provided a revision to Bob to fix the problem. Please do NOT use the file until the revision is implemented.

Typos in megan_mod.f

Obsolete.jpg

NOTE: routine megan_mod.F was removed from GEOS-Chem v10-01 and higher versions. MEGAN biogenic emissions in these versions are now handled by HEMCO.

Please see this post on our MEGAN v2.1 biogenic emissions wiki page for a complete description of the issue.

--Bob Y. 16:20, 25 February 2015 (EST)
--Bob Yantosca (talk) 16:03, 16 November 2017 (UTC)

Typos in edgar_mod.f

Obsolete.jpg

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

Please see this post on our EDGAR anthropogenic emissions wiki page for a full description of this issue.

--Bob Y. 12:36, 20 December 2012 (EST)
--Bob Yantosca (talk) 16:04, 16 November 2017 (UTC)

Outstanding issues not yet resolved in v9-01-01

The following issues remained unresolved as of the release date of v9-01-01 (10 Feb 2011). If you are using v9-01-01, then please be aware of these. Some of these have been fixed in the next version GEOS-Chem v9-01-02, and have been noted accordingly.

Linoz parallelization

We discovered that the main DO loop in routine LINOZ_CHEM3 (in linoz_mod.f) had not been parallelized. We added the !$OMP PARALLEL DO directives to this loop, which should make this routine execute much faster.

--Bob Y. 10:25, 12 November 2010 (EST)

UPDATE: The parallelization seemed to be causing some weird behavior, so at present we have disabled this feature. The OpenMP parallel code in LINOZ_CHEM3 has been commented out. We will look into this at a later time.

--Bob Y. 11:19, 7 February 2011 (EST)

KPP may cause run to exit with error

A couple of users have reported that GEOS-Chem simulations done with the KPP/Rosenbrock solver have been dying with an error such as this:

Forced exit from Rosenbrock due to the following error:
--> Step size too small: T + 10*H = T or H < Roundoff
T=   2977.82070749661      and H=  8.168943036159003E-013

but that the same simulations work fine when using the SMVGEAR solver. We are looking into this at present.

In the meantime, if you encounter an abnormal exit from KPP, please see this wiki post, which will instruct you on how to save debug output from KPP at the point where your run dies. Please send such debug output to Adrian Sandu at Virginia Tech.

--Bob Y. 11:02, 1 March 2011 (EST)

Inconsistencies in aerosol diagnostics

This issue was corrected in GEOS-Chem v9-01-02. It was tested in the 1-month benchmark simulation v9-01-02g, which was approved on 10 Aug 2011.

In the next release of GEOS-Chem we plan to clean up some "historical baggage" in the aerosol diagnostic code. Patrick Kim noted the following inconsistencies:

  1. The OD-MAP-$ diagnostic does not take into account the removal of aerosol tracer by chemistry and wet deposition. This means that the OD-MAP-$ diagnostic is not consistent with the tracer concentrations stored in the IJ-AVG-$ diagnostic.
  2. For the current diagnostics, we compute the AOD at 400nm but scale the result to different wavelengths. With the advent of the new GEOS-Chem aerosol optical properties, we can now compute the aerosol diagnostics for whichever wavelength we wish.

NOTE: After some analysis, we decided not to modify the subroutine gasconc.f in the place where relative humidity is calculated and stored in the ABSHUM array. The GEOS-5 and MERRA met field RH is actually calculated with respect to liquid above 273.16 K, with respect to ice below 253.16 K, and is a weighted average of both at intermediate temperatures (cf MERRA file spec document). Therefore, since the ABSHUM array always contains the relative humidity w/r/t liquid water, we should use this instead of obtaining the RH directly from the met fields. Using RH directly from the met fields impacts the computation of various aerosol quantities.

--Bob Y. 17:21, 22 November 2011 (EST)

Error in partition.f when compiling with IFORT 10

Obsolete.jpg

NOTE: SMVGEAR was removed from GEOS-Chem v11-01 and replaced by FlexChem.

Prasad Kasibhatla reported an error in routine partition.f which caused a GEOS-Chem v9-01-01 execution to halt. Upon further investigation, we found that this error only occurs when compiling GEOS-Chem with the Intel Fortran Compiler version 10 (aka IFORT 10) when selecting -O2 optimization and -openmp parallelization.

We recommend that all GEOS-Chem users upgrade to Intel Fortran Compiler version 11 (aka IFORT 11). If you must use IFORT 10, then we recommend that you compile the entire code with the -O1 optimization option. For more information, please see this wiki post.

--Bob Yantosca (talk) 17:18, 15 November 2017 (UTC)

Mis-indexing when reading restart.cspec file

This issue was corrected in GEOS-Chem v9-01-02. It was tested in benchmark simulation v9-01-02c, which was approved on 21 Jul 2011.

Please see this wiki post on the Restart Files page for more information about an indexing problem when reading the restart.cspec.YYYYMMDDhh file.

--Bob Y. 17:19, 22 November 2011 (EST)