>From: address@hidden
>Organization: St. Cloud State
>Keywords: 199904091934.NAA23884 ldm-mcidas
Alan,
>I also emailed Clint to check on the feedtype issue, but would
>not have known about the error you found.
It turns out that what I was seeing is an artifact. Clint is, in
fact, requesting everything from his upstream feed site. The listing
in our current operational status page is in error.
>What correction was needed in our pqact.conf regarding the
>profiler lines? I had looked at these, and thought they were ok.
The product codes listed for the hourly summary and 6-minute profiler
data were not correct. The hourly summary profiler data in the FSL2
feed is recognized in the McIDAS routing table as product U2; the
6-minute data is recognized as product U6. The product code U4 was
used for the hourly summary profiler data in PROFILER.CDF in the
Unidata-Wisconsin datastream. The entries I found used product codes
U2 and U4 as follows:
# Hourly summary
FSL2 ^FSL\.NetCDF\.NOAAnet\.windprofiler\.01hr\.(.*)\..*
PIPE -close
proftomd -d /var/data/mcidasd U4 WPRO 81 -v
# 6-minute
FSL2 ^FSL\.NetCDF\.NOAAnet\.windprofiler\.06min\.(.*)\..*
PIPE -close
proftomd -d /var/data/mcidasd U2 WPR6 91 -v
Also, the -v flag must come before the Ux Wxxx x1 arguments.
I just checked my ldm-mcidas distribution and find that _I_ am the
culprit for this mistake! I humbly apologize.
>Some other questions;
>
>I have tried to look at some skewT plots on waldo, with only
>minimal success. When requesting such a plot, I get an error
>message in the text window (i clicked on the keyboard icon)
>that states: invalid time, 2nd positional arg has invalid integer
>form 00.00.00; same message if 12z time is used.
OK, I am assuming that you are using my GUI since you mention the
keyboard icon. If the time was specified as "00.00.00" then
an error should be generated. In my old GUI interface to the SKEWT
command, I would regularize the time from 00 to 00:00:00 and
12 to 12:00:00. The UAPLOT command, however, does not (yet)
allow for times to be specified as HH:MM:SS (this is a design flaw/
bug from SSEC).
>It seemed to me that no matter what i tried, 00 or 12 imediately
>changes to 00:00:00 or 12:00:00 and the same problem repeated.
This is very strange indeed. I just started up a McIDAS session on
waldo as your 'mcidas' user with display pointed back here at Unidata
(so I should be running the exact same code as you). When I go to
plot Skew-t diagrams, everything is fine. To see if the problem lies
with a non-SkewT thermodynamic diagram, I marched through the selections
in the "Plot type" dropdown:
Skew T Log P
Stuve
Linear T vs P
Emagram
All of these thermodynamic diagrams plotted correctly and with no errors.
I next tried:
Hodograph
and it succeeded as well.
>I had success once when selecting F5 on the menu, which created
>a station idn table. Then, my first call for a skewT went ok.
>Later tries produced the error noted above. Any ideas?
OK, you are trying to put up the SkewT from the Fkey menu? To test
out the Fkey menu plots, I brought it up from the GUI (Misc dropdown
followed by selection of the Fkey Menu action). I then plotted a
SkewT from the Fkey menu with no problems.
The question is what I am doing differently from you? Are you running
the SkewT plotting from the 'mcidas' account? If not, it could have
something to do with your account's setup (but I don't know what right
at the moment).
>Also, are raw surface and raw upper air data available within
>mcidasx?
Absolutely. Try the following from the GUI:
o click on Display
o click on Data Lists
o click on Coded
o click on Surface
An interactive widget comes up asking you the station name, time, day, etc.
After filling in the information (or taking the default), another window
is popped open with the results from the ADDE application that was run
(SFCRPT in this case).
>I don't think so, since the decoders create files in
>MD format from the DDPLUS feed.
They also create Rapid Access Files that contain pointers into the
daily text "spool" files that are being saved in your /var/data/mcidas
directory. The spool files have sufficies of .XCD.
>I suppose the solution is to
>sort the raw DDPLUS products into the surface and upper air files,
>something like what was done for WXP if I recall.
This is not needed. McIDAS-X couple with XCD to give you very good
listing of coded (i.e. undecoded) and decoded datasets.
>I know they
>can be obtained from archive sites so it is not a big problem.
I think that there may be a couple of things going on here:
o a totally new way of doing things: XCD and ADDE applications
o perhaps running from an account where things are not setup fully
Which machine were you running your McIDAS-X session on? What version
of McIDAS-X was running there (it will be 7.503 if the answer is waldo)?
What account were you running from? If you are running from an account
other than 'mcidas', could you give me the login so I can experience
the problems first hand? Thanks...
>Thanks
Thanks for your kind words in the email to Dave regarding Glenn's death.
As you might imagine, we are all devastated here at Unidata. Glenn
will be missed on many levels by many, many people.
Tom
From address@hidden Wed May 5 17:27:10 1999
To: address@hidden
Subject: 19990505: profiler data at stc (cont.)
Alan,
>Thanks for the discussion on my options for viewing & saving
>data. I need to read on the ADDE routines.
There is a LOT of new capabilities in McIDAS. Hopefully, the GUI and
its follow up revisions will help people discover all that really
can be done with the package.
>Went back to try the profiler display choices again.
>
>Using point source data selection, using the drop down gui,
>hourly data, wind barbs at 1500m, a background map of the
>US plots, but no data points.
>
>Using Display, obs, Profiler Time Ht, the dropdown has no
>value or choices for plot day. No result.
>
>Using the FKey menu, choosing Wind Prof. Time Ht., a smaller
>gui appears. In the day slot, a 0 is listed, and then an
>error box appears, with "invalid day" message. When I type
>in 99125 for day, again get an error. If I somehow continue
>and choose plot, the graph screen appears looking ok, but
>no data points. The text/command window shows that proplt
>sems to run ok.
OK.
>Looked in /var/data/mcidas for MDXX008* and found MDXX0084 & 85.
>Each has a size of about 1.1 MB. also note that there were some
>files in 90's range for the 6 min data (I think).
Exactly correct. The hourly summary data is setup to be put into MD
files 81-90 and the 6-minute data is setup to be put into MD files
91-100.
>I have also looked
>at the log files, and found lines noting activity of the proftomd
>decoders with no errors listed.
I logged onto waldo to scope out the problem with profiler plotting
and see that, for some reason, both the routing and system key tables
are not being updated for either of the profiler data sets.
U2 FSL2 hourly wind profiler default MDXX0000 99125 2124 none 3
U6 FSL2 6-minute Wind profil default MDXX0000 99125 2305 none 3
The suspicious thing in the initial ROUTE LIST that I saw was that the
most recent MD file for both hourly summary and 6-minute data was
MDXX0000. Since this is an illegal McIDAS MD file name, something is
obviously wrong.
My first reaction after seeing this was to redo the routing table entries
for both of these products:
ROUTE ADD U2 MD X X CC=3 SYS=2041 2042 2043 "FSL2 hourly wind profiler
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
s U2 FSL2 hourly wind profiler default none none none 3
ROUTE: Done
ROUTE ADD U6 MD X X CC=3 SYS=2044 2045 2046 "FSL2 6-minute Wind profiler
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
s U6 FSL2 6-minute Wind profil default none none none 3
ROUTE: Done
ROUTE REL U2 U6
This did not correct the problem, however, as is evidenced by the routing
entries after both hourly and 6-minute data came in:
ROUTE LIST U2 U6
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
U2 FSL2 hourly wind profiler default MDXX0000 99125 2322 none 3
U6 FSL2 6-minute Wind profil default MDXX0000 99125 2318 none 3
ROUTE: Done
The strange thing about this is that I am running the exact same profiler
decoder on a Solaris x86 system here at Unidata, and I am not seeing this
problem.
>so, that is how I finished up.
I will find out what is going on on your system, fix it, and then let you
know what I did.
>scouring seems to be going ok, with
>the total usage on the file system that holds ldm, mcidas and data
>staying at about 2 GB out of 7GB avail.
Sounds good. The next thing is to think about what model data you want
to ingest and decode. The model data can suck up a LOT of disk space
in a hurry.
Tom
>From address@hidden Wed May 5 20:27:21 1999
To: address@hidden
Subject: 19990504: profiler (cont.)
Alan,
I found and fixed the problem with the FSL2 wind profiler decoder (it
was indexing in an array related to the routing table using Fortran's
1-base convention when it should have been using the 0-base convention
of C; the array was then getting byte flipped to convert the
information to be big-endian). This never showed up before since most
users are are on running on big-endian machines.
I checked your machine a couple of minutes ago and see that both the
routing and system key tables are now being updated correctly:
ROUTE LIST U2 U6
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
U2 FSL2 hourly wind profiler default MDXX0086 99126 222 none 3
U6 FSL2 6-minute Wind profil default MDXX0096 99126 218 none 3
ROUTE: Done
SYSVAL LIST 2041 2046
SYSKEY Word Value
----------- -----------
2041 = 86
2042 = 2
2043 = 1999126
2044 = 96
2045 = 20600
2046 = 1999126
SYSVAL: Done
I then did a plot of both hourly summary and 6-minute profiler data from
both the GUI and the Fkey menu and had no problems.
Sorry for the foul-ups.
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.