GEOS-5 issues

From Geos-chem
Jump to: navigation, search

Obsolete.jpg

NASA/GMAO ceased production of GEOS-5.2.0 data as of June 2013. See GMAO's GEOS Near-Real Time Data Products page for more details. 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. GEOS-5 was de-supported in GEOS-Chem v11-02.

On this page we list some of the problems (and fixes!) that we have encountered during the implementation of the GMAO GEOS-5.2.0 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:


GEOS-5 Boundary Layer Mixing Issues

GEOS-5 PBL heights - diurnal variation of tracers

This post has been moved to our Boundary Layer Mixing wiki page.

--Bob Y. 16:31, 2 October 2012 (EDT)

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

This post has been moved to our Boundary Layer Mixing wiki page.

--Bob Y. 16:28, 2 October 2012 (EDT)

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

Obsolete.jpg

NOTE: This email pertained to a problem in GEOS-5.2.0, which has since been resolved. We shall keep this information here for future reference. Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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

Obsolete.jpg

NOTE: This fix is obsolete. As of July 2009, we have reprocessed the entire GEOS-5 met data archive for GEOS-Chem (data dates 2004-present). We have also replaced all of the previous GEOS-5.1.0 data with the newer GEOS-5.2.0 data. The reprocessed GEOS-5.2.0 data now eliminates the need for this quick fix. We shall leave this text here for future reference.

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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 reprocessed the entire GEOS-5 met data archive for GEOS-Chem (data dates 2004-present). We have also replaced all of the previous GEOS-5.1.0 data with the newer GEOS-5.2.0 data. The reprocessed GEOS-5.2.0 data now eliminates the need for this quick fix. The code for the "quick fix" has since been removed from GEOS-Chem. We shall leave this text here for future reference.

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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

NOTE: As of July 2009, we have reprocessed the entire GEOS-5 met data archive for GEOS-Chem (data dates 2004-present). Therefore, the fix described below has been rendered obsolete. We shall keep this text here for future reference.'

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

GEOS-5.2.0 (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: The switchover from GEOS-5.1.0 to GEOS-5.2.0 described below took place in 2008. We shall leave this information in place for future reference.

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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 occured in the GEOS-5.1.0 data. In 2009, we replaced all of our GEOS-5.1.0 data with GEOS-5.2.0 data in order to correct a bug in the optical depths. We shall leave this information in place for future reference.

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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

--Bob Y. 10:00, 8 April 2008 (EDT)

NaN's found in GEOS-5 DQIDTMST field

This issue was resolved during our reprocessing of the GEOS-5 met data in 2009. We shall leave this information in place for future reference.

Furthermore, GEOS-5.2.0 is no longer being produced, and will be de-supported in GEOS-Chem v11-02.

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

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

NaN's in GEOS-5 MOISTQ field for 2006/08/27

Sebastian Eastham wrote:

Is there a known issue with NaNs in the GEOS-5 (5.2, not 5.7) MOISTQ fields for 2006-08-27? I know there was a problem with DQIDTMST, and given that MOISTQ is post-processed I was wondering if the error had propagated. I'm seeing a NaN specifically for 4&deg x 5&deg MOISTQ at I=54, J=27, L=37 in the fields centered on 2006-08-27 12:00 noon.
[There also seem] to be 5 erroneous values in the same layer and approximate location in the 2x2.5 data files.

Bob Yantosca replied:

I found 3 NaN's in the MOISTQ field using these GAMAP commands:
   IDL> gamap, file='20060827.a6.4x5', tra=19, result=R
Then via the GAMAP user interface, select the third field (centered on 12:00 GMT). Also specify:
   level: 37
   lon  : -180..180
   lat  : -90..90
GAMAP will create a plot and also return the MOISTQ field for that level the R structure. You can then find out if there are any NaN values with the following commands:
   IDL> ind = where( finite( R ) eq 0 ) 
   IDL> print, R.data[Ind]
            NaN          NaN          NaN
These NaN values may have existed in the raw data files, probably in DQIDTMST. Both MOISTQ and DQIDTMST go to zero pretty quickly once you are out of the regions where clouds form. A quick workaround could be to set those NaN values to zeroes for that particular date and time.

--Bob Y. 14:44, 4 November 2013 (EST)

Reset NaNs in MOISTQ to zero

This update was tested in the 1-month benchmark simulation v9-02r and approved on 14 Nov 2013. This update is included in Adjoint v35j.

Bob Yantosca wrote:

I have a quick fix for the MOISTQ problem described above. In GeosCore/a6_read_mod.F, change these lines:
         IF ( PRESENT( MOISTQ ) ) MOISTQ = -MOISTQ / 8.64d7
To these lines:
         IF ( PRESENT( MOISTQ ) ) THEN

            ! First replace any NaN values with zeroes.  Most NaN's in MOISTQ 
            ! have been shown to occur near the tropopause, where there are 
            ! no clouds, and no cloud or ice precip. (bmy, 11/7/13)
            WHERE( MOISTQ .ne. MOISTQ ) 
               MOISTQ = 0d0
            ENDWHERE

            ! Then convert to [kg H2O/kg air/s]
            MOISTQ = -MOISTQ / 8.64d7
         ENDIF
Tests of the form:
     IF ( X .ne. X ) THEN ...
     WHERE ( ARRAY .ne. ARRAY ) ...
Are quick ways to scan for NaN values.

--Bob Y. 15:30, 14 November 2013 (EST)

Retrieved from "https://wiki.seas.harvard.edu/geos-chem/index.php?title=GEOS-5_issues&oldid=47366"