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

[McIDAS #NJW-868492]: station 60018

Hi Randy,

Well, the test I ran yesterday did not fix the SIG decoding
problem on lead4.unidata.ucar.edu.  After verifying that nothing
had changed, I started doing comparisons of XCD configurations
on adde.ssec.wisc.edu (where SIG decoding for all countries
is working) and lead4.unidata.ucar.edu (one of the machines
under our control where SIG decoding is not working).  I think
I found the problem:

- RAOB decoding is controlled, in part, by configurations in
  the file IRABDEC.CFG

  A comparison of the copy of IRABDEC.CFG on adde.ssec.wisc.edu
  and lead4.unidata.ucar.edu revealed the problem:


NSIG=20000                # number of columns to make the significant
                          # level data

  lead4.unidata.ucar.edu and adde.ucar.edu:

NSIG=6000                 # number of columns to make the significant
                          # level data

  The NSIG parameter controls how many significant level stations
  can be included in the output MD file for significant level
  reports; the number must be larger when decoding more stations
  significant level data.

  I just changed the NSIG parameter in the IRABDEC.CFG file (which
  is ASCII) on lead4.unidata.ucar.edu and adde.ucar.edu.  This change
  should result in decoding of significant level data for all
  RAOBs as soon as a new significant level upper air file is
  created -- this will be 0Z for both lead4.unidata.ucar.edu and

Why the IRABDEC.CFG file was different on adde.ssec.wisc.edu
and lead4.unidata.ucar.edu and adde.ucar.edu is something I
will be investigating today.  I just checked the Unidata
McIDAS-X/-XCD distribution and see that the NSIG setting is
correct in it.  This implies (reminds me?) that this file is
not overwritten when doing an upgrade of an existing XCD installation.
Since the McIDAS installations on lead4.unidata.ucar.edu and
adde.ucar.edu were "old" (preexisting), the change needed to
decode all SIG data was not set as it should be.  Since the
installation on adde.ssec.wisc.edu was new, the version of
IRABDEC.CFG contained in the distribution was/is used.

So, what you should do is:

<as 'mcidas' on your machine that is running XCD decoding>
-- edit IRABDEC.CFG and change NSIG=6000 to NSIG=20000

This change _should_ take effect before 0Z raobs are decoded
this afternoon.  To be sure that they change does take
effect, I recommend stopping and restarting the LDM on
the machine running XCD decoding _after_ making the
change to IRABDEC.CFG:

<as 'ldm'>
ldmadmin stop
ldmadmin start


ldmadmin restart

I feel confident that the IRABDEC.CFG NSIG setting is the
root of the problem that we have been experiencing.  Please
let me know how things are working after running UALIST 60018
for tomorrow's 0Z reports (not today, there is nothing you
can do to fix the problem for today's 0 and 12Z obs since
the data has already come and gone).

One more thing:

If you want/need to back fill your SIG decoded data (for example
you are creating an archive of data), you should be able to copy
the SIG MD files from adde.ssec.wisc.edu (for as many as are there)
to your local machine using PTCOPY.  If you decide to try this,
I recommend copying to a different MD file name range than is
currently in use for real-time decoded SIG files (so you don't
shoot yourself in the foot).  Let me know if you want/need more
information on how I would do this.


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: NJW-868492
Department: Support McIDAS
Priority: Normal
Status: Closed

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.