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

20010815: SFCPLOT not displaying any data

>From: Mark W Wysocki <address@hidden>
>Organization: Cornell
>Keywords: 200108151954.f7FJsN115851 McIDAS SFCPLOT

Mark,

>       I originally thought this inquiry should go to McIDAS
>       but they think you can help me.

It appears that you sent this inquiry to the SSEC McIDAS help desk.
Universities get McIDAS from Unidata and the deal we have with SSEC is
that we (Unidata) provide the support for those users.  This means that
all questions should be sent to Unidata User Support, not the SSEC
McIDAS help desk.  I had this same exchange with Wayne back in the
beginning of July.  I am sorry that he failed to pass along the need to
contact Unidata and not SSEC.

>>          A couple of items for you.
>>
>>          1) We just lost our systems admin person by the
>>             name of Wayne Bresky.  So I need to change the
>>             site coordinator back to myself.  Our information
>>             should read
>>
>>                  site--Cornell University
>>                  coordinator--Mark W Wysocki

Not again!?  This is a big loss given that we have been helping Wayne
get both McIDAS and GEMPAK working at Cornell after Jim DeMarco left.
Just when it appeared that everything was starting to work smoothly, he
leaves!  Bummer!!

I will see to it that the Unidata site contact list is updated with your
name in replacement of Wayne's.

>>          2) Now that I have been handed the task of system admin
>>             (hopefully temporarily) I have a question.  I can't seem
>>             to get any surface plots to work.  I typed
>>
>>          EG;SFCPLOT X NY LSIZE=9
>>
>>          and the response is
>>
>>          No data found matching search conditions
>>
>>          This command use to work until yesterday.

OK, a couple of things here.  First, the default parameter to plot for
a SFCPLOT is a station model PLOT.  This would work IF a couple of things
were setup correctly:

o your McIDAS session is pointed to an ADDE server that provides access
  to the default ADDE dataset used by SFCPLOT, RTPTSRC/SFCHOURLY

o there is data for ADDE to serve in RTPTSRC/SFCHOURLY

Since you say that this command worked until yesterday, it seems most
likely that the problem is the latter, not the former.

>>          I then typed
>>          MDU LIST 1 10
>>
>>          and the response was
>>
>>          MDA   CREATED  SCHM   PROJ   NR   NC   ID        DESCRIPTION
>>            6    2001226   ISFC   0     72   600  2001226    SAO/METAR
>>  data for  14 AUG

This demonstrates that your session can find MD files, but, given that
you sent in this inquiry on the 15th, the most recently decoded surface
data was old.

>>          Are you sending surface data or is the probelm on my end,
>>  i.e. the ldm???

Surface data in McIDAS MD format has not been sent in a satellite broadcast
since the end of June in 1999.  In order to look at POINT data in McIDAS,
one has to do one of two things:

o run the XCD component of Unidata McIDAS; XCD is a set of decoders that
  will turn the raw data being received by the LDM into McIDAS compatible
  data files

o set a DATALOC to point at an ADDE server at a cooperating site that is
  running XCD and producing McIDAS POINT (MDXX) data files

Given that the data you see on your system is old, the problem is either
with your LDM, or the XCD decoder that produces the output MD files.

So, we have a couple of jobs to accomplish here:

o troubleshoot why your system is not converting the data conveyed by the
  Unidata IDD into McIDAS compatible data files

o increase your awareness of how McIDAS now works

Let's start with the easy part, increasing your awareness of McIDAS' ability
to access datasets from remote servers.

First, let's find out where your McIDAS session is attempting to read
its data.  Run the following:

DATALOC LIST RTPTSRC

The output from this command will be the machine (name or IP address)
of the ADDE server your session is attempting to get data from.  It
could also read as LOCAL-DATA.

In the case of LOCAL-DATA, it means that your McIDAS session must be
setup to understand the mapping between ADDE dataset name (in the form
of group/descriptor) and the data file(s) that comprise that dataset.
The dataset name RTPTSRC/SFCHOURLY, the default dataset for SFCPLOT and
SFCCON, is typically setup to be all MD files in the range of MDXX0001
- MDXX0010, inclusive.  This is not how I recommend sites setup ADDE
access to data at their sites.  Instead, I recommend tha the 'mcidas'
account be setup to understand the mapping between dataset names and
physical data files; that the ADDE remote server be installed on the
machine that is running the XCD decoders (which will be the same machine
that is running the LDM and has McIDAS installed on it); and each
client (a client is a McIDAS user including ordinary users and the
user 'mcidas') be setup to request their data from that remote server.

I walked Wayne B. through the process of setting up the remote ADDE server
on the machine, vorticity.cit.cornell.edu.  With Wayne, I tested remote
access to this machine from Unidata.  I _assume_ that Wayne helped setup
your McIDAS session to access data from your own ADDE data server,
vorticity.cit.cornell.edu.

