UPDATE LIST OF OmegaCAM ACTION ITEMS   as of   11/1/2001
========================================================

Next meeting 18/1/2002 13:30

+ Means action closed

STATUS/NEWS

   - There is  a problem with the contract signing ceremony date. :-[ 
   - Weekly ASTRO-WISE telecons started Thursday, 10/1/2001. :-) 
   - We need a list of (lab) testdata that we will be using.
   - Gert Sikkema was present 4/1/2001 at the Kapteyn Institute for the telecon.
   - Python 2.2 & mxDateTime 2.0.3 are released.
   - OPTICON Interoperability Working Group meeting, January 28/29th, 2002,
     which Erik will attend.
   - HEP Database Project Workshop, January 29/31st, 2002, which Edwin and
     Danny might attend.
   - INT observation time at La Palma granted for OmegaCAM. end February and end  July Who will observe?
   - Ewout Helmich to look at the astrometry generated by the pipeline.

   - OmegaCAM contract signing ceremony will take place on March 13, 2002 in
     Groningen. ????
   - ASTRO-WISE kick-off meeting to be held March 14, 2002 in Groningen.
   - ASTRO-WISE jobs advertised. Deadline 1 February 2002.
   - We expect to see ghosts at 26th magnitude for 10th magnitude stars
     9 arcsec from these stars. Koen will provide documentation.
   

AI FOR ALL

    - SKELSTATUS IS NOW COMPLETELY UPDATED AND LISTS FOR EACH RECIPY THE CURRENTLY DEFINED FIRST ACTION
    - KOR: PROVIDE REPORT ON Oracle 9I evaluation with sourcelist/assocate before CERN workshop <25/January 2002
    - DANNY: EVALUATE CALIBRATION DB AND BINDING IN ORACLE 9i < 25 January 2002

- Contact Koen when interested in giving a presentation or presenting a
     poster at the July 2002 "Survey and Other Telescope Technologies and
     Discoveries" SPIE meeting. (Deadline for abstract 15/1/2002)
   - Read VLT-MAN-ESO-19500-1619 "Data Flow Pipeline and Quality Control Users
     Manual" (at least sent by e-mail 20 Apr 2000, in case you can't find it).

KGB
   | Oracle9i Spatial indexing experiments are underway.
   | Oracle9i remote database management is possible.
   | Graceplot can be used non-interactively, e.g. in batch processing.
   -Associate test met _echte_ data. (AXAF/Jelte test data + pipeline test data)
   Oracle9i:
      -assess Associate type of operations  (since 4/9)
      -assess C++ binding (since 4/9)
   -Define GUI perspective. (since 22/10)
   -Investigate use of graceplot for Python plotting (since 29/10).
   - Create plotting module and test with PSF plots (with RR). (since 2/11)
   - Investigate high speed connection to European network. (since 11/1/2)

ED
   - Appropriate projection facilities for Astro-Wise inauguration. (since 2/11)
   - Investigate high speed connection to European network. (since 11/1/2)
   
DB
   Master of all DIDs
      - prepare update DID delivery. Write Stefan (Michelle?) for delivery. (since 4/9)   
   - New template parameter/header item for 2 lamp circuits (check with Andrea). (since 6/11)
     Check out the situation with headers/DID for TWO lamp circuit.
     There will be two circuits, odd and even; every time a lamp brakes down, and very 3 months
     all lamps of the cicuit will be exchanged. After change the lampsidentfyer in the header will be          updated with a new serail number (2 higher than the previous). make sure we have the right header items for this.
   -Investigate Python/Objectivity solution
   Oracle9i:
      -review Federation aspects (Alliance, RAC, transportable tablespaces, clustering, parallel server)
      -write letter for info about Alliance to Oracle person (since 9/10)
   - Use `qc1log' in QCLog stub. (since 2/11)
   - Create sample calibration db and implement Oracle9i binding. (since 7/12)
-
   - Check out pCFITSIO & EIS LDAC methods using pFITSIO. (since 4/1/2)
   - What is the proper keyword for the exposure time? (since 11/1/2)

RR
   master of image pipeline
       - Implement CalFile & Recipe for presolution (since 2/11)
   - Master of all templates
   - Create plotting module and test with PSF plots (with KGB). (since 2/11)
   - Implement Eclipse python interface for average with rejection. (since 2/11)
   - Update recipes for 2 lamp circuits. (since 6/11)
   - Check for conflict in analysis of req571 between focus (single ccd) and
     tilt (multiple ccd's) (with EV). (since 9/11)
     Andrea will read out  all chips in focus template. Write e-mail for confirmation.
   - Implement/use DBObject api based on Python metaclasses to allow schema
     evolution in Python (since 4/1/2)
   
EV FDR actions
   - Check odoco for 2 lamp circuits. (since 9/11)

AOB

   - Every requirement shall have its own recipe.
   - Testdata will be placed on and distributed from the database/fileserver
     when it arrives. rsync/CVS could also be used to distribute the data.
   - Always put the check of the preconditions/inputs in make().
   - The result of the verify() methods should be e.g. a flags parameter
     in the descriptor.
   - !! Continue Recipe implementation crash effort in January 2002. !!



Questions raised as a result of the BIAS recipe evaluation:

   Where can the documentation of a class or method be found?
   How to find lower level functionality?
   How to adapt lower level functionality to ones needs?

   Preliminary answers.

   Documentation of a class/function/method/module is local to the _definition_
   of that class/function/method/module. Wherever a class/function/method/module   is _used_ a one line comment can be added to clarify what happens.

   All docstrings shall be comprehensive.

   One of the OO doctrines is to hide lower level implementation from
   higher level invocation. As a consequence, a user who ones to adapt
   lower level implementation to its own needs has to descend to that
   level to make the appropriate changes. Inheritance from a class gives
   the user the possibility to implement changes without interfering
   with the existing class.


RECIPES
               writer/reviewer  / ADD DATES
image pipeline   RR / ed                      January
562 Monitoring   RR / ed,ev,kgb,db  On-site   January
547 Quick_check  ed / DB            On-site   January
521 Read_Noise   DB / kgb           On-site
531 Dark_Current DB / ed            On-site
541 Bias         rr / kgb,ev,db
542 Dome_Flat    rr / ed
522 Hot Pixels   DB / ed
523 Gain         rr / kgb
554 PSF          RR / ev
535 Cold pixels  ed / DB
543 Twilightflat rr / KGB

Notes.
   - Update "Status" keyword in odoco for requirements.
     "Written" means recipe is written.
     "Verified" means recipes corresponds to specification.
     "Qualified" means working well when applied to test data.
     "Done" means everybody is happy with the result.
     Each of the values "Written/Verified/Qualified" may be followed
     by the initials of the person adding it.
   - Parameter values should go to the descriptor.
   - Preconditions/postconditions; all additional checks on input or output
     data should go to a verify_in() and verify_out() method.
     verify_in() should always be called in the corresponding make() method.
     The result of all verify()'s should be a parameter value that goes to
     the descriptor.

NB. Bij ieder recipe hoort een zelftest en, waar mogelijk/nodig, nepdata, WFI
    data en OmegaCAM labdata.
    De reviewer is degene die bepaalt of een recipe klaar is, of meldt wat
    er aan ontbreekt.
    Reviewers wordt aanbevolen bij bugs een testcase te schrijven die "failt".