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

Re: 20010509: dcacft update

Scott,

I uploaded afgmpk.f and afdupe.f to the upc account on hp1.
af_gmpk will call af_dupe to check for a duplicate location
(same id, time, lat, lon, and elevation(flight level) ) in
the output file. If the location is a duplicate, the data isn't
written in af_gmpk.

The afdupe.f routine calls sfuare.f which forces the need to link gplt.a
(for the GQBND call from the gemlib/lc/lcabnd.f routine- even though 
it isn't needed for this single station id search). Do you consider 
this a problem?

The same routine would also be useful for mawgem (dcmsfc). So, in that case
it might be useful to move the routine to dcdupe.f. The primary thing here
with ship format files is the dc/dctmst.f routine won't work where the
same time and ID may exist at different locations (and the sf_fstn call is not
for time/stations intermixed).

Let me know if you have any questions/concerns.

Thanks,

Steve

------------------------------------------------

On Wed, 9 May 2001, Scott Jacobs wrote:

> Steve,
> 
> There is no reason not to make the fix. I talked with Duane, and to the
> best of her recollection, we did not add the check because we did not
> think to add it. We got the main parts of the decoder from the NCEP
> decoder group and they check for duplicates later in their own
> processing. We are winding up development for patch D, if you send us the
> fix, we will try to add it in, but I cannot promise anything.
> 
> Scott
> 
> 
> Steve Chiswell wrote:
> 
> > Scott,
> >
> > I was looking at the dcacft decoded files and noticed that the af_gmpk
> > routine doesn't make any attempt to detect duplicate reports. As
> > a result, I'm seeing 4+ reports for the same time/location/platform
> > in the decoded file.
> >
> > In my other ship format surface file decoders (lightning, acars etc)
> > I generally assume that if the same station ID, time, and
> > lat/lon exist (slat & slon +/- .01 degrees or so), then I don't create
> > a new entry in the file- but update any fields as necessary. The check
> > is a little slower than for stansard surface files, but it will
> > cut down the overall file size too.
> >
> > My question for you is whether you know of any reason not to do this
> > for this decoder. Otherwise, I'll make that change and send it
> > back to you.
> >
> > Steve
> 


Steve Chiswell
Unidata User Support