I checked data availability from virticity, and note that it now seems
to have current data.  For reference, here is what I did:

DATALOC ADD RTPTSRC VORTICITY.CIT.CORNELL.EDU
DSINFO POINT RTPTSRC
        Dataset Names of Type: POINT in Group: RTPTSRC

Name         NumPos   Content
------------ ------   --------------------------------------
AIRCRAFT        10    Real-Time Aircraft data
FOUS14          10    Real-Time FOUS14 data
LIGHTNING       10    Real-Time Lightning data
PROF6MIN        10    Real-Time 6-Minute Profiler data
PROFHOURLY      10    Real-Time Hourly Profiler data
PTSRCS         100    All point data in MDXX files
SFCHOURLY       10    Real-Time SFC Hourly
SHIPBUOY        10    Real-Time Ship and Buoy data
SYNOPTIC        10    Real-Time SYNOPTIC data
UPPERMAND       10    Real-Time Upper Air (Mandatory Levels)
UPPERSIG        10    Real-Time Upper Air (Significant Levels)

DSINFO -- done

PTLIST RTPTSRC/SFCHOURLY
Row :      1  Col :     31
TYPE        =         0             | DAY         =   2001230 CYD         |
TIME        =         0 HMS         | NREC        =      2287             |
ID          =      PAAP             | LAT         =   56.2500 DEG         |
LON         =  134.6500 DEG         | ZS          =         1 M           |
ST          =        AK             | CO          =        US             |
MOD         =         0             | HMS         =    235800 HMS         |
CIGC        =         2             | CC1         =         1             |
CC2         =         1             | CIGH        =     4000. FT          |
ZCL1        =      600. FT          | ZCL2        =     2000. FT          |
VIS         =      15.0 MI          | WX1         =        R-             |
WX2         = _missing_             | T           =    288.16 K           |
TD          =    286.16 K           | DIR         =       130 DEG         |
SPD         =       1.0 MPS         | GUS         = _missing_             |
PSL         =   1017.60 MB          | PCP         = _missing_             |
SNO         = _missing_             | PRE         = _missing_             |
P24         = _missing_             | WXC1        =        61 CODE        |
WXC2        = _missing_             | WXC3        = _missing_             |
WXC4        = _missing_             |
---------------------------------------------------------------------------
Number of matches found = 1
PTLIST: Done

The DATALOC command told my McIDAS session to request all data from the
RTPTSRC dataset from the server vorticity.cit.cornell.edu.

The DSINFO POINT RTPTSRC command made a request of your remote ADDE
server to list back all of the descriptors (elements) that were
available in the dataset whose group name is RTPTSRC.  The list that
came back is the default setup for the RTPTSRC dataset as sent out with
Unidata McIDAS.

The form of the PTLIST command above asked the server to list back the
first record from the most current MD file in the RTPTSRC/SFCHOURLY
dataset.  You can see from the listing that the DAY key for that record
indicates that the record is for today, which is 2001230 (I am writing
this at 3 UTC on Saturday morning).

The point of the above was to show how McIDAS ADDE commands are used to:

o set who you want to get data from; this is done on a dataset-by-dataset
  basis
o find out what data the server is setup to serve (the listing shows
  several descriptors for RTPTSRC: SFCHOURLY (surface hourly metar data);
  UPPERMAND (mandatory level upper air data); etc.)
o find out what data the server actually has

If you were running the latest Unidata McIDAS distribution (I kept
encouraging Wayne to wait and load this latest version, but he was in a
hurry to load 7.7x), then you could test out a new GUI interface to
McIDAS.  This GUI allows the user to easily change the data server that
s/he is requesting data from for all of the datasets supported by the
GUI.  This would have allowed you to simply bring up a GUI widget;
select a tabbed window for POINT source data access; and specify that
you want to try to get data from some server other than your own.  This
allows one to see if the lack of data on one server (which may be your
own) is shared by other servers (which are operated by a set of
cooperating sites).

I would like to encourage you to upgrade to this new McIDAS
distribution as soon as you can as it will make your, and other McIDAS
users at Cornell lives a whole lot simplier.  I can help you get this
up and running if you like.  I am even willing to do the upgrade from
7.7x to 7.80 if you give me the necessary logins (mcidas and ldm).
Please let me know.

Back to your original problem.  Since I was out of town and not able
to get to your problem when it first came into Unidata, it may be that
you have already noticed that XCD decoding on your system has resumed.
This is nice, but it leaves me wary about why it stopped in the first
place.  Perhaps this needs to be investigated further?  I can help
with this also.

Tom Yoksas