Difference between revisions of "GEOS-5 issues"

From Geos-chem
Jump to: navigation, search
(Wrong unit tag for RH in GEOS-5 raw data files)
Line 44: Line 44:
 
     20080101 180000 RH    0.000000  1.055233  --> 2x25 file regridded from GEOS-5.1.0 data
 
     20080101 180000 RH    0.000000  1.055233  --> 2x25 file regridded from GEOS-5.1.0 data
  
:Also, the last version of the [http://gmao.gsfc.nasa.gov/operations/GEOS5_V1_File_Specification.pdf GEOS-5 file spec)] that I have says RH is %.  
+
:Also, the last version of the [http://gmao.gsfc.nasa.gov/operations/GEOS5_V1_File_Specification.pdf 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.
 
: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.

Revision as of 13:59, 8 April 2008

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.

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:
   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 (rlucchesi@gmao.gsfc.nasa.gov) 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

--Bob Yantosca 10:11, 1 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:
  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 (rlucchesi@gmao.gsfc.nasa.gov) 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

--Bob Yantosca 10:23, 1 April 2008 (EDT)

Wet scavenging in GEOS-5

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.

--Bob Yantosca 10:00 9 January 2008