PIER-05 Quality Control (in and out)

Hi All,

After two months in the syndicate, I thought I might provide some feedback on my experience to date.  

While I am new to AP (well, 18 months in), I was a professional support astronomer on the Anglo-Australian Telescope and Issac Newton Group of Telescopes form 1988-1996 and Director of the Anglo-Australian Telescope (1996-2003), Australia Telescope National Facility (2003-2009) and the Australian SKA Pathfinder (2009-2015).  I have also worked extensively with CCD imaging, including as member of the Supernova Cosmology Project Team and discovered the acceleration of the Universe.  [This is not an attempt to blow my own trumpet, merely to show that I do have some experience and thus some basis to provide what I hope is constructive feedback.]

It is clear that Roboscopes relies heavily on users to QC the data in and out - both in the coordinates supplied and tin the analysis of the data coming off the telescope. No doubt this is why the rates are good, since we as users are expected to do more of the work, since the support staff are themselves flat out. Fair enough, I get the model.  

Arguably, for a small syndicate, this approach is challenging. And, indeed even more challenging when the weather is poor and Q is highly variable.  

Take for example that most recent data on the ftp site.  One set was M45, which had already been taken (submitted incorrectly under the The Vulture Nebula), and had been flagged as such (by me) and acknowledged by the proposer (by Vikas), yet it still managed to slip through the cracks.  The other was Job 1216, the other half of the B7 dark nebula.  Unfortunately the first part of the panel was taken in 75% moon, and is quite compromised. Thus in effect, both sets of data have their issues. 

Unfortunately with the lag between data acquisition and data availability, it is really difficult to provide feedback in this user-driven QC model that can influence future data-sets (particularly those in mosaics) before they are taken.  Indeed, that is why I have withdrawn the Witch Head mosaic.  It is simply too risky under the current model.

Equally this applies to weather conditions, particularly when we have had the bad dew over the past 4-6weeks.   The delay between acquisition and distribution of data, makes it very difficult to assess under what conditions the data were taken, and what might be the cause of low SNR or poor images.  The telemetry on the site is great, but unless I am missing something, I can't find the contemporaneous telemetry for the data I am reducing, usually over a week since it was acquired.

So, what to do?  In the face of the user-driven QC model, understandably driven by resource constraints, I can only offer the following suggestions

1) Greater care and checking of coordinate submissions [I know I am guilty of getting this wrong].  The Roboscopes team have set up a forum to discuss submissions and a method to request removal of submissions from the queue, so that should help.
2) If possible, quicker turn-around of data between observation and distribution.
3)  If that is not possible (and I understand that there is significant work in this), perhaps access to the weather telemetry record when the data was taken to assist the user in reducing the data.  I know, that I found it difficult to diagnose the problem with much of my data (high cloud, incompetent data reduction) until the dew issue was acknowledged.   Perhaps this already exists and I just don't know about it.  

And yes I know that I have joined Roboscopes at a time of poor weather, but this has the advantage of stress-testing the system and, I believe, some useful learnings have come out.  

Regards

Brian