>From: Bill Fingerhut <address@hidden>
>Organization: Lyndon State
>Keywords: 200007061904.e66J4vT23872 McIDAS-XCD RTGRIDS MRF AVN
Bill,
>It's been awhile, but we have returned to this old problem. In the
>mean time, our server (cirrus) has migrated to solaris and the
>McIDAS addendums have been installed.
OK. As of today, the story has changed. Here is what I now see:
>DATALOC ADD RTGRIDS CIRRUS.LSC.VSC.EDU
>
>Group Name Server IP Address
>-------------------- ----------------------------------------
>RTGRIDS CIRRUS.LSC.VSC.EDU
>
><LOCAL-DATA> indicates that data will be accessed from the local data
>directory.
>DATALOC -- done
Since this only tests whether or not a name lookup can be done on
currus.lsc.vsc.edu, we can really say anything yet.
>DSINFO G RTGRIDS
This tests whether or not your ADDE remote server is installed and the
dataset description for RTGRIDS exists. The dataset description is the
mapping between dataset/group and files that should compose the
dataset/group. It does not say whether or not the files exist, or can
be seen by applications.
> Dataset Names of Type: GRID in Group: RTGRIDS
>
>Name NumPos Content
>------------ ------ --------------------------------------
>ALL 620 Real-Time Grids
>AVN 80 Real-Time AVN Grids
>ECMWF 10 Real-Time ECMWF Grids
>ETA 120 Real-Time ETA Grids
>MDR 10 Real-Time MDR Grids
>MISC 10 Other Real-Time Grids
>MRF 100 Real-Time MRF Grids
>MRF-UW 2 MRF Grids in UW stream
>NGM 40 Real-Time NGM Grids
>NGM-UW 2 NGM Grids in UW stream
>RUC 80 Real-Time RUC Grids
>
>DSINFO -- done
So, the remote server is responding and the dataset description information
is readable. For reference, the dataset description is found in the
file RESOLV.SRV which will be located in the PATH of the user running
the remote ADDE server; this should be 'mcadde', and the most typical
(recommended) directory for it to be found in is ~mcidas/workdata.
Now, I try to see if I can list out actual GRID files that are said
to comprise one of the dataset/groups:
GRDLIST RTGRIDS/ALL.ALL FORM=FILE
GRDLIST: No Data Found
GRDLIST - done
GRDLIST failed, RC=2
So, we are at the exact same point as we were in our last exchange on
this matter.
This is telling us that the GRID files that are supposed to comprise any
of the dataset/groups are not found. This could be due to:
o there are no GRID files to be found at all
o the pointers to the GRID files (e.g., REDIRECTions) to the GRID files
are incorrect
If the XCD GRID decoding is turned on, then the latter possibility is most
likely. This can be tested by the 'mcidas' user by:
<login as 'mcidas'>
cd workdata
dmap.k GRID
If this finds the GRID files that are being created by XCD, then we know
that the setup for MCDATA and/or MCPATH in ~mcidas/.mcenv is incorrect.
If this can't find the GRID files, it means that either of the two
possibilities above are true.
To test to see if the GRID file decoding is turned on, one has to check
first in ~ldm/etc/pqact.conf. You should have an entry in this file
that looks like:
#########################################################################
#
# McIDAS-XCD section
#
DDPLUS|IDS ^.* PIPE
xcd_run DDS
HRS ^.* PIPE
xcd_run HRS
For GRID files, the 'HRS ^.* PIPE' entry is the one to pay attention
to. If this entry is commented out (a '#' character in column 1), it needs
to be uncommented, and a HUP needs to be sent to pqact.
If it is there and uncommented, then one must make sure that the GRID
decoding is actually turned on. This is done as the user 'mcidas':
<login as 'mcidas'>
cd workdata
decinfo.k LIST
Look for the entry for DMGRID. It should look like:
Processing Data Monitor: DMGRID is active
=========================================================================
Decoder Status Configuration File
----------------------------------------------------------------------
GRIB Active GRIBDEC.CFG
If the indication that it is inactive, it must be activated (i.e., turned
on/enabled):
decinfo.k SET DMGRID ACTIVE
If the GRID decoding is already active, then it means that the GRID files
still can't be found. This is _usually_ impossible since the location
for decoding the GRID files is controlled by REDIRECTions in the 'mcidas'
account. If, however, the REDIRECTions point to a non-existent file
system, then the GRID files won't be decoded, and they won't be found
by the 'dmap.k' invocation or by the remote ADDE server inquiries.
At this point, I would start worrying about:
o the REDIRECTions defined for the user 'mcidas'
o the read/write settings on the ~mcidas/workdata directory
o the read/write settings on the ~mcidas/data directory
o the read/write settings on the directory into which the GRID files
are to be decoded
>Okay, here is what we get.
>
>Group/Descriptor Type Format & Range RT Comment
>------------------------ ----- ------------------ -- --------------------
>RTGRIDS/ALL GRID GRID 5001-5620 Y Real-Time Grids
>RTGRIDS/AVN GRID GRID 5401-5480 Y Real-Time AVN Grids
>RTGRIDS/ECMWF GRID GRID 5251-5260 Y Real-Time ECMWF Grids
>RTGRIDS/ETA GRID GRID 5501-5620 Y Real-Time ETA Grids
>RTGRIDS/MDR GRID GRID 5301-5310 Y Real-Time MDR Grids
>RTGRIDS/MISC GRID GRID 5001-5010 Y Other Real-Time Grids
>RTGRIDS/MRF GRID GRID 5101-5200 Y Real-Time MRF Grids
>RTGRIDS/MRF-UW GRID GRID 101-102 MRF Grids in UW stream
>RTGRIDS/NGM GRID GRID 5051-5090 Y Real-Time NGM Grids
>RTGRIDS/NGM-UW GRID GRID 1-2 NGM Grids in UW stream
>RTGRIDS/RUC GRID GRID 5201-5280 Y Real-Time RUC Grids
>dsserve.k: done
Right, but this doesn't tell us anything except that the ADDE remote
server is setup and the dataset descriptions are in place. The files
are still not accessible.
>> When we get the remote ADDE access working to your machine, I can look
>> through the GRID files in the RTGRIDS/MRF dataset to see if they
>> look like what I suspect.
>
>Could you try this again, and suggest changes?
Since I can't see any of the GRID files for the datasets, I can't proceed.
If it would help move things along, I would be happy to login and poke
around. To do this, I would need logins as 'mcidas' and 'ldm' (so
I could change file/directory permissions if/when needed).
Tom
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.