RE: 20050621: Gempak - Decoding ACARS data

Fantastic Steve.  This seems to work.  Thanks much.

Justin

-----Original Message-----
From: General Support [mailto:address@hidden]
Sent: Wednesday, June 22, 2005 9:53 AM
To: Sharp,Justin - PGPW
Cc: address@hidden
Subject: RE: 20050621: Gempak - Decoding ACARS data



Justin,

I've attached a tarfile that can be unpacked from your $NAWIPS directory
with:

gunzip -c dcacars_update.tar.gz | tar xvf -

it will unpack the unidata/ldmbridge/dcacars directory.
At that point,
cd unidata/ldmbridge/dcacars
make clean
make all
make install
make clean

Steve Chiswell
Unidata User Support

****************************************************************************
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 Wed, 22 Jun 2005, Sharp,Justin - PGPW wrote:

> Hi Steve:
>
> Thanks for responding to this so quickly with a fix.  I did build from 
> source, so if you can send me the source file that will probably help.  I'll 
> try the binary, but suspect that I'll end up with library conflicts.  I have 
> no problem recieving mail attachments.
>
> Justin
>
> -----Original Message-----
> From: General Support [mailto:address@hidden]
> Sent: Wednesday, June 22, 2005 9:28 AM
> To: Sharp,Justin - PGPW
> Cc: address@hidden
> Subject: Re: 20050621: Gempak - Decoding ACARS data
>
>
>
> 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.
> >
>