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: Mark Tucker <address@hidden> >Organization: Lyndon State >Keywords: 200011021724.eA2HOE400457 McIDAS-X 7.6 SFCPLOT Mark, >We've found some strange behavior with the SFCPLOT command and hoped that >you could possibly shed some light on how to fix it. Here's some examples >of what we have tried and the results: > >SFCPLOT GUS OLAY LATEST INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 >SF=YES PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO >SFCPLOT: Dataset contains more than one schema The error indication suggests that at least one of the files in the RTPTSRC/SFCHOURLY dataset is somehow damaged or contains a schema different than one or more of the other files in the same dataset. At this point, I would list out the file information from the dataset with: PTLIST RTPTSRC/SFCHOURLY.ALL FORM=FILE and see if the schema type in the file list varies at all. I just tried this while pointing to your server and did not see the problem: DATALOC ADD RTPTSRC cirrus.lsc.vsc.edu PTLIST RTPTSRC/SFCHOURLY.ALL FORM=FILE Pos Description Schema NRows NCols Date ------ -------------------------------- ------ ----- ----- ------- 5 SAO/METAR data for 31 OCT 2000 ISFC 72 4500 2000305 6 SAO/METAR data for 01 NOV 2000 ISFC 72 4500 2000306 7 SAO/METAR data for 02 NOV 2000 ISFC 72 4500 2000307 8 SAO/METAR data for 03 NOV 2000 ISFC 72 4500 2000308 PTLIST: Done While pointing at cirrus, I ran the invocation you list in a 7.613 McIDAS-X session and got the correct plot of wind GUSts: SF 12 EG MAP USA SFCPLOT GUS OLAY LATEST INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 SF=YES PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO Is it possible that there happened to be a bad surface file in the RTPTSRC/SFCHOURLY dataset when you ran this program and got the error and that file is now gone? Is cirrus the ADDE server you are running from? >SFCPLOT GUS OLAY LATEST INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 >SF=YES PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO DATASET=RTPTSRC/SFCHOURLY.7 >PTDISP: No data found matching search conditions This invocation worked for me also: EG LEV=3;SFCPLOT GUS OLAY LATEST INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 SF=YES PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO DATASET=RTPTSRC/SFCHOURLY.7 > This has the same results regardless of the (valid) position of > RTPTSRC/SFCHOURLY > >SFCPLOT GUS OLAY 12 INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 SF=YES >PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO >SFCPLOT: Dataset contains more than one schema >SFCPLOT - Done >SFCPLOT failed, rc=1 This really does look like there was a bad datafile in the RTPTSRC/SFCHOURLY dataset that you were pointing at. Again, what is/was the ADDE server when you ran this invocation? To check, run: DATALOC LIST on the machine on which you encountered the problem. >SFCPLOT GUS OLAY 12 INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 SF=YES >PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO DATASET=RTPTSRC/SFCHOURLY >SFCPLOT - Done > > It works!! This worked for me also. >SFCPLOT GUS OLAY 12 INT=00:30 DAY=2000307 MODE=X GRIDF=132 GRA=12 SF=YES >PRO=CONF OUT=PLO GU=GRAPHIC BLANK=NO DATASET=RTPTSRC/SFCHOURLY.7 >SFCPLOT - Done > > It works!! (for any valid position) This invocation worked for me as well. >Without specifying the dataset we get a schema error and the command >fails. At this point, I would appreciate to see the output of: DATALOC LIST PTLIST RTPTSRC/SFCHOURLY.ALL FORM=FILE >In addition, the LATEST parameter does not seem to work. LATEST was introduced for use in the non-ADDE access surface plotting routine. It was kept for backward compatibility, but it does not necessarily give you back a plot of the latest avaiable data for the day. >The data >does exist and the last two successful examples I've listed behave as one >would expect. The problem for me is that I was unable to reproduce your failure while pointing my 7.613 session at cirrus. I need to know if you were getting the results while pointing to a different machine. Tom