Difference between revisions of "GEOS-5 issues"

From Geos-chem
Jump to: navigation, search
Line 410: Line 410:
This addition to the wiki is intended to foster discussion and communication about PBL heights in GEOS met fields.  Large differences in the diurnal variation in the GEOS-4 and GEOS-5 PBL heights are affecting GEOS-Chem simulations.   
This addition to the wiki is intended to foster discussion and communication about PBL heights in GEOS met fields.  Large differences in the diurnal variation in the GEOS-4 and GEOS-5 PBL heights are affecting the GEOS-Chem simulations.   
Line 418: Line 418:
The figure above shows the diurnal variation of PM2.5 concentrations over 588 sites across the continental US (for 2005 June, GEOS-Chem simulation (v8-03-01) by Aaron van Donkelaar) while using GEOS-5 (blue) and GEOS-4 (green) met fields.  We suspect that the large build up of aerosols overnight in GEOS-5 run is related to low PBLH overnight.
The figure above shows the mean diurnal variation of PM2.5 concentrations over 588 sites (red line)across the continental US (for 2005 June, GEOS-Chem simulation (v8-03-01) by Aaron van Donkelaar) while using GEOS-5 (blue) and GEOS-4 (green) met fields.  We suspect that the large build up of aerosols overnight in GEOS-5 run is related to low PBLH overnight.
Sajeev Philip (April 14, 2011)
Sajeev Philip (April 14, 2011)

Revision as of 19:10, 14 April 2011

On this page we list some of the problems (and fixes!) that we have encountered during the implementaton of the GMAO GEOS-5 met fields into GEOS-Chem.

For more information about GEOS-5, please be sure to visit the following resources:

GEOS-5 update and clarification

Dear GEOS-Chem users:

There has been some confusion about the quality of the GEOS-5 meteorological fields used by GEOS-Chem from 1/2007 onwards. This message is to clarify the situation.

  1. GEOS-5 has gone through successive iterations at GMAO since early 2007. There was version 0.1, then 1.0, then 2.0. Steven Pawson at GMAO assures me that version 2.0 will remain stable as the operational version. We are presently downloading 2.0, but the 1/2008-8/2008 period still uses the 1.0 version and the 1/2005-12/2007 period still uses the 0.1 version. We are told that there are some significant differences between versions in convective mass fluxes. We will be reprocessing 2.0 data for earlier periods as it becomes available, but in the meantime there is no reason to view the earlier versions as bad. NOTE: as of July 2009, we have completed reprocessing the GEOS-5 met data from from 2004-present.
  2. We discovered an error in the documentation of the cloud OD output from GEOS-5. The documentation lists it as grid-average OD, but it is in fact the in-cloud OD. To obtain the grid-average OD you need to multiply by cloud fraction (also archived). This led to some discussion involving Hongyu Liu, Moeko Yoshitomi, Michael Prather, and Steven Pawson about how best to average ODs when regridding. Hongyu Liu recommended a scheme based on conservation of cloud albedo that received general approval, but implementing it will require reprocessing of the GEOS-5 data stream. In the meantime you can just multiply cloud OD by cloud fraction and you won't be too far off. NOTE: The reprocessing of the GEOS-5 met data has now resolved the optical depth issue described above.
  3. We are presently working through the problem of excessive x-tropopause transport and polar stratospheric transport in GEOS-Chem. We've known about this problem for a long time (it predates GEOS-5). What's interesting is that GMI seems to be doing this transport better, using the same GEOS fields. It may have to do with different regridding schemes or different versions of TPCORE. We are actively investigating this problem and will keep you posted. But as far as we know it doesn't affect tropospheric transport so as long as your focus is on the troposphere you're OK. NOTE: This has been fixed by replacing the TPCORE advection code with the version from the GMI model, which was done in GEOS-Chem v8-01-03.

Daniel Jacob
Bob Yantosca

--Bob Y. 10:28, 13 July 2009 (EDT)

