IPP Progress Report for the week 2011.03.14 - 2011.03.18

(Up to IPP Progress Reports)

Eugene Magnier

Serge Chastel

• MOPS czar
• mops helper for czar reporting
• IPP czar
• Nebulous replication on ippdb02
• pstamp backup
• Updated ​http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/wiki/Processing with screen/czarpoll
• gpc1 replication failed

Heather Flewelling

Roy Henderson

• PSPS
  • extracted more files for Jim's MD04 stack analysis (weights)
  • some discussions and planning with Jim regarding new plan to only publish detections seen twice or more.
  • PSVO
    • more design discussions with Daniel and Jim regarding integration of graphical query building into PSVO. We have a plan.
    • started on Classes to encapsulate database schema for the above
    • bug with JDBC drivers not on CLASSPATH for jar version: fixed

• IPP
  • czartool
    • a face-lift for czartool: nicer tables, clearer highlighting of errors, better general formatting
    • a fix for unsightly jumps in czartool plots when a new label is added (done by checking for large jumps in 1st derivative value, then adjusting accordingly)
    • finally added publish to czartool
    • created a new rate line plot (while retaining stacked histogram). Now using this on czartool webpage
    • added a 'pending postage stamp requests' table to webpage
    • added nebulous time series plot to webpage
  • ippToPsps
    • DetectionBatch class now utilizing new Fits class. Used new unit-test to ensure I didn't break anything along the way
    • added some documentation on detection batch unit-testing

• Other
  • some time granting data access to new Hungarian group

Bill Sweeney

Chris Waters

• Investigated the dtime_photom values from the chip stage: ChipStage_Timing. Conclusion was that chips with bad dark models were identifying large numbers of faint sources, and the footprint culling algorithm ran slowly for these sources.
• Diskspace: Identified that hosts with larger-than-expected disk usage were hosts that had been offline at somepoint in the past. This causes them to have gaps in the range of so_ids that are available on that host, which decreases the effectiveness of the disk balance code. To get around this, disk balance now starts at a random so_id value to allow the full space to be explored with more regularity. Previously, only a small fraction starting at so_id = 1 were being examined.
• Reprocessing: organized scripts to calculate tessellation cells that are well populated in all filters, and plot DVO image footprints. This will help in choosing which data to use when we start reprocessing.
• Detectability server: bugfixes and rewrites to get this working correctly. Still not finished.