IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Ignore:
Timestamp:
Jan 31, 2013, 12:21:01 PM (14 years ago)
Author:
eugene
Message:

adding notes

File:
1 edited

Legend:

Unmodified
Added
Removed

  • branches/eam_branches/ipp-20121219/ippToPsps/doc/upgrade.txt

    r35072 r35075  
     1
     22012.01.29
     3
     4I'm trying to re-work the operational model.  First, make sure we have correct names for concepts:
     5
     6* region : unit of spatial partition within DVO : a single region (eg,
     7  n0000/0020.01) has bounds of lines of constant RA & DEC, and is
     8  associated with 4 files containing dvo database tables for that part
     9  of the sky.
     10
     11* batch : the unit of data sent to psps (1 camera-stage smf, 1 stack-stack cmf, 1 region-worth for obj, 1 init batch)
     12
     13* box: an area on the sky for which we are generating / have generated
     14  batches.
     15
     16* config : an area on the sky for which we are generating batches in boxes
     17  XXX : this name is somewhat confused & overloaded in ipptopsps -- it
     18  encompases both the static configuration information and the
     19  information about a processing chunk.
     20
     21* client : an instance of an ipptopsps running proccess
     22
     23Example sequence:
     24
     25* ippjython queue.py edit : create a new 'config'
     26
    127
    2282012.01.27
    … …  
    733
    834  I need to change the way ippToPsps works at the operational level.
    9   currently, the concept is that a 'config' is once and the boundaries
    10   / aspect changed to trigger different processing.  this is poor
    11   because it leaves no tracking, and it means the current situation
    12   change change too easily.  in addition, the rules for triggering dvo
    13   ingest are not completely clear, and probably not enforceable from
    14   within ippToPsps
     35  currently, the concept is that a 'config' is created once and the
     36  boundaries / aspect changed to trigger different processing.  this
     37  is poor because it leaves no tracking, and it means the current
     38  situation can change too easily.  in addition, the rules for
     39  triggering dvo ingest are not completely explicit, and probably not
     40  enforceable from within ippToPsps for parallel DVOs
    1541
    1642  alternatively, I'd like to have the following sequence:
Note: See TracChangeset for help on using the changeset viewer.