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

[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