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

20010305: ncdc radar at stc (cont.)

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 200102202133.f1KLXZL10511 McIDAS NEXRAD display


>Okay, Tom;  one last push


>I/we must be close, but I am stalled.  I have done the following, all on
>waldo, as user mcidas
>1. created, on waldo,  /NCDC/RADAR/KMPX/NTP   changed ownership to mcidas
>   (can't see that the KMPX as different from your MPX should matter)

The only difference should be in how you setup the configuration file.

>   moved a couple of files, KMPX2000..... to that location


>2. copied NNEXRAD.CFG  to NCDCNEXR.CFG and edited last 3 lines.
>   I think I edited as you directed, but may have misinterpreted
>   I did look at the examples in the original file.
>   I tried a couple of different variations, but end results were the same

If you put just what I said previously, then the setup will not work
since your directory structure is subtly different.

If you are putting the Storm Total Precip. products for MPX in
/NCDC/RADAR/KMPX/NTP, then the DIRMASK= entry in NCDCNEXR.CFG will need
to be:


See below for more...

>3. Ran DSSERVE ADD as you instructed in your message of this morning;  no
>   error msg. Did this each time I changed  the CFG file in 2.


>4. DATALOC  shows I have a dataset RTNEXRAD on Local Data, 
>   tried IMGDISP  as  IMGDISP  NCDCNEXR/NTP ID=MPX (also with times)
>   but no display.

I will assume that this is due to the difference in your directory
setup and the configuration file DIRMASK= mask.

>5. Went back to your email of Friday, and copied DSSERVE.BAT to NCDCNEXR.BAT,
>   then edited to just a 1 line file reading
>   DSSERVE ADD NCDCNEXR/NTP    NEXR  1 9999  .....   as listed in
>DSSERVE.BAT for the NTP line
>   Ran Batch NCDCNEXR.BAT    ran ok

This should end up being the exact same DSSERVE line as I sent in my
previous email.

>   Ran DATALOC ADD NCDCNEXR  waldo.stcloudstate.edu  ok

The only difference in doing this is that now the requests go through
the remote ADDE interface, not the LOCAL-DATA one.  For the user 'mcidas'
this will be more-or-less identical.

>6. Now, I have the same dataset defined in 2 different ways, but IMGDISP
>still fails.

OK, see below.

>7. Also, tried IMGLIST  NCDCNEXR/NTP  ID=MPX (also tried KMPX  and all) but
>cannot get it to list the files.
>So, there is a snag someplace.  I see where the DSSERVE ADD tells it to
>read the CFG file, 
>where the instructions are found as to where the data set is, and how it is
>named, but 
>can't see where I messed up.

>In the .CFG file?

I took the liberty of logging on and correcting the DIRMASK entry in your
~mcidas/workdata/NCDCNEXR.CFG file.  It now reads:


>In use of IMGDISP ?

No, this was correct.

>Wrong command for display?  


>Can you show me the error of my ways?

Hopefully :o)

>do I need a REDIRECT entry for this ?

No, the DIRMASK= entry tells the server where to find the files;  the
FILEMASK= entry tells the server how the files are named; and the
IPMASK= entry tells the server who is allowed access to the data.
These are now all setup correctly.

Since I could not get a listing of the files you put in /NCDC/RADAR/MPX/NTP,
I decided to invoke IMGDISP with server tracing turned on:

<on waldo as 'mcidas'>

cd workdata
rm -f ~mcidas/mcidas/data/trce

This tells the server to log information in the file ~mcidas/mcidas/data/trce.

The contents of the trce file shows:

cat ~/mcidas/data/trce

Image file directory listing for:NCDCNEXR/NTP
imglist.k: There are no images that meet the selection criteria
imglist.k: done
/home/mcidas/workdata% cat ~/mcidas/data/trce
nexradir:: starting up
nexradir:: dataset descriptor: NTP
nexradir:: configuration file name: NCDCNEXR.CFG
GetConfigInfo:: INFO= specified
nexradir:: data directory: /NCDC/RADAR/K\ID/\TYPE
nexradir:: file name mask: K\ID*.*
nexradir:: info file name:
nexradir:: allowed IP mask: *
AllowedAccess:: IP mask does not restrict access
nexradir:: bpos = 0 epos = 0
nexradir:: btim = -1 etim = -1
nexradir:: bday = -1 eday = -1
nexradir:: bss = -1 ess = -1
nexradir:: cblock =
nexradir:: cid = MPX
GetFileList:: file directory matching mask: /NCDC/RADAR/KMPX/NTP/KMPX*.*
GetFileList:: matching pattern list length: 2
GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580
GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580
ReadNexrInfo:: file: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580
ReadNexrInfo:: 512 bytes to read from NEXRAD file
ReadNexrInfo:: 0 header bytes in file type 0
request ID: MPX  image ID:   ÿ
ReadNexrInfo:: file: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580
ReadNexrInfo:: 512 bytes to read from NEXRAD file
ReadNexrInfo:: 0 header bytes in file type 0
request ID: MPX  image ID:   ÿ
SelectNexrImages:: relative file positions
There are no images that meet the selection criteria

So, the things we can learn from this listing are the following:

1) the configuration file is setup to correctly locate and name the data
   files.  We know this because the files are found (reference the
   lines that look like:

   GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1017_00.580
   GetFileList:: filename: /NCDC/RADAR/KMPX/NTP/KMPX20000416_1121_00.580

   These are the two files that you put in the /NCDC/RADAR/KMPX/NTP
   directory.  So far so good.

2) The server tries to determine exactly what kind of a NIDS file this

   ReadNexrInfo:: 0 header bytes in file type 0

   This is saying that the file is _not_ a zlib-compressed NEXRAD Level
   III image product.  Rather, its header makes it look like it _might_
   be a WSI NIDS product.

Since the last observation did not make sense to me, I FTPed one of the
files back here to Unidata and took a close look at it.  The end of an
output for KMPX20000416_1017_00.580

LWU LIST KMPX20000416_1017_00.580      (You could do this on waldo also.)

shows what is going on:

    3450.  538981424   808333360 HEX: 20203430 302E3030 ASCII:   40 0.00
    3452.  541936928   538976288 HEX: 204D4D20 20202020 ASCII:  MM
    3454.  538968144  1296649760 HEX: 20200050 4D494E20 ASCII:    P MIN
    3456. 1213353049   541540679 HEX: 48524C59 20474147 ASCII: HRLY  GAG
    3458. 1159745362   542261572 HEX: 45204F52 20524144 ASCII: E OR  RAD
    3460. 1095901249  1128486221 HEX: 41522041 4343554D ASCII: AR A CCUM
    3462.  773869125  1162102084 HEX: 2E204E45 45444544 ASCII: . NE EDED
    3464.  541478738   541215041 HEX: 20464F52 20424941 ASCII:  FOR  BIA
    3466. 1394623297  1279481164 HEX: 53204341 4C43554C ASCII: S CA LCUL
    3468. 1096042831  1311649326 HEX: 4154494F 4E2E2E2E ASCII: ATIO N...
    3470.  538976288   538980398 HEX: 20202020 2020302E ASCII:        0.
    3472.  909123661  1293951008 HEX: 3630204D 4D202020 ASCII: 60 M M
    3474.  538976288      -32640 HEX: 20202020 FFFF8080 ASCII:

This file is not a NEXRAD image file at all!  Instead, it appears to be the
digital precipitation array product.  Since this product is not an image,
I never tried to support it with my ADDE NEXRAD image server.

So, the question now is whether or not the student grabbed the incorrect
data file, or whether the student actually wants the digital precip.  array
for his/her work?


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.