Quick fix for optical depth

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


#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)

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.

NOTE: This fix is obsolete. As of July 2009, we have completed reprocessing the entire GEOS-5 met data period from 2004-present. The reprocessed GEOS-5 data now eliminates the need for this quick fix.

--Bob Y. 10:30, 13 July 2009 (EDT)

Error in GEOS-5 Cloud Optical Depths


Due to an oversight, the descriptions of the GEOS-5 met fields TAUCLI (ice-path optical depth) and TAUCLW (water-path optical depth) were incorrectly reported in the GEOS-5 file specification document. These fields were listed as grid-box optical depths but were actually in-cloud optical depths.

Steven Pawson wrote:

I have now spoken to colleagues and have "definitive" information that the cloud optical depths (TAUCLW and TAUCLI) are for in-cloud optical depths only. They are not grid-box averages and to convert to grid-box averages you need to use the 3D cloud fraction, CLOUD.
This is a change from GEOS-4 (and 3) that is not documented in the GEOS-5.0.1 or 5.1.0 data description documents.
This change must have been introduced after the GEOS-CHEM meeting when we showed some cloud optical depths from GEOS-5, for liquid and ice clouds.

While processing and regridding the "raw" GEOS-5 met field data into the GEOS-Chem binary format, the TAUCLI and TAUCLW fields were summed to create the overall visible optical depth:


where I,J,L are the lon, lat, and altitude indices that specify each grid box.

The OPTDEPTH variable was created on the GEOS-5 native 0.5° x 0.667° degree grid, and then regridded to 2° x 2.5° and 4° x 5° resolution.

NOTE: It is necessary to compute the sum of TAUCLI and TAUCLW on the GEOS-5 native grid before regridding to coarser resolution in order to obtain the proper result. If you regrid TAUCLI and TAUCLW to coarse resolution before summing them, the resultant sum can be 20-50% lower than if you sum first and then regrid.

However, because the TAUCLI and TAUCLW fields are actually in-cloud optical depths rather than grid-box optical depths, they should have been multiplied by the 3-D cloud fraction field CLOUD. Therefore, the correct way of creating the visible optical depth should have been:


and then the overall visible optical depth OPTDEPTH can be regridded from 0.5° x 0.667° resolution to coarser resolution.

We regret this error. We plan on reprocessing the GEOS-5 met fields and also upgrading the data version from the older GEOS-5.0.1 data to the GEOS-5.1.0 data. Stay tuned for future developments.

--Bob Y. 09:53, 15 September 2008 (EDT)


For the time being, you can implement the quick fix for optical depth (i.e. to multiply optical depth by cloud fraction) as described above. This fix will be made standard in GEOS-Chem v8-01-02.

Very soon, we will reprocess the entire data set of GEOS-5 met fields using the regridding algorithm provided to us by Hongyu Liu.

Bob Yantosca wrote:

I created a plot of the column sums at 0.5 x 0.666, 2 x 2.5, and 4x5 for day 2008/09/30 at 0GMT. See this GIF.
There are 9 panels on the plot
           column #1       column #2                    column #3
           vertical sums   vertical sums                vertical sums
           in-cloud OD     grid-box OD                  approximate random overlap OD
                           = in-cloud OD * cld frac     = in-cloud OD  * (cld frac ^1.5)
   row #1    0.5 x 0.6666    0.5 x 0.666                  0.5 x 0.666
   row #2    2 x 2.5         2 x 2.5                      2 x 2.5
   row #3    4 x 5           4 x 5                        4 x 5
