Another issue for JLS observing is with time accounting. How to account in the OMP the time for data that has been deemed unacceptable. These data do not get charged to the surveys so if the data were initially QUESTIONABLE retroactive action will need to be taken to correctly account for that time (notwithstanding the issue of shared calibrations...see later). So that we can track how much time has been REJECTed by each survey, there shall be a special project code (eg. MJLSG00) for each which we will use to charge REJECT observations to.
The idea is that when the obslog flag changes:
1. an email is triggered to ACC and PIs notifying the change
2. if the change is to REJECT then the release date is automatically changed to TODAY (or equivalent)
3. ACC runs up nightrep for the night in question and changes the time accounting accordingly.
4. changes to flags are propagated to CADC
In a situation where calibrations are provided by the observatory this system should work flawlessly (and a tool which takes care of the time accounting automatically would also be feasible). However, in the current situation where calibrations are shared amongst the projects, it is difficult to do the time accounting properly in this scheme as it is not immediately obvious how much calibration time should be taken with the REJECTed observation. It would have to be recalculated.
3 comments:
I still have problems with assigning observations to a made-up project just to massage accounting. For one, it loses the history of what project ID the data was originally taken under. And we have to go all the way back to disk and to CADC to change the PROJECT header - it's a nightmare.
But more to the point I am not sure it is necessary.
Tim, is there a reason why different observations in a project cannot have different release dates? Aside from the release date I don't see why REJECT observations are different from BAD for time accounting purposes, and we definietly don't move out BAD observations to a special project.
Is this massaging or managing accounting? ;-)
I thought the plan was to not change the project header. Data taken under a project banner, even though it's REJECTed, should not lose its history.
Ultimately I don't care how it is done, but what I want is to be able to track how much time is being charged to JLS projects and how much time/data each project is REJECTing.
The "00" project was for time accounting. There was no intention to modify the project id in the database or in the headers. The release dates can be different per file. BAD observations contribute to FAULT statistics. REJECT observations are not associated with FAULT statistics. FAULT, WEATHER, OTHER are all general time accounting categories that do not need to be associated with the original project. REJECT is different in that you would like to know which project is rejecting the most data and justify this separately to the Board (although in general REJECT should be small and should be associated with CAL because of QA processing). The trouble with "00" is that this approach is not generic. It only works for JLS observations.
One option is to charge to REJECT as for FAULT and WEATHER but provide a separate interface that would scan obslog for REJECT statistics on a per-project basis. This would remove the need for magic projects but is only really tenable if the calibrations are not charged.
Post a Comment