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

Hi Ken,

re:
> 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.

re:
> [muser@wx-mcidas-bvldev01 data]$ skl.k
> *** SCHEDULER IS ON  ***          MESSAGE DEVICE IS: N
> T#  ID  XS NEXT EXECUTN # REM INTERVAL  TOL  NAME PROJ COMMAND TEXT...
> -- ---- -- ------------ ----- -------- ----- ---- ---- ------------
> .
> .
> .
> 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
> --END OF LIST

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 
latitudnal
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.

Cheers,

Tom
--
****************************************************************************
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