Column #1 of the plot shows the vertical sums of the in-cloud OD's. These are what are returned by Hongyu's algorithm.
Column #2 of the plot shows the vertical sums of grid-box OD's (i.e. in-cloud OD * Cloud fraction). The grid-box OD's are what FAST-J will see if we use the "linear" approximation (OVERLAP=1 option) in the "fast_j.f" routine.
Column #3 of the plot shows the vertical sums of the approximate random overlap OD's (i.e. optical depth * (cld frac)^1.5). This is what FAST-J will see if we use the OVERLAP=2 option in the "fast_j.f" routine.
I think we have to look at the grid-box OD's (column #2) and not the in-cloud OD's (column #1). The in-cloud OD's may appear to be higher at coarser resolution. However, when converting to the grid-box OD, you multipy by the cloud fraction...and the because the grid box is bigger at coarser resolution, the overall cloud fraction probably tends to be smaller than at fine resolution. So this would tend to compensate in the grid-box OD's. Ditto for the approximate random overlap OD's in column #3.

Daniel Jacob replied:

Hi all - this looks good to me. I think we can close the case.

NOTE: As of July 2009, we have completed reprocessing the entire GEOS-5 met field data for the period of 2004-present. The reprocessed met data eliminates the need for the "quick fix" described above. The code for the "quick fix" will soon be removed from the standard GEOS-Chem distribution.

--Bob Y. 10:01, 4 February 2010 (EST)

Switchover from GEOS-5.1.0 to GEOS-5.2.0

We recently received this notification from GMAO about a minor upgrade to the GEOS-5 met field data product. Most of these involve "under-the-hood" changes and should not affect the ordering of the individual met fields into files, etc. We will keep you informed of upcoming developments.

Dear GEOS-5 data users,
GEOS-5 V1.0 has been in production for many months now. Several improvements have been made to the GEOS-5 system over the past few months and GMAO is planning to upgrade the forward processing operation with the latest GEOS-5 system. In addition to the GEOS-5 system upgrade, forward processing operations will be migrated to a different high performance computing (HPC) platform at the GSFC NCCS. This move is required because the NCCS will decommission the platforms that we have been using for the GEOS-5.1.0 operations at the end of September, 2008.
The upgraded system will be designated 'GEOS-5 V2.0'. (Following our past practice, we may use 'GEOS-5.2.0' as an alias.)
Here is a brief description of the science changes that impact the system:
Updates to the GCM:
  1. A bug in cloudnew.F90 related to the use of the wind shear pdf was corrected.
  2. Updates were made in cloudnew.F90 to allow a) thicker cold low-level cloud and b) lower limits on RH in re-evaporation.
  3. Lowered the upper limit on RADQL and RADQI to 1 g/kg from 40 g/kg.
  4. A bug in MOIST was fixed to pressure weight DTDTFRIC.
  5. TROPP_THERMAL, TROPP_EPV, and TROPP_BLENDED options were implemented for Tropopause Pressure.
  6. The bounds for the relative humidity ramp for mass flux in RAS were changed from [0.6,0.8] to [0.5,0.65].
  7. The temperature perturbation in convective boundary layers was capped at 2ºK over the ocean and 4ºK over the land.
  8. Corrections were made to ALBEDO and SLRSFC calculations in GEOS_SolarGridComp.F90 and sorad.F. The LANDICEALBEDO was changed to 0.775 (from 0.8).
  9. The historical CO2 record is used.
  10. A gravity wave drag heating correction based on energy conversion from waves (rather than mean flow) was implemented.
  11. Modifications were made to thermal capacity of ice to allow diurnal cycle of surface temperature over land and sea ice.
Updates to the Analysis:
  1. The satellite bias correction was turned off for AMSU-A channel 14 and SSU channel 3.
  2. CRTM coefficients for AMSU and MSU, all channels for NOAA-8 and SSU channels for NOAA-11 were updated.
  3. A bug was fixed in the quality control of microwave instruments.
