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.
> Hi Steve, > > When I sent my last email, I still didn't realize I asked for 800 > times! (I was confused with # of stations. Actually I DID want that > many times, since I have been doing a bias calulation of the PMSL for > each station in North America.) After I re-created the file with only > 200 times, that error no longer showed up. > > With this in mind, a question comes to me. If I keep adding up more > times to the file and reach 200, I will want to delete the "first" time > in the file to make room for the latest data. I will need to use > SFDELT. I know that LAST can be used to specify the latest time. But > is there one for the "first" time? > > Kwan Kwan, Yes, you can set "DATTIM=first" in SFMOD and delete the first time in the data file. set AREA=dset to delete all observations at that time. Steve Chiswell Unidata User Support > > ----- Original Message ----- > From: Unidata GEMPAK Support <address@hidden> > Date: Friday, July 6, 2007 5:03 pm > Subject: [GEMPAK #XGO-813982]: SFMOD cannot save new time in SFOUTF > > > Kwan, > > > > Your TIMSTN=800/250 line is actually telling the file to allow > > space > > for 800 times and 250 additional stations. > > > > However, the GEMPAK distribution as delivered by NCEP to > > the national centers has a limit of 200 as the maxmimum > > number of times, and 4800 maximum number of stations (see > > "grep LLMXTM $GEMPAK/include/*" and "grep LLSTFL $GEMPAK/include/*"). > > The file you are creating is invalid, and you will not be able to > > access more than 200 times, and I cannot guarantee that the > > data will not be corrupt. > > > > As I said before, I define the number of headers for my > > distribution > > as 300 times and 29,700 stations, but even that is not compatible with > > your 800 time size you are using. > > > > Steve Chiswell > > Unidata User Support > > > > > > > > > Hi Steve, > > > > > > I've just realized that I have not described the problem > > exactly. I get > > > > > > [TI 2] The time ...... is not found in the data set. > > > [TI -2] No valid times entered. > > > > > > from SFMOD only when I specify a new time in DATOUT that is not > > yet in > > > SFOUTF. If DATTIM is set and DATOUT is empty, SFMOD is able to copy > > > the data even though the time is not yet in SFOUTF. The purpose of > > > DATOUT is, as you know, to change the time of the data. But it > > > apparently fails if DATOUT != DATTIM and DATOUT is not in SFOUTF. > > > > > > For your info, I created the surface file from SFCFIL using these: > > > > > > SFOUTF = $HOME/temp/pmsl-bias.metar > > > SFPRMF = PMSL;POBJ;DPSL > > > STNFIL = SFSTNS.TBL > > > SHIPFL = NO > > > TIMSTN = 800/250 > > > SFFSRC = METR > > > > > > I have access to 5.10.3 since I am now working at > > Hydrometeorological> Prediction Center, part of NOAA NCEP. > > > > > > Kwan > > > > > > ----- Original Message ----- > > > From: Unidata GEMPAK Support <address@hidden> > > > Date: Thursday, July 5, 2007 10:23 pm > > > Subject: [GEMPAK #XGO-813982]: SFMOD cannot save new time in SFOUTF > > > > > > > > Hi Steve, > > > > > > > > > > I know that the pre-defined MAXTIM=250 has not been reached. > > > > There are > > > > > 150 times listed. In addition, my script also uses GDGSFC to > > > > > interploate grid data into the surface file. It has been > > adding new > > > > > times with no problems, but not so with SFMOD. > > > > > > > > > > Kwan > > > > > > > > Kwan, > > > > > > > > That would depend on whose GEMPAK distribution you are using and > > > > how your surface file was created. If you are using NCEP's 5.10.3 > > > > distribution, then you have > > > > a limit of 200 times in a file, and what TIMSTN was set if you > > > > created the file using SFCFIL. > > > > > > > > The Unidata distribution is compiled for up to 300 times in a > > > > file, but I have only released > > > > 5.10.2, so if you did have 5.10.3, it didn't come from me. > > > > > > > > Can you provide details as to where you obtained the distribution, > > > > and how the surface file > > > > is created that you are attempting to add the stations to? > > > > > > > > Steve Chiswell > > > > Unidata User Support > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: Unidata GEMPAK Support <address@hidden> > > > > > Date: Thursday, July 5, 2007 6:14 pm > > > > > Subject: [GEMPAK #XGO-813982]: SFMOD cannot save new time in > > SFOUTF> > > > > > > > > Kwan, > > > > > > > > > > > > The maximum number of times in a surface file is defined at > > > > > > creation time. > > > > > > This is either done by the decoder (such as dcmetr) or by > > SFCFIL.> > > > > > > > > > The decoder dcmetr generally creates a file using "-m 72" > > for a > > > > > > maximum of 72 > > > > > > times in a file (eg 20 minute bins for 24 hours). If you are > > > > > > trying to SFMOD > > > > > > data to a surface file where the maximum number of times > > already> > > > exists,then a new time cannot be added. If that is > > the case, you > > > > > > should create a new > > > > > > file using SFCFIL and specify a maximum number of times > > (up to 300 > > > > > > allowed maximum > > > > > > at compile time), and then move both data sets to the new > > file.> > > > > > > > > > You can determine what times already exist in your file in > > > > SFLIST by > > > > > > setting DATTIM=list. > > > > > > > > > > > > Steve Chiswell > > > > > > Unidata User Support > > > > > > > > > > > > > > > > > > > Hi Steve, > > > > > > > > > > > > > > I am attempting to copy some surface data from one file to > > > > another> > > using SFMOD. However, if a time specified in DATOUT > > > > is not > > > > > > already in > > > > > > > SFOUTF, the program terminates with a message saying > > that the > > > > > > time is > > > > > > > not in SFOUTF. I checked the help, and it said that it's > > > > > > supposed to > > > > > > > add data to SFOUTF even if it is a new time. There is > > enough> > > > room in > > > > > > > my SFOUTF. Did I do something wrong? Or is it a bug in > > > > this SFMOD? > > > > > > > I am using GEMPAK 5.10.3. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Kwan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ticket Details > > > > > > =================== > > > > > > Ticket ID: XGO-813982 > > > > > > Department: Support GEMPAK > > > > > > Priority: Normal > > > > > > Status: Closed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ticket Details > > > > =================== > > > > Ticket ID: XGO-813982 > > > > Department: Support GEMPAK > > > > Priority: Normal > > > > Status: Closed > > > > > > > > > > > > > > > > > > > > Ticket Details > > =================== > > Ticket ID: XGO-813982 > > Department: Support GEMPAK > > Priority: Normal > > Status: Closed > > > > > > Ticket Details =================== Ticket ID: XGO-813982 Department: Support GEMPAK Priority: Normal Status: Closed