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.
Donna, It turns out that sfmod uses the sf_atim call to add the new time to the output file, and this routine cannot be used with a ship file ifthe time does not already exist in the output file. The easiest way around this is to use sflist to output the data to a text file using SFPARM=slat;slon;dset. Then, used sfedit to read the data into the new file (you can use TIMSTN=1/9999 in sfcfil...the times/stns are all intermixed in the ship file). THis will be slower than sfmod, but does work for me. Steve Chiswell Unidata User Support >From: address@hidden >Organization: UCAR/Unidata >Keywords: 200007062030.e66KU1T26233 >Steve, > >Yes, these are all ship files. I have ftped the following files > >99061000_pir.sfc (sample AWC file) >pireps.pack >sfcfil.nts (sfcfil parameters) > >Donna Tucker http://chinook.phsx.ukans.edu/tucker.html >address@hidden Department of Physics and Astronomy >(785) 864-4738 (new area code!) University of Kansas >(785) 864-5262 (fax) Lawrence, KS 66045-2151 > > > > >----- Begin Included Message ----- > >From address@hidden Thu Jul 6 15:13:23 2000 >To: address@hidden >cc: address@hidden >Subject: 20000706: gempak sfmod command >Date: Thu, 06 Jul 2000 14:14:23 -0600 >From: Unidata Support <address@hidden> > > >Donna, > >Its ok to have several reports from the same "station" in a ship file >(presumably the aircraft is at a different location 10 minutes later >when that report is made). Your sfoutf extension sounds like a ship >file...so I'm presuming that both are...but I probably need to look >at ne of your input files: 99061000_pir.sfc and see the >commands you used to create the surface file in sfcfil. > >If you could ftp the input file to ~gbuddy/incoming, I'll take a look. > >Steve Chiswell >Unidata User Support > > > >>From: address@hidden >>Organization: UCAR/Unidata >>Keywords: 200007061910.e66JAaT23989 > >>We have a large number of GEMPAK files with pilot reports which we got from >>the Aviation Weather Center. I can send you a sample file if you would like >>to see it. We would like to combine these into several >>large files so they are not as cumbersome to work with. Our strategy is >>to create a new file with SFCFIL and move data into it with SFMOD. We >>created the new file using a packing file I made up based on what information >>I could gather about the data from AWC. I can send you the packing file if >>you would like to see it. When we run SFMOD we get >> >> SFFILE Surface data file 99061000_pir.sfc >> SFOUTF Output surface file nturb.shp >> DATTIM Date/time /00 >> AREA Data area dset >> Parameters requested: SFFILE,SFOUTF,DATTIM,AREA. >> GEMPAK-SFMOD>r >> [SFMOD -4] Time 990610/0000 cannot be added. >> Parameters requested: SFFILE,SFOUTF,DATTIM,AREA. >> GEMPAK-SFMOD> >> >>Normally, when I see this error message I assume the output file is full but >>since this is the first file we are processing, that cannot be the case. No >>data are actually written to the output file. The >>files from AWC contain a number of instances where the same station reports >>several times an hour (e.g. a pilot reports moderate turbulence and 10 >>minutes later reports severe turbulence - the AWC GEMPAK files have these >>reports listed at the same time). I wonder if this is screwing up the >>process or if it is something else. Any ideas on what could be wrong or >>what we can do to work around it? >> >>Donna Tucker http://chinook.phsx.ukans.edu/tucker.html >>address@hidden Department of Physics and Astronomy >>(785) 864-4738 (new area code!) University of Kansas >>(785) 864-5262 (fax) Lawrence, KS 66045-2151 > >> >> > > > >----- End Included Message ----- > >