There is also one change to the GEOS-5 file specification document. This change is to correct a documentation error in the unit specification for the RH. In the file spec document, RH in product tavg3d_dyn_v is defined as having units of 'percent'. In fact, RH in this product is provided as a fraction between 0 and 1.
What follows is a sequence of events and schedule for the system upgrade :
  1. The updated GEOS-5 file specification document will be posted on the GMAO web site by July 9th.
  2. To support your SW testing, a month of sample GEOS-5.2.0 data files will be made available on the GMAO ftp site on July 20th. We have GEOS-5.2.0 data from March 1, 2008 - present. We plan to provide you with data from May, 2008. If you prefer other months for your test, please let us know by July 10th. The GSFC DISC will make the subsetted data of the sample data files that some of you routinely receive and have them available to you soon after July 20th.
  3. The GMAO will begin a near real time test run of GEOS-5.2.0 on the new NCCS HPC platform called 'discover' with August 1, 0z data.
  4. The GSFC DISC will conduct a short data flow test with users on August 6th.
  5. GMAO will start sending the GEOS-5.2.0 data to the GSFC DISC for operational data distribution on August 12th beginning with August 11th, 0z data.
  6. We would like to stop data production of GEOS-5.1.0 at the end of August. We think this is feasible because the transition should be relatively transparent from your perspective. However we will work with you on the schedule. The latest date possible for stopping GEOS-5.1.0 would be September 29th after September 28th 18z data delivery.
Please let us know if you have any concerns or questions regarding this GEOS-5 system upgrade plan.
Best regards,
Gi-Kong (gkim@gmao.gsfc.nasa.gov)

--Bob Y. 14:03, 1 July 2008 (EDT)

Update: 23-July-2008

Hi all,
In support of some of you who need a longer overlap between GEOS-5 V1.0 and V2.0, GMAO plans to keep the GEOS-5.1.0 forward processing through the data date Oct 2nd, 2008, more than a month longer than originally scheduled. I'd like to express here our thanks to GSFC NCCS who made an arrangement to keep the HPC computers running a few more days beyond the lease expiration.
On another note, the GEOS-5.2.0 sample data delivery will be further delayed to Monday (7/28) next week. The impact of the OS upgrade lingered on longer than we anticipated. We apologize for any inconvenience to you caused by this delay.
Gi-Kong (gkim@gmao.gsfc.nasa.gov)

--Bob Y. 14:03, 23 July 2008 (EDT)

Update: 03-Sep-2008

GEOS-5.2.0 actually started on August 15, 2008. As of 9/3/08, GMAO is creating both GEOS-5.1.0 and and GEOS-5.2.0 data on parallel streams. GMAO will probably stop shipping GEOS-5.1.0 by the end of September, 2008.

For the GEOS-5 dataset that we have already processed for GEOS-Chem, the GMAO version numbers are as follows:

  • GEOS-5.0.1 (2005/01/01 - 2007/12/31)
    • NOTE: All GEOS-5.0.1 data is being replaced with GEOS-5.1.0 data
  • GEOS-5.1.0 (2008/01/01 - 2008/08/31)
  • GEOS-5.2.0 (2008/09/01 - onwards)

--Bob Y. 09:31, 24 April 2009 (EDT)

Small negative RH value in 20060206.a6.2x25 file

Those of you who have already downloaded GEOS-5 met data prior to 5/1/08 should be aware of this:

Philippe Le Sager (plesager@seas.harvard.edu) wrote:

Hi Dylan
some good news. I succeed[ed] in reproducing and solving two other [problems] from your GEOS-5 run. Nothing to do with IFort.... Here is the story:
A negative (although very small) Relative Humidity triggers several NaN in the aerosols routines. Since there is no check on tracers in those routines, the NaN are caught in the wetdep module. You can make quite a bit of operations with NaN.... It took me few days while rewriting part of the GEOS-Chem manual to find the root of the problem, but do I feel good now that I got it!
The fix is twofold. In a6_read_mod.f, RH is set to 0 if negative. Then, in drydep_mod.f, seasalt_mod.f, and sulfate_mod.f, if RH is used as argument for a LOG, I do
   RH=max( TINY(RH), RH )
... so we don't get a LOG(0)!
We do not know yet if the negative RH was already in the raw GEOS-5, or if it is an artifact of the regridding procedure. Bob has modified the latter to set all negative RH to 0, so the fix in a6_read_mod.f is meant to be temporary.
The other fixes are more general and will stay. I put the modified routines at:
Let us know how it goes, thanks

