20001201: MDXX problems in McIDAS-X 7.6x PROPLT (cont.)

>From: "Patrick S. Market" <address@hidden>
>Organization: University of Missouri-Columbia
>Keywords: 200011141520.eAEFKZO20569 McIDAS-X 7.6x PROPLT

Pat,

>Thanks for your patience and your offer to logon.  I think Anne Wilson did it
>a few months back, so I know that your machine is in the hosts.allow file.

OK.

>The raw profiler data is in     /asp/ap/market/970410prof 
>
>I'll be in St. Louis, MO, the rest of the day.  I'll write again on Monday.

I logged in from Anne's machine and quickly determined that WNCI2 _should_
have data!  I did this by looking at the contents of a couple of the
netCDF files in /asp/ap/market/970410prof.

The next thing I did was to look in MDXX7780 to see if data had actually
had been decoded for WNCI2, and it _HAD_.  So the mystery boiled down
to why MDL, PROPLOT, PROFP, and PROFSECT couldn't list/plot the data
for that station.

The answer came back that cdftomd was storing an incorrect number of
available stations in the MD file ROW header.  It was saying that there
were 29 stations with data, when it should have been saying that
stations with data extend out to COLumn 32 in the file.  (McIDAS MD
files are "look" like two dimensional arrays:

                     COL-->    1      2      3            32
     ROW 
      | DAY,TIME,CMAX        PLTC2  VBGC1  WSMN5   ...   WNCI2
      |
      v

The header in each ROW has how many stations are available in that row.
The decoder is incorrectly counting how many stations actually have data
(that _is_ 29), not what the last COLumn holding data actually is.

I modified the file (by using the McIDAS 'LWU POKE' invocation) and changed
the row headers' number of stations key (CMAX) from 29 to 32 and then
was able to list out the decoded data for WNCI2:

cd mcidas/data
redirect.k ADD MDXX7780 \"/asp/ap/market/970410prof
mdl.k 7780 ALL KEYS=DAY TIME ROW IDA IDB Z DIR SPD MODE Z=0 IDA=WNCI
   DAY   TIME   ROW IDA  IDB      Z  DIR   SPD     MODE
  97100      0    1 WNCI 2        0            LOW
  97100      0    2 WNCI 2        0            HIGH
  97100  10000    3 WNCI 2        0            LOW
  97100  10000    4 WNCI 2        0            HIGH
  97100  20000    5 WNCI 2        0            LOW
  97100  20000    6 WNCI 2        0            HIGH
  97100  30000    7 WNCI 2        0            LOW
  97100  30000    8 WNCI 2        0            HIGH
  97100  40000    9 WNCI 2        0            LOW
  97100  40000   10 WNCI 2        0            HIGH
  97100  50000   11 WNCI 2        0            LOW
  97100  50000   12 WNCI 2        0            HIGH
  97100  60000   13 WNCI 2        0            LOW
  97100  60000   14 WNCI 2        0            HIGH
  97100  70000   15 WNCI 2        0            LOW
  97100  70000   16 WNCI 2        0            HIGH
  97100  80000   17 WNCI 2        0            LOW
  97100  80000   18 WNCI 2        0            HIGH
  97100  90000   19 WNCI 2        0            LOW
  97100  90000   20 WNCI 2        0            HIGH
  97100 100000   21 WNCI 2        0            LOW
  97100 100000   22 WNCI 2        0            HIGH
  97100 110000   23 WNCI 2        0            LOW
  97100 110000   24 WNCI 2        0            HIGH
  97100 120000   25 WNCI 2        0            LOW
  97100 120000   26 WNCI 2        0            HIGH
  97100 130000   27 WNCI 2        0            LOW
  97100 130000   28 WNCI 2        0            HIGH
  97100 140000   29 WNCI 2        0            LOW
  97100 140000   30 WNCI 2        0            HIGH
  97100 150000   31 WNCI 2        0            LOW
  97100 150000   32 WNCI 2        0            HIGH
  97100 160000   33 WNCI 2        0            LOW
  97100 160000   34 WNCI 2        0            HIGH
  97100 170000   35 WNCI 2        0            LOW
  97100 170000   36 WNCI 2        0            HIGH
  97100 180000   37 WNCI 2        0            LOW
  97100 180000   38 WNCI 2        0            HIGH

(the fact that there is no wind speed (SPD) or direction (DIR) at the lowest
level is not suprising.  there _is_ good data for WNCI2 at other levels).

In order to correct other profiler MD files, I wrote a little McIDAS McBASI
script that can be modified and reused.  The file, mcidas/data/POKE.MCB
starts at the MD file location 4099 and sets values to 32 for every
four file locations.  I put a little documentation at the top of the file
so you can use it until 'cdftomd' gets fixed.  An invocation would look
like:

cd mcidas/data
redirect.k ADD MDXX7780 \"/asp/ap/market/970410prof
run.k MDXX7780 FILE=POKE.MCB

I tested out PROPLT's ability to generate a good, usable GIF (tm) from
the corrected file as follows:

mcenv
proplt.k WNCI2 18 17 MDF=7780 DAY=1997100
frmsave.k 1 proplt.gif
exit

This generated the GIF file 'proplt.gif' in the mcidas/data directory of the
user account you let me login to.  I FTPed the file back here to the UPC
and took a look; it looks entirely reasonable.

So, the problem is in the cdftomd decoder (and perhaps the newer 'proftomd'
decoder) that is part of ldm-mcidas.  I will have to take a look at this
routine and update it with the next ldm-mcidas release (which is coming
up within a couple of weeks).

Sorry for the incredible hassle!

Tom