Re: 20050621: Gempak - Decoding ACARS data

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to address@hidden for more info.

Justin,

I've attached an updated Linux binary of dcacars (were you running the
binary distribution of GEMPAK, or did you build from source? I
can post the updated source code if necessary).

If you need me to post the file instead of attaching to email let me know,
and I can do that- but its easier this way. This will be included in the
next distribution I post.

This binary will recognize the TAMDAR RH variables of
sensor[1,2]RelativeHumidity
as a replacement for the previous "rh_probe" variable that FSL used.

Steve Chiswell

****************************************************************************
Unidata User Support                                    UCAR Unidata Program
303 497 8643                                                  P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata WWW Service              http://my.unidata.ucar.edu/content/support
****************************************************************************

On Tue, 21 Jun 2005, Unidata Support wrote:

>
> Justin,
>
> It seems that FSL has updated/changed the CDL of their file, now
> at 1.7 according to your dump.
>
> The decoder is looking for certain known identifiers, and after not finding
> "rh_probe" as one of the variables, it is exiting the netcdf routine without
> decoding the data. It would appear that the CDL is now identifying the
> TAMDAR RH as sensor1RelativeHumidity and sensor2RelativeHumidity.
>
> I'll have to update the decoder accordingly.
>
> Steve Chiswell
> Unidata User Support
>
>
>
>
>
> >From: "Justin Sharp" <address@hidden>
> >Organization: UCAR/Unidata
> >Keywords: 200506212049.j5LKnpB1007873
>
> >Institution: Bonneville Power Administration (DoE)
> >Package Version: 2.1
> >Operating System: Redhat Linux
> >Hardware Information: HP XW 8200 Workstation
> >Inquiry: The weather group at BPA has recently been granted access to ACARS 
> >da
> > ta by FSL.  However, since our machines sit on a DMZ behind a proxy server, 
> > w
> > e have to use the FSL Madis FTP server, rather than getting the data from 
> > FSL
> > \'s ldm.
> >
> >I figured that these files would have the same form as those on the ldm and 
> >th
> > at I could push them into dcacars to convert them from netCDF to gempak 
> > forma
> > t.  However, I can\'t seem to get this to work and am now wondering if the 
> > fi
> > le contents are different.
> >
> >Do you know if these files will be the same, and if so, have you any idea 
> >what
> >  I\'m doing wrong?
> >
> >Here\'s what I\'m doing (from the ~ldm directory):
> >decoders/dcacars -v -x -f /tmp/20050621_1600 -e 
> >GEMTBL=/usr/local/nawips/gempa
> > k/tables -l - data/gempak/acars/YYYYMMDDHH_acars.gem
> >
> >I\'ve also tried outputing to file test.gem.
> >
> >Here\'s the log message (with the -v and -x flags):
> >Jun 21 20:39:54 dcacars[7027]: Starting up
> >        putenv GEMTBL=/usr/local/nawips/gempak/tables
> >        will get input from /tmp/20050621_1600
> >        decode_acars /tmp/20050621_1600 miss -9999 ier 0 cdfid 3
> >        decoding ncacars
> >        version name len is 3
> >        version type is NC_CHAR 1.7 VAL 1.700000
> >        CDF file version is 1.700000
> >Jun 21 20:39:54 dcacars[7027]: MADIS ACARS data
> >Jun 21 20:39:54 dcacars[7027]: No pressure variable, will calculate
> >Jun 21 20:39:54 dcacars[7027]: correctedWVMR not present
> >        encrypted name length is 12
> >Jun 21 20:39:54 dcacars[7027]: Warning: Tail number exceeds 8 characters, 
> >will
> >  truncate on storage
> >Jun 21 20:39:54 dcacars[7027]: could not get variable information
> >Jun 21 20:39:54 dcacars[7027]: could not decode data 0
> >Jun 21 20:39:54 dcacars[7027]: Exiting
> >
> >I\'ve attatched the oldest acars file I could download from fsl (so that 
> >nobod
> > y gets upset) to see if you can verify if it is compatible with dcacars.  
> > Its
> >  a valid netCDF file (viewed it with ncdump).  Of course, I\'m gunzipping it
> > before trying to run dcacars.
> >
> >Help is much appreciated, as I\'m pulling out what little hair I have left :)
> >
> >Thanks,
> >
> >Justin
> >
> >
> >
> --
> NOTE: All email exchanges with Unidata User Support are recorded in the
> Unidata inquiry tracking system and then made publicly available
> through the web.  If you do not want to have your interactions made
> available in this way, you must let us know in each email you send to us.
>