>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.