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

[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 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