Sussex Workshop - Group A

Who

• Attendees:

• Helpers: JonathanTedds, SilviaDalla, PhilNicolson

Notes

Group A (Kathy's group)

Want to work with their private XCS cluster catalogue. They want to match it to SDSS DR4 and 2MASS (ultimately UKIDSS). Results include determining any pointing offset. They want to obtain any catalogued redshifts within their fields and determine photo-z for cluster members.

Also want to cross match VSZS cluster catalogue and possibly also whole REFLEX catalogue with known radio sources. VSZS is a sample of the brightest REFLEX clusters in the southern hemisphere (dec <-45), observed with ACBAR at 150GHz, with 5' resolution. We would like to know how many clusters in our sample are associated with radio sources (and eventually estimate the contribution of these sources at 150GHz). Radio surveys in the southern hemisphere include SUMMS, which is available over astrogrid.

A possible extension to this would be wrapping 'specfind' (Bert Volmer @ CDS) for use within astrogrid. Specfind would allow us to choose specific types of radio sources before correlating.

XCS Progess:

We have converted the XCS catalogue into VOTable (tabledata) format from CSV format in Topcat. We have also learned how to edit the column headers and add UCD (universal column descriptor?) names. The important columns for the cross matcher are RA and Dec. The UCDs for these are:

POS_EQ_RA_MAIN

POS_EQ_DEC_MAIN

We want to extract a sample of sdss objects in our XCS regions and cross match with our catalogue. We're going to try this using the RA & dec of one of our objects as the centre of a search region. Next we have to choose a suitable search radius. Trying 15 arcmin to begin with. We thought it might be more efficient to load in a list of regions, pull out a votable from sdss for each region and then run crossmatcher between each sdss votable and our own catalogue. However, we then abandoned this for the following:

We realized we didn't need to run crossmatcher separately if we just queried each object individually, because this essentially is cross-matching. So we just had to reduce the query search radius to some "match" radius. In order to do this we had to build a workflow to loop over all the objects in our catalogue.

We have managed to build a workflow which:

• Loads up our catalogue in votable format.
• Reads the RA & Dec columns
• Loops over each object and sends an sdss query using the RA & Dec of the object. Search radius is 15 arcsec.

This gives us a separate output table for each loop and we're not sure how to deal with all the output. Ideally we would like to add this information to our XCS table, but we don't know how to do this in workflow builder.

We could write each table to a separate output file, but we have to figure out how to make the output file for the sdss query variable. e.g. filename${j} where j is the variable we are looping over.

We thought we'd managed to do this however the workflow ends in an error, and we can't yet make any sense of the error messages.

It appears the error messages are to do with the part of our workflow which is recording and then accessing the ra and dec values for each object.

We also forsee having problems with compiling all the results into a big table, as we have learned that this is not currently possible with astrogrid applications. Possible solution (?): http://wiki.astrogrid.org/bin/view/Astrogrid/JesScriptingFAQ#3_1_Concatenating_2_votables

General problems we have encountered:

• Sometimes when browsing myspace the directory structure is invisible (the left hand side window is blank, and we can only bring up random bits of it by clicking in the window). As a result we tended to save things on the local disk most of the time.
• Having to create a new file before saving it.
• In the VO Lookout window, if we stop and delete one of our workflows, it re-appears everytime we refresh the window (with attached errors).
• Scripting is difficult when you don't know the language. Debugging is even harder.