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.
Chris, Quick question here... Did you need to copy your dcnmos into ~ldm/decoders or somewhere to update your runnig copy- just to check to make sure you aren't still using the old copy. The first time should be 6Z or 18Z. Steve Chiswell >From: address@hidden (Chris Hennon) >Organization: UCAR/Unidata >Keywords: 200008050034.e750YfT20302 >Steve - > >I may be screwing something up, but I installed your patch and I'm getting >the same error. When I run sflist on the nmos file, I get: > > SFFILE Surface data file 2000080200_nmos.gem > AREA Data area dset > DATTIM Date/time list > SFPARM Surface parameter list text > OUTPUT Output device/filename t > IDNTYP STNM or STID STID > Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP. > GEMPAK-SFLIST>sffile = 2000080412_nmos.gem > GEMPAK-SFLIST>r > > List of times: > > 000804/1200 000804/1800 000804/2100 000805/0000 > 000805/0300 000805/0600 000805/0900 000805/1200 > 000805/1500 000805/1800 000805/2100 000806/0000 > 000806/0300 000806/0600 000806/0900 000806/1200 > 000806/1500 000806/1800 000806/2100 000807/0000 > > >Enter a time or type EXIT: > >Should the first time still be the analysis time? Thanks. > >Chris > > >On Mon, 31 Jul 2000, Unidata Support wrote: > >> >> Chris, >> >> The reason that you are having trouble with dattim=all is that >> the TEXT is being stored in the file as the initial time, whereas the foreca > st >> data start at the 6 hour offset. >> >> So, when oabsfc gets the list of times in the file, the first time has no >> data (only the TEXT of the mos bulletin which you can list out with sflist). >> In the new release of GEMPAK, this has been changed so that the TEXT is stor > ed >> with the data of the FIRST time- which is 6 or 18Z. >> >> You can see this, if you use sflist with dattim=list. The list of times >> currently will have the bulletin time (0 or 12Z with only the TEXT sfparm). >> You can use sfdelt to delete this time out of the file if you desire. >> Then the gridding will work for dattim=all. I give you that solution if you >> need to use any old data you have already decoded. >> >> To fix this in your copy of dcnmos to match the way the data will be stored > in the >> new version, I have posted a patch to $GEMPAKHOME/source/programs/dc/dcnmos/ > dcnmdc.f >> in ~gbuddy/nawips-5.4/patches/. >> >> You can download the dcnmdc.f into your $GEMPAKHOME/source/programs/dc/dcnmo > s/ >> directory, then rebuild your dcnmos with: >> >> cd $GEMPAKHOME/source/programs/dc/dcnmos/ >> make clean >> make all >> make install >> make clean >> >> Steve Chiswell >> Unidata User Support >> >> >> >> >> >From: address@hidden (Chris Hennon) >> >Organization: UCAR/Unidata >> >Keywords: 200007282124.e6SLOqT13406 >> >> >Steve - >> > >> >I put the file 'chris_osu.tar' in the incoming directory. >> > >> >Chris >> > >> >================================================ >> >| Chris Hennon Ohio State University | >> >| Tropical Meteorology address@hidden | >> >| | >> >| Dept of Geography Office: 1155 Derby Hall | >> >| 1036 Derby Hall Phone : (614) 292-2704 | >> >| Columbus, OH 43210 Fax : (614) 292-6213 | >> >================================================ >> > >> >On Thu, 27 Jul 2000, Unidata Support wrote: >> > >> >> >> >> Chris, >> >> >> >> This is strange. I ran this on SOlaris which I believe you are too, and e > ver >> > ything >> >> worked. Normally, with that error, I would suspect that the station table > fo >> > r >> >> the lat/lon information for all the decoded surface data was missing, so > tha >> > t >> >> the too few stations wouldactually be true....but, since it works for a s > ing >> > le time, >> >> then that means that there should be lat/lon info in it. >> >> >> >> Can you ftp to ~gbuddy/incomin your ngm file, the grid file you are attem > pti >> > ng >> >> to write to, and your oabsfc executable? >> >> >> >> Thanks, >> >> >> >> Steve Chiswell >> >> Unidata User Support >> >> >> >> >> >> >From: address@hidden (Chris Hennon) >> >> >Organization: UCAR/Unidata >> >> >Keywords: 200007271435.e6REZQT17298 >> >> >> >> >Steve - >> >> > >> >> >My input to OABSFC looks like: >> >> > >> >> > GEMPAK-OABSFC>l >> >> > SFFILE = 2000072700_nmos.gem >> >> > GDFILE = $HOME/grids/ngmmos.grd >> >> > SFPARM = sknt >> >> > DATTIM = all >> >> > DTAAREA = dset >> >> > GUESS = >> >> > GAMMA = 0.3 >> >> > SEARCH = 20 >> >> > NPASS = 2 >> >> > >> >> >When I run it like that, I get back: >> >> > >> >> >GEMPAK-OABSFC>r >> >> > [OABSFC 6] WARNING: Area is not DATA area in file. >> >> > [OABSFC -7] There are too few stations in data subset area. >> >> > [OABSFC 9] No data from 2000072700_nmos.gem will be used. >> >> > [OABSFC -9] No valid parameters have been entered. >> >> > Parameters requested: SFFILE,GDFILE,SFPARM,DATTIM,DTAAREA,GUESS,GAMMA, >> >> > SEARCH,NPASS. >> >> > >> >> >When I change dattim to 000727/06, it runs normally and performs the >> >> >analysis. Sorry I wasn't as specific last time. >> >> > >> >> >Chris >> >> > >> >> >================================================ >> >> >| Chris Hennon Ohio State University | >> >> >| Tropical Meteorology address@hidden | >> >> >| | >> >> >| Dept of Geography Office: 1155 Derby Hall | >> >> >| 1036 Derby Hall Phone : (614) 292-2704 | >> >> >| Columbus, OH 43210 Fax : (614) 292-6213 | >> >> >================================================ >> >> > >> >> >> >> ************************************************************************* > *** >> >> Unidata User Support UCAR Unidata Prog > ram >> >> (303)497-8644 P.O. Box 3 > 000 >> >> address@hidden Boulder, CO 80 > 307 >> >> ------------------------------------------------------------------------- > --- >> >> Unidata WWW Service http://www.unidata.ucar.edu/ > >> >> ************************************************************************* > *** >> >> >> > >> >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** >> >