Belfast Meeting, September 18th 2007

Presents: Stephen Smartt, Dave Young (QUB), Eduardo Gonzalez (AstroGrid, IoA)

We had a kick-off day meeting at Belfast to define what needs to be done for the project.

PS1 is a 1.8m telescope built in Haleakala, Maui. Some quick facts:

• Data rate as high as 1 Tb/night (1.8 Pb over 3.5 years)
• Camera is 8x8 CCDs each of 4096x4096 pix (that is SLOANx10) covering a f.o.v of 7 sq. deg.
• Survey operations start on March-April 2008.
• Pipeline processing is done at Maui HPC
• Astrometry good to 100 mas absolute over whole field, 10 mas internal. (Reference is USNO-B?)
• Limiting magnitude (for this project) is r~24 after stacking (~10 stacks over 3.5 years). Compare SDSS with r~22.
• Complete sky coverage 30,000 sq. deg.
• The Pipeline Processing module (IPP) is in charge of processing the images (almost in real time). The Moving Object Pipeline (MOPS) receives the output from IPP and searches for transients.
• From the point of view of this project we are only interested in catalogues and cutouts from MOPS. We estimate that the data volume of this is not high so we want to run the software locally at QUB.

The following PDF summarizes the discussion and workflow to implement: ps1_workflow.pdf. The green box requires further investigation when in contact with someone at IfA^?. The blue boxes will need definition from QUB.

The MOPS module will ingest the catalogues coming from the IPP and produce a database of possible transients. We need to use some criteria to select from those a list of potential objects. We need to discuss further how to access that database and how to obtain the needed information from it. Also if it provides cutouts or what is the preferred way of getting those.

Once we have a list of selected transients AstroGrid will write a program module that takes as input this list and a list of catalogues to be queried (provided by QUB) and carry out a cone search and cross match for each transient in all the provided catalogues. The output result is then filtered, in a process in which additional parameters (like absolute magnitude, distance of the transient to the nearest galaxy, ...) are also calculated. During this process the transients will be classified as possible variable stars, SN, AGN, X-ray binary and others. All these except 'others' will be ingested into a Postgres database flagging also some interesting objects. The design of this database has to be done when we know what information is available from MOPS and how we want to propagate that information. By installing a DSA in front of this Postgres DB we can benefit from the option of performing more advanced queries to select particular objects.

At this point we also want to generate an alert (VOEvent). Discussion on how to do this is referred for next week. Only to note that once this is done we will also have access to a RSS feed, a STAP service and Google Sky publication through KML.

The user will interact with the data through a set of web pages. A single web page will list all the VOEvents and for each of them a link will direct to a web page with all the information known for the object detected including cutouts (see http://voeventnet.caltech.edu/feeds/SDSS.shtml). It is necessary to define what information is included in the listing page and how to design the web pages for clarity. Also we need the (authenticated) user to annotate the object pages (e.g. inserting the SN type if a spectrum has been obtained or maybe even including a spectrum).

Other points to note:

• MOPS will be updated almost in real time, but we expect to run the full workflow nightly. Probably this is ok but we could discuss the possibility that an update to the MOPS database triggers this workflow.
• Each transient is detected in one filter and a VOEvent is sent, so after some nights we will have the transient detected in several filters with possible several VOEvents for the same object. So the question remains on how to group these VOEvents which correspond to the same source detected in different nights. Is VOTimeSeries^? responsible for this?
• The number of transients coming from the MOPS selection can be as high as 10,000. This may be too much for the cone searches. We may need to add some more restrictive filters and probably be a bit smart on the Xmatch. It is anticipated that most of these will go into the 'Others' classification though.

Next Meeting: Friday 28th at the IVOA in Cambridge. See IoAMeetingSep28