[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #XGO-813982]: SFMOD cannot save new time in SFOUTF

> Hi Steve,
> 
> For unknown reason(s), SFMOD still cannot add new times in SFOUTF even
> though the settings are within limits.
> 
> Total # of stations = 4516
> Total # of times    =  200
> 

Kwan,

When you create the surface file either through sfcfil or a decoder such as 
dcmetr,
you have to specify the number of "Additional stations" in addition to
the stations in the STNFIL. GDGSFC will interpolate to existing station 
locations
already in your file. If you are trying to add new station locations to your
file with SFMOD, there must be room for additional stations (and remember that
a decoder would be adding stations to the data set as they were encuntered in 
the data set).
since you are using the NCEP distribution with about 4000 stations in 
sfstns.tbl, it sounds like your
4516 stations is about the same as the default dcmetr to allow room for 500 
additional stations.
Check the number of stations (even those with SLAT and SLON = -9999) in your 
fle, and 
determine if you have to either add extra room for your SFMOD stns, or 
eliminate 
those missing lat/lon stations.

Since you are within NOAA and getting your distribution from NCEP, you may be 
able to
get help from NCO to directly look at what you have on your system since I 
cannot
from outside NOAA.

Steve Chiswell
Unidata User Support






> Again, only GDGSFC is able to add new times in SFOUTF with no problems.
> 
> Kwan
> 
> ----- Original Message -----
> From: Unidata GEMPAK Support <address@hidden>
> Date: Monday, July 9, 2007 12:22 pm
> Subject: [GEMPAK #XGO-813982]: SFMOD cannot save new time in SFOUTF
> 
> > > 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
> > observationsat 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 <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
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: XGO-813982
Department: Support GEMPAK
Priority: Emergency
Status: Closed