Bob Yantosca (yantosca@seas.harvard.edu) replied:

Hi Dylan,
I used IDL to replace the negative RH with zero in the file 20060206.a6.2x25. There was just one box with this small negative RH. Not sure if this is a problem in the original data or if this is just a regridding artifact. I've modified my regridding code so this doesn't happen again. Nevertheless, if you want, you may take the file:
   ftp ftp.as.harvard.edu
   cd pub/geos-chem/data/GEOS_2x2.5.d/GEOS_5/2006
   get 02.tar.gz
Bob Y.

NOTE: These patches, originally introduced in v8-01-01, have now been standardized in v8-01-02.

--Bob Y. 16:59, 1 May 2008 (EDT)

Floating point error in RPMARES

Please see the discussion on the Aerosol Thermodynamical Equilibrium wiki page to learn more about how we corrected a floating-point error in RPMARES that manifested itself under certain conditions when running GEOS-Chem with GEOS-5.

Lightning with GEOS-5

Please see the lightning NOx emissions wiki page for a description of the modifications that were made to the lightning NOx algorithm for GEOS-5.

Wrong unit tag for RH in GEOS-5 raw data files

The GEOS-5 raw met data files (both in versions 5.0.1 and 5.1.0) at 0.5 x 0.667 resolution have the wrong unit tag for the 3-D relative humidity field. The field is given as a fraction but the unit tag in the HDF file says percent.

The quick fix is to just multiply RH * 100 as soon as it is read from disk in a6_read_mod.f.

Bob Yantosca (yantosca@seas.harvard.edu) wrote:

Hi Rob,
I think I may have found a slight bug in one of the GEOS-5 fields. The Relative Humidity variable in the tavg3d_dyn_v files seems to have the wrong unit tag. The RH data is unitless but the data tag says percent.
I looked at the file:
and I was able to read it into IDL with HDF_BROWSER, which gives info about each data block:
   ** Structure <108eeeb8>, 15 tags, length=152, data length=136, refs=2:
      LABEL           STRING    'Relative humidity'
      NAME            STRING    'RH'
      TYPE            STRING    'FLOAT'
      UNIT            STRING    'percent'

But then if you print out the min and max of the data I got:
    Time      Time from           Date          Time
    Index     1993 (s)       (YYYYMMDD)      (HHMMSS)
       1   480124806.0        20080320        000000

    ### RH min, max:   0.0000000E+00   1.113281   
If it were % it would be 111.3281%. So there is a factor of 100 difference. Can you confirm this?
I believe that RH is unitless for both the 5.0.1 and the 5.1.0 data. I checked a couple of data files that I had created from both data sets:
     date    time  field    min        max  
   20050101 180000 RH     0.000001   1.052381  --> 2x25 file regridded from GEOS-5.0.1 data
   20080101 180000 RH     0.000000   1.055233  --> 2x25 file regridded from GEOS-5.1.0 data
Also, the last version of the GEOS-5 file spec that I have says RH is %.
For the time being I'll put a line of code into GEOS-Chem to multiply RH by 100 (our algorithm expects RH in %). That is the easiest fix.
Thanks much,
Bob Y.

Rob Lucchesi (rlucchesi@gmao.gsfc.nasa.gov) replied:

You are right. RH as written by the model is a fraction, not a percentage. We will have to modify the documentation and metadata in future products to reflect this. Note that the RH derived from the analysis (in the inst3d_met_p product) is a percentage. RH in the MERRA products is also fractional, but the documentation reflects that.
Thanks for the info.
Rob Lucchesi

--Bmy 10:00, 8 April 2008 (EDT)

NaN's found in GEOS-5 DQIDTMST field

Some of the values in the DQIDTMST (tendency of specific humidity due to moist processes) contained NaN values. All of them were located near the tropopause.

