UPDATE LIST OF OmegaCAM ACTION ITEMS as of 18/12/2001 ======================================================== Next meeting 4/1/2002 13:30 + Means action closed STATUS/NEWS - 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. - Fabrice will try to have a look at time variations of the gain of the CCD's under lab conditions and also try to compare a CCD that had to be tuned with one that works with nominal settings. AI FOR ALL - 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 28/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). + Inspect with Fabrice the CCD test data (this week in Groningen) 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) ED - Appropriate projection facilities for Astro-Wise inauguration. (since 2/11) + Trace bug in LDAC causing incorrect calculation of PV matrix. (since 7/12) - Bug is repaired. New calculation of the PV matrix is now tested. 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) -create sample calibration db (since 18/4) - Use `qc1log' in QCLog stub. (since 2/11) - Implement Oracle9i binding of the OmegaCAM database. (since 7/12) + Copy CCD FDR documents from Koen for FDR package file. (since 7/12) 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) - Check odoco for 2 lamp circuits (with EV). (since 9/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. EV FDR actions + What filter to use for gain/linearity? Prefer r (when not fringed- update doc's) (since 18/12) - Fabrice recommends filter around 630nm to avoid fringing. - Check odoco for 2 lamp circuits (with RR). (since 9/11) + Reestablish contacts with Oracle after Bjorn Engsig departed Oracle. (since 7/12) Contact was reestablished with Dave Pearson. AOB - !! 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. "Comments" can be followed by comments on all parts of the requirement and its implementation. Each of the values "Written/Verified/Qualified/Comments" 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. 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".