GMAO GEOS-4

The GEOS-4 operational product ceased and is now obsolete. We recommend that you use either GEOS-FP, which is the current operational GMAO met data product, or MERRA-2, which is the current GMAO reanalysis product.

Support for GEOS-4 meteorology was removed from v11-02d and later versions.

Overview

GEOS-4 was the first hybrid sigma-pressure met field product produced by NASA's Global Assimilation and Modeling Office (GMAO). We have processed approximately 20 years (1985-2006, partial 2007) of GEOS-4 data for input into GEOS-Chem.

Resolution

Native horizontal grid:

• 1° lat x 1.25° lon

Regridded horizontal grids:

• 2° lon x 2.5° lat
• 4° lon x 5° lat

Vertical grids:

• 55 hybrid sigma-pressure levels
• 30 hybrid sigma-pressure levels (reduced grid: levels lumped above 176 hPa)

In practice, the regridded 2° x 2.5° and 4° x 5° grids are used for global simulations. However, starting in GEOS-Chem v8-03-01, Lok Lamsal (formerly from Dalhousie University) has added the capability to run a GEOS-Chem global simulation at 1° x 1.25° resolution.

Additional documentation

• Availability of GEOS-4 data
• List of GEOS-4 met fields used by GEOS-Chem
• Overview of GMAO met data products

--Melissa Sulprizio 13:53, 15 April 2015 (EDT)

Validation

Here are some documents from members of the Harvard Atmospheric Chemistry Modeling Group which contain plots of various GEOS-4 met fields.

1. GEOS-4 vs. GEOS-3 problems (Jennifer Logan)
2. Changes in CO and O3 in 1-year benchmarks (Rynda Hudman)
3. GEOS-4 optical depths (Bob Yantosca)
4. Winds in GEOS-4, Part 1 (Bob Yantosca)
5. Winds in GEOS-4, Part 2 (Bob Yantosca)
6. Overview of the GEOS-4 met fields (Bob Yantosca)
7. Rn, Pb, Be concentrations in GEOS-4 and GMI models (Hongyu Liu)

NOTE: There is a known inconsistency in the GEOS-4 met in the optical depth fields. Places which have high cloud fraction in the 5-10 km range do not always have the corresponding optical depths that would be expected. This affects the FAST-J photolysis scheme and as a result, the mean OH concentration is higher than what we saw in either GEOS-3 or GEOS-5.

--Bob Y. 10:54, 17 February 2010 (EST)

References

1. GEOS-4 file specification document, 24 Feb 2004.
2. Bloom, S., A. da Silva, D. Dee, M. Bosilovich, J.-D. Chern, S. Pawson, S. Schubert, M. Sienkiewicz, I. Stajner, W.-W. Tan, M.-L. Wu, 2005. Documentation and Validation of the Goddard Earth Observing System (GEOS) Data Assimilation System - Version 4, Technical Report Series on Global Modeling and Data Assimilation 104606, 26. PDF

Known issues

Spatially shifted values in the GEOS-4 MOISTQ field

Please see this presentation which shows how the MOISTQ field is shifted spatially for some months in 1998.

--Bob Y. 12:16, 19 August 2013 (EDT)

Bad GEOS-4 A6 met data causing segmentation fault

Jesse Kenyon wrote:

In our runs of the GEOS-Chem model using GEOS4 data from 2006, we have run into a corrupt data problem that causes our runs to crash on rundate 20060913. We have been able to isolate this to bad values in the A6 files for the meridional wind (V component). Specifically, it appears two files contain bad data: 20060913.a6.4x5 and 20060915.a6.4x5. The bad data takes the form of unphysically huge values (e.g. 0.75553E+29), and occurs at many gridboxes on levels 6 and 7 of the 20060913 file and levels 18 and 19 of the 20060915 file. In both files, the bad data only occur for the 00 hour (06, 12, and 18 hours appear okay). We also checked the 20060914, 20060916, 20060917, 20060918, and 20060919.a6.4x5 files - they seem okay. A check of the U component wind on 09-13 and 09-15 shows no problems.

For us, the problem manifested itself as a segmentation fault when trying to access address -21474836 of array qtmp in subroutine xtp in module tpcore_fdvas_mod.f90. The address was calculated from xmass which is calculated from wind and pressure in another subroutine (Init_press_fix). We know some folks at Harvard have been able to get beyond this rundate without crashing and suspect it might be due to a difference in computer system or compiler.

We have not yet tried running with a "repaired" V wind, so cannot say for sure that there are no other problems in the A6 files besides V (or U which was also checked).

Philippe Le Sager wrote:

Thanks for reporting the issue. We had the exact same problem with GCAP once and the problem was solved by repairing the met field (a very bad value in U or V). Then Mike and Bastien got the exact same error with GEOS4, on the same day as you. My first idea was to test the met fields but I did not get any bad value. I just did a run with Bastien's inputs, and was not able to reproduce the crash. You just confirmed that the first idea was the good one: a bad met field.

Since I seem to have a good met field and you do not, I check the met fields on the server this time. And I did find a problem with V for 20060913. Here are the output from test_met.pro (it gives min and max of each met fields):

   at Harvard (internal disk):
   20060913 000000 U             -72.816071     144.557083
   20060913 000000 V             -67.133759      61.291386

   on the server:
   20060913 000000 U             -72.816071     144.557083
   20060913 000000 V             -67.133759***************

All others fields give the exact same min/max. There is a huge or NaN value in the file we put on the server. We do not understand how that happened, since files are simply copied from one location to the other. So we are still investigating the issue, checking the whole archive, and will let you know as soon as we replace it.

Bob Yantosca wrote:

I have fixed the bad A-6 data for 2006 -- 09/13, 09/14, 09/15, 09/16. For some reason the data in the FTP site was corrupt (bad values in the winds at a couple of GMT times) but the data on our internal disk (behind the firewall) was not. I just copied the relevant data files over and re-created the TAR file.

Please obtain the new TAR file from:

  ftp ftp.as.harvard.edu
  cd pub/geos-chem/data/GEOS_4x5.d/GEOS_4_v4/2006/09
  get 09.tar.gz

--Bob Y. 15:40, 23 September 2008 (EDT)