GEOS-Chem v9-02
NOTE: We shall henceforth denote GEOS-Chem versions as GEOS-Chem v9-02, etc. instead of using the previous nomenclature (e.g. GEOS-Chem v9-01-03).
Contents
- 1 Overview
- 2 Performance
- 3 Previous issues now resolved in GEOS-Chem v9-02
- 3.1 Correction for GEOS-5 PBL heights
- 3.2 Bug fixes for tagged CO simulation
- 3.3 Bug fix in nei2005_anthro_mod.F
- 3.4 Bug fix for updated CAC emissions
- 3.5 Bug fix for Br2 emissions
- 3.6 Bug in regridding of anthropogenic emissions
- 3.7 Bug in MEGAN emissions when running with MERRA or GEOS-FP
- 3.8 Additional bug fixes for MAP_A2A regridding algorithm
- 3.9 Prevent bad drydep flux values from being passed to the soil NOx emissions module
- 3.10 Bug fix for declaration of GEOS-FP PFICU, PFLCU, PFILSAN, PFLLSAN fields
- 3.11 Bug fix for reading OH file in offline simulations
- 3.12 Bug fixes in biofuel_mod.F and emfossil.F
- 3.13 Bug in wet deposition Henry's constant
- 3.14 Bug fix for anthropogenic scaling factors for years 2006 and later
- 3.15 Bug in ship CO emissions
- 3.16 Bug fixes in day-of-week computation
- 3.17 Bug fixes in diag48_mod.F
- 3.18 Bug in ND36 diagnostic when ship emissions are turned off
- 3.19 Additional minor bug fixes
- 3.20 Use reprocessed data files for CAC NH3 emissions
- 3.21 Convert MERRA and GEOS-FP relative humidity fields to percent after reading from disk
- 3.22 Bug fix for NEI2005 SO4 emissions in sulfate_mod.F
- 4 Outstanding issues not yet resolved in GEOS-Chem v9-02
Overview
In this section we provide basic information about this version of GEOS-Chem.
History
The table below shows the previous, current, and successive versions of GEOS-Chem:
Previous version | This version | Next version |
---|---|---|
GEOS-Chem v9-01-03 | GEOS-Chem v9-02 | GEOS-Chem v10-01 |
PUBLIC RELEASE 14 Sep 2012 | PROVISIONAL RELEASE TBD | TBD |
View v9-01-03 benchmark history | View v9-02 benchmark history | View v10-01 benchmark history |
--Bob Y. 10:21, 16 January 2014 (EST)
Period of public comment
GEOS-Chem v9-02 is the first version of GEOS-Chem for which we will issue a PROVISIONAL RELEASE. We will release the GEOS-Chem source code, data directories, and run directories to the GEOS-Chem User Community. We will then ask the User Community to download and run GEOS-Chem for a period of public comment which will last for approximately one month. During this period of public comment, we encourage the GEOS-Chem User Community to keep us (the GEOS-Chem Support Team) informed of any:
- Last-minute bugs
- Technical issues with the GEOS-Chem code or data
- Typos or omissions in the wiki or web documentation
- Other issues (i.e. problems downloading or installing the code and/or required libraries)
At the end of the period of public comment, we will then issue a PUBLIC RELEASE once we are confident that all reported issues have been corrected.
--Bob Y. 10:21, 16 January 2014 (EST)
What's new in this version
GEOS-Chem v9-02 contains the following major updates and improvements. The order has been determined by the GEOS-Chem Steering Committee.
v9-02a, v9-02b, etc. denote 1-month benchmark simulations, which are designed to evaluate GEOS-Chem's performance at intermediate stages of development.
Alternating stripes of color (white & cyan) in the table below group together features that were evaluated in the same 1-month benchmark.
--Bob Y. 10:33, 16 January 2014 (EST)
Downloading and installing GEOS-Chem v9-02
For complete instructions on how to download and install GEOS-Chem v9-02, please visit the following links:
- GEOS-Chem Online User's Guide Ch. 2: Installation
- GEOS-Chem Online User's Guide Ch. 3: Compilation
- GEOS-Chem Online User's Guide Ch. 4: Data directories
- GEOS-Chem Online User's Guide Ch. 5: Run directories
--Bob Y. 10:11, 16 January 2014 (EST)
New data directories
The following new data directories have been added for GEOS-Chem v9-02. You will have to download the directories relevant to your simulation.
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.25x0.3125_CH # Met fields and emissions for nested CH simulation GEOS_0.25x0.3125_NA # Met fields and emissions for nested NA simulation GEOS_0.5x0.666_NA/CAC_201307 # Canadian NH3 emissions GEOS_0.5x0.666_NA/CH4_201305 # EDGAR v4.2 emissions for CH4 simulation GEOS_0.5x0.666_NA/RETRO_201103 # RETRO anthropogenic VOC emissions GEOS_0.5x0.666_NA/RCP_201206 # RCP future emission scenarios GEOS_0.5x0.666_NA/lightning_NOx_201311 # Lightning redistribution files GEOS_0.5x0.666_NA/mercury_201203 # Data files for the nested NA Hg simulation GEOS_0.5x0.666_EU/RETRO_201103 # RETRO anthropogenic VOC emissions GEOS_0.5x0.666_CH/RETRO_201103 # RETRO anthropogenic VOC emissions GEOS_2x2.5/CH4_201305 # EDGAR v4.2 emissions for CH4 simulation GEOS_2x2.5/GEOS_FP # GEOS-FP meteorology fields GEOS_2x2.5/POPs_201209 # BC & OC concentrations for POPs simulation GEOS_2x2.5/RCP_201206 # RCP future emission scenarios GEOS_2x2.5/lightning_NOx_201311 # Lightning redistribution files GEOS_2x2.5/mercury_201203 # NEI2005 and NPRI2005 emissions for Hg simulation GEOS_4x5/CH4_201305 # EDGAR v4.2 emissions for CH4 simulation GEOS_4x5/GEOS_FP # GEOS-FP meteorology fields GEOS_4x5/POPs_201209 # BC & OC concentrations for POPs simulation GEOS_4x5/RCP_201206 # RCP future emission scenarios GEOS_4x5/lightning_NOx_201311 # Lightning redistribution files GEOS_4x5/mercury_201203 # NEI2005 and NPRI2005 emissions for Hg simulation GEOS_NATIVE/AEIC_201301 # AEIC aircraft emissions GEOS_NATIVE/CAC_201307 # Canadian NH3 emissions GEOS_NATIVE/GFED3_201212 # GFED3 emissions, now including 2011 GEOS_NATIVE/POPs_201209 # BaP, PHE, and PYR emissions for POPs simulation GEOS_NATIVE/mercury_201205 # Streets future anthropogenic Hg emissions GEOS_NATIVE/soil_NOx_201208 # Files for updated soil NOx emission scheme
--Bob Y. 10:11, 16 January 2014 (EST)
Using the GEOS-Chem Unit Tester
We now have a new tool that you can use to help debug your GEOS-Chem simulations! The GEOS-Chem Unit Tester can now run short test simulations designed to reveal several common programming and/or numerical issues, including:
- Parallelization errors
- Array-out-of-bounds errors
- Division-by-zero errors
- Invalid computations (i.e. SQRT(-1), LOG(0), etc.)
- Inefficient subroutine calls.
For more information about how the GEOS-Chem Unit Tester can assist you, please see our Debugging with the GEOS-Chem Unit Tester wiki page.
Starting with GEOS-Chem v9-02, we now have a new tool that
Performance
In this section we provide information about the GEOS-Chem's scalability. This is best illustrated as a plot of GEOS-Chem run times as you increase the number of CPUs on your system.
Scalability of the standard 1-month benchmark simulation
Mat Evans wrote:
- I've run lots of the benchmark version (4x5 geos5 1 month) with different numbers of cores for GEOS-Chem v9-01-03 and v9-02. I've run this all on a 2CPU Xeon X5670 @ 2.93GHz which has 6 cores per chip. 12 cores per system and up 24 threads through the hyper threading.
Bob Yantosca wrote:
- I think a couple of things were responsible for the speedup:
- We removed a lot of array temporaries from the code. In particular, this was happening in the TPCORE routines—the code had to make duplicate copies several IIPAR x JJPAR x LLPAR arrays for each subroutine call. And this was done in a loop over N = 1, 66 tracers, so you can imagine the bottleneck that was being created.
- We just re-activated the parallel DO loop in the LINOZ module. Some time ago this was reported as problematic. But I tested it again recently and found that it worked OK. This will increase the scalability for runs where we call chemistry several times an hour (i.e. 2x25, nested grids), since the fraction of code that is parallelized is greater than before.
- In our recent GEOS-Chem v9-02r 1-month benchmark (GEOS-5, 4x5) benchmark run, we got about 730% speedup on 8 CPUs (800% is theoretical max). That’s pretty good. The I/O is still all on single processor so you really can’t do better there.
- Also … I am not sure how well OpenMP parallelization performs with hyperthreading (where 1 CPU acts as if it were 2 CPUs). That may explain the falloff that you see when you go past 12 CPUs. On 12 or less CPUs, you are using the actual # of CPUs/node. But when you go past 12 CPUs, and into hyperthreading, you probably incur some additional system overhead, and that could be causing the turnover in the graph.
--Bob Y. 10:51, 19 November 2013 (EST)
Scalability of GEOS-Chem with GEOS-FP meteorology
It should be noted that GEOS-Chem simulations using GEOS-FP meteorology scale slightly lower than equivalent simulations using GEOS-5 meteorology. This can be illustrated by looking at the timing results from these two 1-month benchmarks:
Benchmark | # of CPUs | Run time | Scalability |
---|---|---|---|
v9-02r 1-month benchmark w/ GEOS-5 met | 8 | 2h 38min | 7.2794 |
v9-02r 1-month benchmark w/ GEOS-FP met | 8 | 2h 47min | 6.9529 |
A "perfect" simulation using 8 CPUs would theoretically have a scalability of 8.0000. In practice, we never attain the ideal scalability due to the following factors:
- As you use more CPUs in a simulation, each CPU has to communicate with the others more frequently). This incurs additional system overhead.
- Some sections of GEOS-Chem have not been parallelized. This is particularly true of the sections of code which handle file I/O.
As you can see from the above table, GEOS-Chem simulations using GEOS-FP met scale slightly worse than when using GEOS-5 met. We believe that this can be explained by:
- GEOS-FP requires more frequent reading of data from disk than GEOS-5.
- GEOS-5 meteorology needs to be read at intervals of 3 hours (surface fields) and 6 hours (3-D fields).
- GEOS-FP meteorology needs to be read at intervals of 1 hour (surface fields) and 3 hours (3-D fields).
- GEOS-FP uses a different file format than GEOS-5.
- GEOS-5 meteorology is archived as flat binary files, which are very quick to read in.
- GEOS-FP meteorology is saved in netCDF files. Reading netCDF files requires a call to the netCDF library routines, which incurs additional overhead.
--Bob Y. 11:31, 16 January 2014 (EST)
Previous issues now resolved in GEOS-Chem v9-02
This section contains a list of improvements and bug fixes that have been included in GEOS-Chem v9-02. For a complete list of bug fixes in GEOS-Chem, please see our Bugs and fixes wiki page.
Correction for GEOS-5 PBL heights
This update was tested in the 1-month benchmark simulation v9-02a and approved on 16 Oct 2012.
Please see this post on our Boundary layer mixing wiki page for a full description of this issue.
--Bob Y. 11:01, 5 October 2012 (EDT)
Bug fixes for tagged CO simulation
This update was tested in the 1-month benchmark simulation v9-02b and approved on 29 Oct 2012.
Please see this post on our Tagged CO simulation wiki page for more a complete description of the issue.
--Bob Y. 10:59, 20 December 2012 (EST)
Bug fix in nei2005_anthro_mod.F
This update was tested in the 1-month benchmark simulation v9-02b and approved on 29 Oct 2012.
We corrected incorrect subroutine calls to the regridding subroutine DO_REGRID_A2A from routines GET_NEI99_SEASON_05x0666 and GET_VISTAS_SEASON_05x0666 of GeosCore/nei2005_anthro_mod.F. Please see this wiki post on our EPA/NEI05 North American emissions wiki page for further information.
--Bob Y. 11:13, 20 December 2012 (EST)
Bug fix for updated CAC emissions
This update was tested in the 1-month benchmark simulation v9-02c and approved on 29 Nov 2012.
Aaron van Donkelaar wrote:
- The code as implemented in v9-01-03 contains only few of the changes I submitted to update CAC to 2008. My guess is that somehow two versions of this file were being worked on simultaneously.
- As a result of the mix-up, simulations using CAC emissions and running 2006 or 2007 will crash. Other than that it shouldn't have had any major ramifications.
--Melissa Payer 15:51, 27 November 2012 (EST)
Bug fix for Br2 emissions
This update was tested in the 1-month benchmark simulation v9-02d and approved on 19 Dec 2012.
Please see this wiki post on our Bromine Chemistry Mechanism wiki page for a full description of this issue.
--Bob Y. 15:38, 20 December 2012 (EST)
Bug in regridding of anthropogenic emissions
NOTE: This issue was tested in the 1-month benchmark simulation in v9-02e, which was approved on 09 Jan 2013.
We corrected an issue in the regridding of the anthropogenic Streets and NEI2005 emissions. Please see the discussion on our Regridding in GEOS-Chem wiki page for more information.
--Bob Y. 10:21, 10 January 2013 (EST)
Bug in MEGAN emissions when running with MERRA or GEOS-FP
NOTE: This issue was tested in the 1-month benchmark simulation in v9-02e, which was approved on 09 Jan 2013.
Please see the discussion on our MEGAN biogenic emissions wiki page for a complete description of this issue.
--Bob Y. 10:34, 10 January 2013 (EST)
Additional bug fixes for MAP_A2A regridding algorithm
NOTE: This issue was tested in the 1-month benchmark simulation v9-02e, which was approved on 09 Jan 2013.
Please see the discussion on our Regridding in GEOS-Chem wiki page for a complete description of this issue.
--Bob Y. 10:25, 10 January 2013 (EST)
Prevent bad drydep flux values from being passed to the soil NOx emissions module
This issue was tested in the 1-year benchmark simulation v9-02f and approved on 20 Mar 2013.
It was discovered that junk values in the drydep fluxes were being passed to the soil NOx emissions module (via routine SOIL_DRYDEP) when the ND44 dry deposition diagnostic was switched off. We have now corrected this issue. Please see this post on our Soil NOx emissions wiki page for more information.
--Bob Y. 09:29, 14 March 2013 (EDT)
Bug fix for declaration of GEOS-FP PFICU, PFLCU, PFILSAN, PFLLSAN fields
This update was tested in the 1-month benchmark simulation v9-02g and approved on 24 Mar 2013.
Please see this wiki post on our GEOS-FP implementation details wiki page for a full description of this issue.
--Bob Y. 11:42, 18 March 2013 (EDT)
Bug fix for reading OH file in offline simulations
This update was tested in the 1-month benchmark simulation v9-02g and approved on 14 Mar 2013.
When running the nested grid simulation over North America, a segmentation fault would occur in routine GET_GLOBAL_OH. GEOS-Chem was previously reading the global 0.5x0.666 data file, which lead to an array-out-of-bounds error. To make sure that the proper file is read, the following lines have been added to routine GET_GLOBAL_OH in GeosCore/global_oh_mod.F:
#if defined( NESTED_NA ) ! Filename FILENAME = TRIM( OH_DIR ) // 'OH_3Dglobal.' // GET_NAME_EXT() // & '.' // GET_RES_EXT() // '_NA' #else ! Filename FILENAME = TRIM( OH_DIR ) // 'OH_3Dglobal.' // GET_NAME_EXT() // & '.' // GET_RES_EXT() #endif
--Melissa Sulprizio 14:40, 6 September 2013 (EDT)
Bug fixes in biofuel_mod.F and emfossil.F
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
This update is included in Adjoint v34j.
Christoph Keller wrote:
- I found two bugs in the emissions code which I think we should fix.
- Firstly, the diurnal NOx scale factors should be based on local time instead of Greenwich Mean Time (aka Universal Time). The fix is easy, we just have to use the local time for a given grid box instead of taking the UTC hour when calculating the emissions in emfossil.F
- Secondly, I think that we currently double count biofuel emissions over Canada and Mexico if the respective local inventories (CAC and BRAVO) are used. Again, this is an easy fix, we just have to set the biofuel emissions for the given tracers and regions to zero if CAC and/or BRAVO are used.
Christoph Keller wrote:
- After having had a second look at the EMEP data I'm pretty sure that they contain biofuel emissions too. So I will have to update biofuel_mod.f accordingly, then it should be ready to merge.
--Melissa Payer 18:21, 20 June 2013 (EDT)
Bug in wet deposition Henry's constant
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
Fabien Paulot found a small bug in Henry's constant used in the wet deposition routine. Please see this post on our Wet deposition wiki page for a full description of this issue.
--Melissa Payer 17:58, 15 May 2013 (EDT)
Bug fix for anthropogenic scaling factors for years 2006 and later
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
Please see this post on our Scale factors for anthropogenic emissions wiki page for a full description of this issue. We plan to include this fix in GEOS-Chem v9-02n. --Melissa Payer 12:25, 22 March 2013 (EDT)
Bug in ship CO emissions
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
Please see this post on our Ship Emissions wiki page for a full description of the issue. We plan to include this fix in GEOS-Chem v9-02m.
--Bob Y. 15:47, 8 April 2013 (EDT)
Bug fixes in day-of-week computation
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
We corrected a couple of issues regarding how the day of the week is computed in GEOS-Chem. We made this fix primarily to ensure EPA/NEI weekday or weekend emissions were being selected properly. The EPA/NEI emissions are defined over the United States, where the local solar time can be 5-8 hours behind Greenwich Mean Time. Therefore, when deciding if EPA/NEI weekday or weekend emissions should be applied, we should use the day of the week w/r/t the local time at each grid box location over the United States. But in all GEOS-Chem versions prior to v9-02, the day of the week was always computed w/r/t Greenwich Mean Time.
In order to correct this discrepancy, we made the following modifications in GEOS-Chem v9-02l:
- (1) We have now moved the location of where the day of the week (w/r/t the GMT date) is computed:
- Subroutine SET_CURRENT_TIME (in GeosUtil/time_mod.F) computes the day of the week and stores it in module variable DAY_OF_WEEK.
- Function GET_DAY_OF_WEEK (also in GeosUtil/time_mod.F) now just returns the value of module variable DAY_OF_WEEK to the calling program.
- (2) We fixed a couple of numerical issues in the computation of the day of the week (w/r/t the GMT date), namely:
- (a) In subroutine SET_CURRENT_TIME (in module GeosUtil/time_mod.F), we need to round off the B term to 4 decimal places in order to avoid roundoff errors. We added this line:
! NOTE: This is not in the Duffett-Smith book, but when using ! REAL*8, we have to round B to 4 decimal places in order ! to avoid floating-point errors. (bmy, 6/13/13) B = INT( NINT( B*1d5 + SIGN( 5d0, B ) ) / 10d0 ) / 1d4
- (b) Also in SET_CURRENT_TIME, we changed the line:
DAY_NUM = INT( B + 0.5d0 )
- to
DAY_NUM = INT( B )
- The extra 0.5 was causing the day of week to increment 12 hours ahead of time. (The 0.5 is present in the algorithm upon which the function is based. But since this algorithm was developed for hand-held calculators, it may not take into account the roundoff that may exist in floating point numerical computations.)
- (3) Note that as written, subroutine SET_CURRENT_TIME returns the day of the week with respect to the Greenwich Mean Time (GMT). But when deciding to apply either weekday or weekend emissions at a particular location on the globe, we really want to get the day of the week with respect to the local solar time at that location. The local solar time may differ from GMT by several hours depending on distance from the prime meridian. Therefore, we have introduced a new function named GET_DAY_OF_WEEK_LT, which computes the day of the week with respect to the local time at a given location. Emissions routines that need to know the day of the week shall now use GET_DAY_OF_WEEK_LT instead of GET_DAY_OF_WEEK.
- (a) In the following emissions modules:
- GeosCore/biofuel_mod.F
- GeosCore/emfossil.F
- GeosCore/epa_nei_mod.F
- GeosCore/nei2005_anthro_mod.F
- GeosCore/sulfate_mod.F
- GeosCore/vistas_anthro_mod.F
- we have added code to call the new function GET_DAY_OF_WEEK_LT, in order to obtain the day of the week w/r/t the local solar time at GEOS-Chem grid box (I,J,L). The typical pattern that we use is as follows:
REAL*8 :: DOW_LT LOGICAL :: WEEKDAY . . . DO J = 1, JJPAR DO I = 1, IIPAR ! Determine if we should use weekday or weekend NEI ! emissions at grid box (I,J,L). Since NEI is over ! the US, then weekend is Sat/Sun. DOW_LT = GET_DAY_OF_WEEK_LT( I, J, 1 ) WEEKDAY = ( DOW_LT > 0 .and. DOW_LT < 6 ) ! Call emissions routines (in this example, EPA/NEI99) AN = GET_EPA_ANTHRO( I, J, IDTSO2, WEEKDAY ) BF = GET_EPA_BIOFUEL( I, J, ITDSO2, WEEKDAY ) ... etc ... ENDDO ENDDO
- Important notes:
- Sunday is denoted when DOW_LT == 0, and Saturday is denoted when DOW_LT == 6. For the purposes of the EPA/NEI emissions (over the United States), a "weekend" is Saturday/Sunday. (NOTE: in some locations of the world, particularly in the Middle East, weekends are defined as Friday/Saturday.)
- We now need to call GET_DAY_OF_WEEK_LT from the same DO loop where the call to the emissions routines (in this example, for EPA/NEI99) are located. This is because GET_DAY_OF_WEEK_LT now needs to know the I, J, (and for multi-level data, L) indices of the grid box.
- If the DO loop is parallelized, then the variables DOW_LT and WEEKDAY need to be added to the !$OMP PRIVATE declaration.
--Bob Y. 14:27, 18 June 2013 (EDT)
Bug fixes in diag48_mod.F
This update was tested in the 1-month benchmark simulation v9-02l and approved on 26 Jun 2013.
Jenny Fisher wrote:
- A couple of bugs in diag48_mod.F:
- 1. GET_LOCALTIME is called with LT = GET_LOCALTIME( I, J, L )
- But L hasn't been defined. This should either be K or 1, but not L.
- 2.
DO L = 1, K Q(L) = GET_PEDGE( I, J, K ) ENDDO
- The K in GET_PEDGE should be L.
--Melissa Payer 14:36, 18 June 2013 (EDT)
Bug in ND36 diagnostic when ship emissions are turned off
This update was tested in the 1-month benchmark simulation v9-02o and approved on 03 Sep 2013.
For a full description of this issue, please see this post on our Ship emissions wiki page.
--Melissa Sulprizio 11:36, 22 August 2013 (EDT)
Additional minor bug fixes
These updates were tested in the 1-month benchmark simulation v9-02r and approved on 14 Nov 2013.
These issues were mainly identified with the GEOS-Chem Unit Tester while validating GEOS_Chem v9-02r.
- Do not call PARANOX when running offline simulations
- Make sure BC and OC biofuel emissions are zeroed out when using the RCP emission scenarios (submitted by Colette Heald)
- Fixed parallelization error in routine METERO (in dry deposition module)
- Fixed parallelization error in routine DRYFLX (in dry deposition module)
- Eliminate array temporaries in GEOS-4 convection module
- Prevent LOG(0) error from occurring in soil NOx module
- Eliminate array temporaries in GCAP convection module
- Eliminate array temporaries in pjc_pfix_mod.F and pressure_mod.F
- Avoid error in ISOROPIAII when using offline aerosol simulation
- Modifications for v9-02 tagged O3 simulation
- Reactivate parallel DO loop in LINOZ_CHEMO3 routine
- Reset NaNs in MOISTQ to zero
- Bug fix for RCP ship NOx emissions
--Bob Y. 15:01, 7 November 2013 (EST)
Use reprocessed data files for CAC NH3 emissions
This update was tested in the 1-month benchmark simulation v9-02r and approved on 14 Nov 2013.
The 1-year benchmark for v9-02l revealed that Canadian NH3 emissions were not varying with season as expected. Wai Ho Lo has reprocessed the data files for the CAC NH3 emissions. These new emission files are slated for inclusion in v9-02r. For more information please see this post on our Anthropogenic emissions wiki page.
--Bob Y. 16:36, 31 October 2013 (EDT)
Convert MERRA and GEOS-FP relative humidity fields to percent after reading from disk
This update was tested in 1-month benchmark simulation v9-02r with GEOS-FP met and approved on 14 Jan 2014.
Aaron van Donkelaar wrote:
- I've noticed some oddities in the surface-layer relative humidity of a MERRA-driven simulation, as output from diag51. The attached plot shows the RH output in the lowest two layers of a GEOS-5- and MERRA-driven simulation for Aug 27, 2005 using v9-01-03.
- A couple things jump out. First, MERRA RH goes from 0-1, rather than 0-100, and second, the lowest layer (shown in the bottom left) is really noisy.
- The simulation was run by another user, whom is checking into it as well. I was, however, wondering if this was something you had already come across and could maybe shed some light on.
Bob Yantosca replied:
- It appears we read in GEOS-5 RH as unitless then convert to %. It seems be that we do not do this unit conversion for MERRA (or for GEOS-FP).
Older met products (e.g. GEOS-1, GEOS-STRAT, GEOS-4) carried RH with units of %. The newer GMAO met products all carry RH as unitless. Therefore, for backwards compatibility with existing GEOS-Chem code, we have to convert RH to % immediately after reading it in from disk. This unit conversion is done when running GEOS-Chem with GEOS-5 met. But as you can see from the above plot, this unit conversion currently does not happen when running GEOS-Chem with either MERRA or GEOS-FP met.
This issue can be resolved by adding a couple extra lines of code:
1. In GeosCore/merra_i3_mod.F, we modify the CASE statement for RH to add the unit conversion:
!------------------------------------ ! RH: Relative humidity [1] ! and converted to [%] !------------------------------------ CASE ( 'RH' ) READ( IU_I6, IOSTAT=IOS ) XYMD, XHMS, Q3 IF ( IOS /= 0 ) CALL IOERROR( IOS, IU_I6, 'read_i6:3' ) IF ( XYMD == NYMD .and. XHMS == NHMS ) THEN CALL TRANSFER_3D( Q3, RH ) NFOUND = NFOUND + 1 ! Convert RH from [1] to [%] RH = RH * 100d0 ENDIF
2. In GeosCore/geosfp_read_mod.F90, we add the same unit conversion in the last section of the routine (just before exiting):
!====================================================================== ! Unit conversions, diagnostics, cleanup, and quit !====================================================================== ! Convert RH from [1] to [%] State_Met%RH = State_Met%RH * 100d0 ! CLDTOPS = highest location of CMFMC in the column (I,J) DO J = 1, JJPAR DO I = 1, IIPAR ... etc ...
3. For consistency, we have also updated the comments in Headers/gigc_state_met_mod.F90 to reflect the proper units:
REAL*8, POINTER :: RH (:,:,:) ! Relative humidity [%] REAL*8, POINTER :: RH1 (:,:,:) ! RH at timestep start [%] REAL*8, POINTER :: RH2 (:,:,:) ! RH at timestep end [%]
These fixes correct the issue. The diagnostics now report RH in %, as seen by the following plot.
These updates have since been added to GEOS-Chem v9-02.
--Bob Y. 10:44, 16 January 2014 (EST)
Bug fix for NEI2005 SO4 emissions in sulfate_mod.F
This update was included as a last-minute fix in GEOS-Chem v9-02 and approved on 14 Jan 2014.
Please see this post on our EPA/NEI05 North American emissions wiki page for more a complete description of the issue.
--Bob Y. 10:45, 16 January 2014 (EST)
Outstanding issues not yet resolved in GEOS-Chem v9-02
The following issues have not yet been resolved in GEOS-Chem v9-02. For a complete list of unresolved issues by GEOS-Chem version, please see our Currently unresolved issues in GEOS-Chem wiki page.
Regional biofuel emissions may be neglected when using RETRO or RCP emissions
For a complete description of this issue, please see this post on our Biofuel emissions wiki page.
--Bob Y. 11:42, 16 January 2014 (EST)
Isoprene emissions are lower when using GEOS-FP meteorology
It has been noted that the GEOS-FP 1-year benchmark runs produce much less isoprene than the GEOS-5 1-year benchmark run. This is not a necessarily a problem with the model, but is a matter of active research.
Dylan Millet wrote:
- Indeed isoprene emissions are now quite low, dropping to 395 TgC/y with GEOS-FP and further to 361 TgC/y once we also use the Olson 2001 land map. 361 TgC is 409 Tg isoprene, this puts us at the low end of other estimates using MEGAN2.1 which are mostly 500-600 Tg/y. (But not totally outside the range)
- Overall CO seems to have decreased overall, but the change appears not as dramatic as previously when the anthro emissions were also different.
- My feeling is we shouldn't scale isoprene emissions for their own sake, since as far as I know it's an open science question as to whether 500-600 Tg/y is a better global estimate than 400. But, if a consensus emerges among the SC that the low isoprene causes too much of a step-change in other species like CO and PAN, then that would be grounds for scaling.
- I will forward this discussion on to other folks who have been involved in MEGAN development in GC and see what their thoughts are.
Daniel Jacob replied:
- It seems to me that the GEOS-FP run is OK. There are large differences with GEOS-5 but nothing that seems to obviously compromise the quality of the model and the rest is a matter of research. Dylan M thinks that we should live with the lower isoprene at least for the time being. I suggest that we approve this version and go on to [the next version].
--Bob Y. 10:56, 16 January 2014 (EST)
Soil NOx emissions are lower when using GEOS-FP meteorology
The lower surface temperatures in GEOS-FP (as described in the preceding section also cause soil NOx emissions to be lower compared to GEOS-5. Again, this does not necessarily indicate a problem with GEOS-Chem, but is also a matter of active research.
Prasad Kasibhatla wrote:
- Is there an obvious exp;anation for why the NO soil and fertilizer sources have decreased by about 20% in 1-year benchmark v9-02-geosfp-Run0 relative to v9-02-geos5-Run0? Is it because of surface temperature?
Daniel Jacob replied:
- Thanks Prasad. 20% decrease in NOx soil source is very consistent with the cooler temperatures in GEOS-FP driving the isoprene decrease. I don't think that needs to be investigated further.
--Bob Y. 11:06, 16 January 2014 (EST)