Re: 20040420: 20040319: Gempak - Solaris 8 - decoding drops with dcuair

That worked great.  Thanks!
Megan Gentry

>
> Megan,
>
> You are decoding each of the drops100x.txt to the same test.gem file,
> which
> only has 24 times allowed in it. The confusion is that I meant to merge
> the
> decoded content from three separate files into a new created file
> (actually
> using the SNMOD program) created with SNCFIL to allow more than 24 times.
>
> You should be able to do the following:
>
> dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 test1.gem < drops1001.txt
> dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 test2.gem < drops1002.txt
> dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 test3.gem < drops1003.txt
>
> You can ignore the "-p snmerg.pack" as it is the default.
>
> Then, create a new sounding file with SNCFIL:
>  SNOUTF   = testmerg.gem
>  SNPRMF   =
>  STNFIL   =
>  MRGDAT   = no
>  TIMSTN   = 200/2000
>  GEMPAK-SNCFIL>r
>
>  SNCFIL PARAMETERS:
>
>  New sounding file:     testmerg.gem
>  Station file:
>  Number of stations in STNFIL:       0
>  Number of additional stations:   2000
>  Total number of stations:        2000
>  Total number of times:            200
>
>  This file will be an unmerged sounding file containing
>  mandatory and significant data below and above 100 mb.
>
> Enter <cr> to accept parameters or type EXIT:
>  Parameters requested: SNOUTF,SNPRMF,STNFIL,MRGDAT,TIMSTN.
>  GEMPAK-SNCFIL>
>
> Again here, the SNPRMF is blank and will use the snmerg.pack file.
> Note that these are unmerged files from the decoder.
>
> --------------------------------------------------------------
>
> Now use SNMOD to copy over each existing file into the new testmer.gem
> file
>
>  SNFILE   = test1.gem
>  SNOUTF   = testmerg.gem
>  SNPARM   = dset
>  AREA     = dset
>  DATTIM   = all
>  LEVELS   = all
>  VCOORD   = pres
>  TIMSTN   = 200/2000
>  MRGDAT   = no
>  IDNTYP   = stnm
>  GEMPAK-SNMOD>r
>
>  <stuff>
>
>  SNFILE = test2.gem
>  GEMPAK-SNMOD>r
>
>  <stuff>
>
>  SNFILE = test3.gem
> GEMPAK-SNMOD>r
>
>  <stuff>
>
>
> At this point, you should be able to use your combined
> file as merged or unmerged in SNLISt etc.
>
> Steve CHiswell
>
>
>
>>From: Megan Gentry <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200404202059.i3KKxgCT006461
>
>>Thanks for your help!
>>I do have a question about using SNMERG though.  I've been using the
>> following
>>commands to try and combine soundings from three different days into one
>> file.
>> ..
>>dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 -p snmerg.pack test.gem <
>>drops1001.txt
>>dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 -p snmerg.pack test.gem <
>>drops1002.txt
>>dcuair -c 021004/0000 -b 2000 -m 24 -a 2000 -p snmerg.pack test.gem <
>>drops1003.txt
>>The total number of dropsondes over all three days is 65.  So, my -a
>> parameter
>>  of
>>2000 should be more than sufficient.  However, when I look at the
>> soundings in
>>SNLIST, only the first 49 soundings processed are showing up.
>>I can decode all three days into individual files, so I know that the
>> problem
>>isn't with the sounding data.  Does snmerg only allow a certain number of
>>soundings to be in one file?  Or is it that one of the flags in my dcuair
>> comm
>> and
>>isn't set correctly?
>>Thanks,
>>Megan Gentry
>>
>>
>>Unidata Support wrote:
>>
>>> Megan,
>>>
>>> This sounds like you either don't have enough stations allowed in your
>>> created file, or you have run out of time slots. my guess is that your
>>> drops10.txt has more than 24 hours worth of data....for example,
>>> in SNLIST, using DATTIM=list, you may see times from the previous day.
>>>
>>> The best way to work with this is to use the YYYYMMDD template
>>> in your output file name, instead of test.gem. This way, each file will
>>> have one day or 24 hours in the file. If you need to combine the data
>>> into
>>> a single file later, then you can use SNMERG to copy multiple files
>>> into a single file, but at least with the decoder, in order to
>>> accomplish
>>> the hourly bins with -m 24, the initial step should be daily files.
>>>
>>> The other p[ossibility would be you are allowing space for 1000
>>> additional
>>> stations (the -a flag) in your data set....and since you have
>>> dropsondes,
>>> they won't be in the snstns.tbl file. Depending on the number of
>>> dropsondes
>>> you have, you may need to increase that.....but that wouldn't be likely
>>> for
>>> broadcast data....but would be more likely if you had field experiment
>>> data.
>>>
>>> Steve Chiswell
>>>
>>> >From: "Megan Gentry" <address@hidden>
>>> >Organization: UCAR/Unidata
>>> >Keywords: 200403192136.i2JLasQB029999
>>>
>>> >Institution: NC State Forecasting Lab
>>> >Package Version: 5.6
>>> >Operating System: Solaris 8
>>> >Hardware Information: Sun workstation
>>> >Inquiry: I'm trying to decode several dropsondes using dcuair.  I\'m
>>> having
>>  tr
>>> > ouble getting them all decoded with hourly entries.  I used the
>>> following
>> com
>>> > mand and all of the dropsondes were decoded...
>>> >dcuair -c 021004/0000 -b 1000 -m 150 -a 1000 test.gem < drops10.txt
>>> >However, this only produced entries every 3 hours.  I read up on the
>>> -m opt
>> ion
>>> >  and realized that I should have set it to 24 to have entries hourly.
>>> So I
>>  us
>>> > ed the same command, only with the -m option changed to 24.  This
>>> time I g
>> ot
>>> > hourly entries.  However, when I used snlist to look at the
>>> dropsondes, th
>> e o
>>> > nes near the end of the dataset were missing.  The dcuair.log file
>>> had the
>>  sa
>>> > me number of bulletins read and processed with both commands.
>>> >Is there another option that I need to change when I reset -m to 24?
>>> >Thanks,
>>> >Megan
>>> >
>>> >
>>> >
>>> --
>>> ****************************************************************************
>>  <
>>> 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
>>  <
>>> ----------------------------------------------------------------------------
>>  <
>>> NOTE: All email exchanges with Unidata User Support are recorded in the
>>> Unidata inquiry tracking system and then made publically 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.
>>
> --
> ****************************************************************************
> <
> 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  <
> ----------------------------------------------------------------------------
> <
> NOTE: All email exchanges with Unidata User Support are recorded in the
> Unidata inquiry tracking system and then made publically 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.
>