OTFC is performing well. Several overseas requests completed successfully. No problems or questions have been reported to the archive hot seat.
Most requests for WFPC2 and STIS data (about 75%) are being carried out through OTFC. Nearly all OTFC requests are for proprietary data. Most nonOTFC requests for WFPC2 and STIS data are for nonproprietary data.
The fix for the DADS test pipe to OTFC has not yet been completed. There is an NFS problem that is getting higher priority. There is no schedule for when the test pipe will be enabled. Meanwhile, we cannot use the test pipe for OTFC.
Ron has suggested that the system track reference files used for each dataset processed, along with the user name. This feature would be part of the requirements for not storing calibrated data. Most problems that arise with STIS concern reference files. The STIS team would like to be able to contact individual users about problems. It is in principle possible to determine which reference files were applied to a given dataset through the OTFC and CDBS database tables. However, in the OTFR era we will not know the calibration keyword values in a dataset at some time in the past because keyword changes may occur through generic conversion changes. Instead, Ron proposes that we store the names of the reference files along with the dataset name and user name for each calibrated dataset. This should probably be implemented in a database table that is populated by an OPUS task.
The OTFC performance statistics are now being gathered in the DADS database table. Lisa is developing queries to produce reports. The cpu time has a 1 second granularity.
Mike Swam is going to develop an OTFR pathfinder. The pathfinder will operate in the manner we tested WFPC2 and STIS calibration pipelines. That is, some datasets will be requested from DADS. Steve and Mike will use this system to see if there are problems with the use of POD files.
AN OTFR cache of about 600 GB would be required to store all the existing WFPC2 and STIS POD files. Some savings through data compression may occur. This could be done through either MO disks or standard disks, which are now cheap. With standard disks, the cost would be around $50,000. We are unlikely to pursue this approach in the short term. This solution is equivalent to allowing OTFR to directly make data requests without going through DADS. This may be a desirable approach for the long term.
OPUS is going to save trailers for requests that go to trouble. We discussed having a mechanism to automatically alert the instrument teams about calibration problems through email. The archive branch and the instrument groups want this. A script that operates as a cronjob will need to be written.