GEOS-5 issues

From Geos-chem
Revision as of 20:02, 14 June 2012 by Sajeev Philip (Talk | contribs)

Jump to: navigation, search

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. Many of these issues have since been resolved (and are marked as such); we keep the original posts here for reference.

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

Updates on GEOS-5 PBL height & diurnal variation of aerosols

Sajeev Philip wrote:

GEOS-5.2.0-driven simulations have a high nighttime bias for aerosols (for both full-mixing and non-local mixing schemes) compared with observations. For the full mixing scheme, the bias arises from the low nighttime PBLH. We correct this by restricting the PBLH from dropping below a minimum mechanical mixing depth, defined as a function of local friction velocity (Koracin and Bberkowicz, 1988; Lin and McElroy, 2010). Figure 1 shows the diurnal variation of PBLH compared with observations from the ARM-Southern Great Plains (black line) site. The nighttime shallow PBLH in GEOS-5 is evident (blue line), which is corrected by this method (red line).
Figure 2 shows the mean diurnal variation of PM2.5 over 115 sites across the continental U.S. (measurements by Beta Attenuation Mass monitors). The threshold on PBLH reduces the diurnal variation and better matches the diurnal variation in the observations. This approach with the full mixing scheme reduces annual mean PM2.5 and NO3- over North America by 15% and 30% respectively. It also reduces the annual mean bias versus observations for PM2.5 (slope changes from 1.47 to 1.09) and NO3- (slope changes from 2.23 to 1.52).
The non-local mixing scheme has an option to recalculate the PBLH online, and it fixes the bias in nighttime PBLH. However, aerosol concentrations are unaffected, partly due to the low sensitivity to PBLH in this scheme. At this time, we recommend use of full mixing scheme with our nocturnal-GEOS-5-PBLH-correction.
Add the following correction to line 1452 in a3_read_mod.F (version 9-01-02):
     ! PBLH must be greater than a minimum mechanical mixing depth,
     ! defined as 700*friction velocity (Koracin and Berkowicz, 1988; Lin and McElroy, 2010)
#if   defined( GEOS_5 )
     DO J = 1, JJPAR
     DO I = 1, IIPAR
        PBL(I,J) = max( PBL(I,J), 700d0*USTAR(I,J) )
     ENDDO
     ENDDO
#endif
Koracin, D. and R. Berkowicz: 1988, Nocturnal Boundary Layer Height: Observations by Acoustic Sounders and Prediction in Terms of Surface Layer Parameters, Boundary-Layer Meteorol. 43, 65-83.
Lin, J. T. and McElroy, M. B.: Impacts of boundary layer mixing on pollutant vertical profiles in the lower troposphere: Implications to satellite remote sensing, Atmos. Environ., 44, 1726–1739, 2010.

Figure-1.jpg Figure-2.jpg

-- Sajeev Philip (June 14, 2012)


GEOS-5 PBL heights - diurnal variation of tracers

NOTE: This is a yet-unresolved issue.

Sajeev Philip 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.

Figure1.jpg

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.

Figure2.jpg

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)

Wet scavenging in GEOS-5

NOTE: These modifications were implemented in GEOS-Chem v8-01-01.

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 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.
Thanks,
Hongyu

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

GEOS-5 update and clarification

NOTE: This email pertained to a problem in GEOS-5.2.0, which has since been resolved.

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

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.

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
      !------------------------------

to:

#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)
     IF ( PRESENT( OPTDEPTH ) ) THEN
        OPTDEPTH = OPTDEPTH * CLDTOT
     ENDIF

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.

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

Error in GEOS-5 Cloud Optical Depths

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 has since been removed.

Overview

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.
Steven

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:

OPTDEPTH(I,J,L) = TAUCLI(I,J,L) + TAUCLW(I,J,L)

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:

OPTDEPTH(I,J,L) = ( TAUCLI(I,J,L) + TAUCLW(I,J,L) ) * CLOUD(I,J,L)

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)

Solution

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.

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

GEOS-Chem timeseries diagnostics for optical depth

GEOS-5 (and MERRA) met fields have in-cloud optical depths, as explained above. Previous met fields contained grid-box optical depths. We have accounted for this in the ND21 optical depth diagnostic, which is saved to the GEOS-Chem binary punch file output.

However, users should be aware that the timeseries diagnostics (ND48, ND49, ND50, ND51) may not have been updated accordingly. We will address this in a future model release.

Bonne Ford wrote:

On the wiki, it states that there used to be a problem that the model was saving out in cloud optical depth rather than a grid-box optical depth, but that this has since been resolved. However, in the diagnostic, I'm getting out values that are more like the ones shown for in-cloud rather than grid-box OD (they are much larger than expected, up to 200+ and average of 30+).

Bob Yantosca replied:

Here is what I think is going on. In GEOS-5 and MERRA, the optical depth was changed from grid-box to in-cloud. There is a note in optdepth_mod.F about it:
   ! !REMARKS:
   !  The optical depths in the GEOS-5 met field archives are in-cloud optical
   !  depths instead of grid-box optical depths (as was reported in the file
   !  specification documents erroneously).
In the meantime, probably nobody has updated the satellite diagnostic. (Many of the diagnostics were implemented by users according to their own needs). So probably what we need to do is to multiply the optical depth by the cloud fraction when taking the column. In diag50_mod.F (etc.), make the following modification:
               ELSE IF ( N == 82 .and. IS_OPTD ) THEN  

                  !--------------------------------------
                  ! COLUMN OPTICAL DEPTH [unitless]
                  !--------------------------------------
   #if   defined( GEOS_5 ) || defined( MERRA )
                  ! For GEOS-5/MERRA, in order to get get grid-box OD
                  ! we have to multiply by cloud fraction
                  Q(X,Y,1,W) = Q(X,Y,1,W) + ( OPTD(L,I,J) * CLDF(L,I,J) )
   #else
                  ! Other met fields already have grid-box OD's
                  Q(X,Y,1,W) = Q(X,Y,1,W) + OPTD(L,I,J)
   #endif

--Bob Y. 10:08, 3 November 2011 (EDT)

Switchover from GEOS-5.1.0 to GEOS-5.2.0

NOTE: This switchover took place in 2008. GMAO is currently preparing to update the operational product version from GEOS-5.2.0 to GEOS-5.7.1 in summer 2011.

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.
Thanks.
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

NOTE: These patches, originally introduced in v8-01-01, have now been standardized in v8-01-02. They are included in all higher versions as well.

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

Philippe Le Sager 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
-Philippe

Bob Yantosca 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.

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

NOTE: This issue has since been resolved.

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 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:
   DAS.ops.asm.tavg3d_dyn_v.GEOS510.20080320_0000.V01.hdf
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 replied:

Bob,
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
GMAO

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

NaN's found in GEOS-5 DQIDTMST field

This issue was resolved during the reprocessing of the GEOS-5 met data.

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 wrote:

Hi all,
I was processing the GEOS-5 "tavg3d_mst_v" file:
  DAS.ops.asm.tavg3d_mst_v.GEOS510.20080116_0600.V01.hdf
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!
where
  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 replied:

Bob,
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.
Rob

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