This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: "Patrick O'Reilly" <address@hidden> >Organization: UNI >Keywords: 200111271954.fARJsiN04944 McIDAS Patrick, >In trying to plot the previous day's upper air / surface data, it seems >McIDAS will only plot the current day's data, even when the date and >time are explicitly set. I verified that I tried putting up surface plots from yesterday: SF 1 ERASE SFCPLOT WINDB USACONF 12 DAY=2001330 This indeed put up a plot from 12Z today, DAY 2001331. So, I tried specifying the DAY differently on the command line: SFCPLOT WINDB USACONF 12 2001330 This time, the correct plot was made. I then tried plotting upper air data and got similar results: SF 2 ERASE RAOBPLOT Z 500 USACONF 12 DAY=2001330 does not give the correct day's data, but: SF 2 ERASE RAOBPLOT Z 500 USACONF 12 2001330 does. This indicates that there _are_ bugs in SFCPLOT's and RAOBPLOT's use of the DAY= keyword. Now, since the MCGUI specifies the DAY using the DAY= keyword, it will also show the problem. >I even tried in command mode (not the McGUI) >to get 26 November 12Z upperair/surface data to plot, but it only plots >12Z 27 November. Compare the command syntax you used for SFCPLOT/RAOBPLOT with what I listed above. I think you will find that the second form works and the first does't (the on using DAY= syntax). >I checked the files and have: > >MDXX0011 >MDXX0020 >MDXX0021 >MDXX0030 >which my LSSERVE.BAT say are mandatory and significant level upperair >files. That is correct. >So the data seems to be there. Any ideas why I can't get "old" >data to plot? You discovered a bug. >I tried a couple different machines too, mine here, >adde.ucar.edu, and papagayo.unl.edu. Same result. Help would be >appreciated. I will dig into the source code for the modules that are not working; develop appropriate fixes; and then let you know how to download the revised source and build and install new executables. >Thanks! Thanks for finding the bug. I am suprised that I didn't see this one before! Just goes to show that I mostly look at current data!! Tom