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

[McIDAS #GEJ-957244]: McIDAS GOES-South Problem

Hi Ken,

> A point of clarification,  for this current project we are attempting to
> inject the GOES-South (GOES-12) data into our legacy
> satellite processing system, not the applications Fred developed for us last
> year (although these concerns do impact his stuff too).
> Our legacy system relies on the McIDAS-X workstations scheduler to do the
> data ingesting and we rely on it to make sure we
> only ingest the most current data (that we haven't already gotten, we don't
> ever want to get any image more than once) from each SDI we connect to.
> Our software doesn't do much time checking, whatever is received via the
> McIDAS scheduler is processed, when compositing images together it tries
> to find a matching time for each data set.  So, the obvious problem is once
> the UCAR SDI has future data our scheduler won't ingest any data until UCAR's
> SDI has purged the future data or time passes the future file.

I understand.

> address@hidden data]$ skl.k
> -- ---- -- ------------ ----- -------- ----- ---- ---- ------------
> .
> .
> .
> 1  650    12124 224200  MANY      500   400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES
> 1  651    12124 224200  MANY      500   400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES
> 1  652  S 12111 132700  MANY      500   400 MXWX 4416 IMGCOPY SOUTH/SH.0 GOES

The situation is now clear to me: the IMGCOPY invocations always grab the
"most recent" image from the server.  The logic in the server is very simple:
get a list of all images; sort the list by nominal image time; send back the
one that has the newest time.  This is a nice feature of ADDE image servers,
but it is error prone in the face of image times that are in the future.

A thought: the invocation of IMGCOPY could be replace by the invocation
of a McBASI script that could do simple checking of times that are in the
future.  The only reason I keep returning to the point of doing checking on the
receiving end is I want users to benefit by the data access we make freely
available, not be hampered by it.

Just so you know that we are taking this problem seriously:

This past weekend we checked cabling, connections, and everything else we could
think of in addition to moving the ingest to a dish that can track the 
movement of GOES-12. There is not much more we can do to clean-up the
data ingest given our constraints of dish location (between two buildings
looking over the top of one the buildings and a tree that partially obstructs
the view) and no funding to move the dish to a better location.


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: GEJ-957244
Department: Support McIDAS
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.