The quick fix was to reprocess the GEOS-5 met data the dates in question, and whenever a NaN value was encountered, to replace that with a zero.

Bob Yantosca (yantosca@seas.harvard.edu) wrote:

Hi all,
I was processing the GEOS-5 "tavg3d_mst_v" file:
and I noticed that the DQIDTMST field has a NaN value present
                                  x   y   z   time
  DQIDTMST is NaN at grid box:  356 333  28   1!
  x = lon index,
  y = lat index,
  z = level index (z=1 is the top of the atmosphere)
  t=time index (actually there is only one time in this file).
I just wanted to bring that to your attention. I will put a workaround in my data processing code for the time being.
Thanks much,
Bob Y.

Rob Lucchesi (rlucchesi@gmao.gsfc.nasa.gov) replied:

We are looking into this now. It appears to occur at the level where the data has tapered off to very tiny non-zero numbers just prior to the fields becoming constant=0.
Thanks for the info.

--Bmy 10:23, 1 April 2008 (EDT)

Wet scavenging in GEOS-5

It was discovered that there can be significant differences in the amount of tracer lost to wet scavenging in GEOS-5 as compared to the equivalent run in GEOS-4. Click HERE to view a powerpoint that describes some of the differences.

Hongyu Liu suggested the following modifications to the wet scavenging algorithm for GEOS-5:

Hongyu Liu (hyl@nianet.org) wrote:

Shutting off rainout/washout for convective precip is legitimate since in GEOS5-Chem the cloud anvil precip is already included in the large-scale precip. Indeed, the fraction of large-scale precip in total precip is much larger in GEOS-5, as shown in Bob's earlier plots. One of the "knobs" that can be turned is the rainout for frozen precipitation (at temperatures below 258K). While this was off in Liu et al. [2001], you decided to turn it on for full-chem with previous GEOS series.
With rainout for BOTH conv precip and frozen LS precip turned OFF, the GEOS-5 simulation has been improved --- closer to the GEOS-4 simulation. Note that BOTH were turned ON in the GEOS-4 simulation. See plots below.
Surface concentrations:
Surface fluxes:
210Pb deposition fluxes are biased low especially in the NH, suggesting that 222Rn emissions in the current version of G-C are too low. I don't see this bias in GMI, although both models followed Jacob et al. [1997] for 222Rn emissions. Probably it was implemented differently. Need to check into this.
Anyway, it appears that we can improve the GEOS-5 simulation by turning off rainout/washout for convective precip and suppressing rainout for LS precip at temperatures below 258K.
What do you think? If you agree, Bob might want to implement this modification for GEOS-5 full-chem.

These modifications were implemented GEOS-Chem v8-01-01.

--Bmy 10:15, 22 April 2008 (EDT)

GEOS-5 PBL heights - diurnal variation of tracers

Sajeev Philip(philip.sajeev@dal.ca) wrote:

This addition to the wiki is intended to foster discussion and communication about PBL heights in GEOS met fields. Large differences in the diurnal variation in the GEOS-4 and GEOS-5 PBL heights are affecting the GEOS-Chem simulations.


The animated figure above (from Jeff Pierce and Chris Wainwright) shows a map of the percent change in the PBL height between the GEOS-5 and GEOS-4 met fields (for April 2004), calculated as (GEOS5-GEOS4)/GEOS4*100). The solid black vertical line shows the longitude where the local noon is occurring. GEOS-5 is predicting generally much lower PBL heights than GEOS-4 at night, but higher PBL heights during the day over land.


The figure above shows the mean diurnal variation of PM2.5 concentrations over 588 sites (red line)across the continental US (for 2005 June, GEOS-Chem simulation (v8-03-01) by Aaron van Donkelaar) while using GEOS-5 (blue) and GEOS-4 (green) met fields. We suspect that the large build up of aerosols overnight in GEOS-5 run is related to low PBLH overnight.

Sajeev Philip (April 14, 2011)