[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #POC-749431]: Gempak producing "grid holes" when calculating dewpoint and theta-e

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [GEMPAK #POC-749431]: Gempak producing "grid holes" when calculating dewpoint and theta-e
  • Date: Thu, 15 May 2014 17:46:48 -0600
Hi Shawn,

I sent this along to folks at NCEP and they confirmed the presence of these 
data holes.  What I was told is that, if RELH is an available grid (versus 
having to be calculated from moisture and temperature parameters), such as with 
the GFS, grid values of RELH = 0 result in ln(0) = -Inf, which in GEMPAK is 
missing data -9999.  

Michael James
Unidata 


> Hi,
> 
> We've run into a problem with Gempak using any common reanalysis
> (NCEP/NCAR, NCEP-2, CFSR) in trying to display certain moisture variables.
> Basically you get holes in the grid as in the sample image below.  The
> image below is for theta-e, but I traced it to the dwpc parameter contained
> within tlcl.  I traced it further to the part in the dwpc formula that
> calls for ln(quo(relh,100)).  I've tried substituting mixing ratio for relh
> and I get the same result.  There is something about taking the natural log
> of relh that makes it break down in random spots.  Any idea if there's a
> way around this?  I've tried multiple versions of Gempak that are otherwise
> stable (6.2, 6.4, 7.0).
> 
> Thanks,
> Shawn Milrad
> 
> 
> 
> --
> Shawn Milrad
> Cell:  732-261-3594
> 
> 


Ticket Details
===================
Ticket ID: POC-749431
Department: Support GEMPAK
Priority: Normal
Status: Open