Relationship of Galaxy Morphology to the Intra-cluster Medium: an NVO Demonstration Ray Plante and Jim Annis Version 2.0 Abstract The NVO is developing three demonstrations of VO principles as part of its first year efforts. This document describes the "Galaxy Morphology" demo, summarizing the science and technical goals. It also outlines how the demo will proceed from the prospective of the audience along with the implementation requirements. Contents: I. Science Summary II. Technical Goals III. Demo Outline IV. Imlementation Requirements I. Science Summary This demonstration looks for relationships in galaxy clusters between morphology of its member galaxies and the intergalactic environment. In particular, we will use the X-ray flux surrounding galaxies as a probe of the intergalactic environment. Morphology will be characterized by three parameters--mean surface brightness, concentration index, and asymmetry index--which we will calculated directly from images of the galaxies. The primary results will be correlation plots between these parameters and the surrounding x-ray flux. To help us understand any correlations found, we will produce correlation plots of these four quantities with other readily available quantities. For example, correlations of the x-ray flux with distance to the cluster center and local galaxy density would test how sensitive the x-ray flux is to the Dressler morphology-density relation (Dressler, 1980ApJ...236..351D). A galaxy's radio flux could be a further indicator of galaxy encounters which could be explored via a comparison with the morphological parameters. II. Technical Goals 1. demonstrate how diverse data resources can be incorporated into grid-based computational analysis 2. demonstrate the discovery of catalogs relevent to a scientific question from diverse locations. 3. demonstrate the generic aquisition of image cutouts from various sky surveys. 4. demonstrate how a table interchange standard can allow users to integrate their own data into NVO-based analysis and publishing. III. Demo Outline The following describes the sequence of steps for obtaining the results of the demo investigation as seen by the demo audience. 1. Obtain a catalog of cluster positions. In principle, this can be any catalog providing right ascensions, declinations, and red-shifts; however, a catalog of actual clusters would be most obviously meaningful. We will show up to three possible ways of doing this: a. Discovering a "cluster" catalog. This will be done by doing a search of catalogs in a registry service based on UCD column tags and subject/title. Our default catalog will be "Redshifts and Vel Dispersions for Abell Clusters" (Struble, Rood 1991), available from the ADC & Vizier. The chosen catalog will be downloaded to the local disk of the demonstration (i.e. the user's machine) b. Creating a custom catalog from NED. This would be done by using the NED services to create "best values" for a list of clusters in VOTable format and downloading it to the local disk. c. Use a pre-assembled table stored on local disk as an example of a table that might be created by the user. This is to demonstrate the use of user-provided data. Option b. could be combined with c. if it is too difficult to demonstrate in the limited time of the demo: we would explain that the user-provided table was created using NED. The contents of the table could be displayed either in raw form or via a service that transforms the VOTable to HTML (using the stylesheet available from http://us-vo.org/VOTable/.) 2. Obtain a table of candidate member galaxies. Since we will want to eventually obtain image cut-outs of these galaxies, it is best to mine this list from an extended object catalog associated with the target image surveys. We will require major axis, minor axis, and position angle for each galaxy. Our target surveys will be SDSS and 2MASS. The list will be generated by doing a cone search on the center of each cluster. This will be done in one of two ways: a. use a version of the remote cone search service that will accept an input VOTable containing the input parameters and returning a single VOTable. b. use a client program that submits multiple cone searches using parameters found in the local VOTable. The results would either be stored each in its own table, or combined into a single table. (If possible, we will use a resource registry to identify the locations of these resources and their cone search services. The search would request sky surveys with extended object catalogs associated with them.) The results can be viewed in a manner similar to that described in step 1. 3. Create a VOTable containg x-ray fluxes of the regions around the candidate galaxies. This will be accomplished via a custom service of the Chandra X-ray Data Center. (If possible, this service will be discovered via a resource registry.) The service will return calculated fluxes and possibly pointers to X-ray image cutouts as a VOTable. This would be obtained in one of two ways: a. use a version of the service that accepts a VOTable input containing the needed input parameters (position, elliptical region). b. use a client program that submits single flux requests for each of galaxies in the candidate member galaxy catalog(s). 4. Cross-match the galaxy and x-ray flux tables. This would be done using a general-purpose, remote cross-match service (as set up by Roy Williams). 5. Set up and execute a grid processing job to calculate the morphology parameters. This will most likely be done using Condor. The input will be the combined table from step 4. and a pointer to the target survey's image cut-out service. Each galaxy in the table can be handled by a different thread. Each galaxy thread will retrieve the cutout and calculate the parameters; the master thread will add the parameters to new columns in the table. 6. Generate correlation plots. This will be done using a locally installed plotting package. IV. Implementation Requirements The steps described above imply certain tools to exist or be implemented. These requirements are described below. Multiple alternatives and functionality marked "if possible" will be implemented as resources and time allow. * Step 1a implies a searchable catalog registry service that allows one to search on UCD column tags, subject, and title; this would need to be implemented. It also implies that the desired catalogs are available in VOTable format. * Step 1b implies that NED services can return VOTables; currently, they can not. * Step 1 suggests a service for rendering VOTables in HTML via XSL. While many browsers can transform XML documents automatically when they contain a reference to the XSL stylesheet, it is probably not wise if not impractical to require VOTable creaters to include a reference. An XSL rendering service, however, is very simple to provide (the BIMA Archive server does this to some extent already). * Step 2a--a cone search that takes a VOTable as an input--is a capability we would like to see in the VO and probably a good one to demonstrate; however, it may not be practical to implement for more than the two target catalogs on the time scale of the demo. Step 2b--a client program that handles multiple cone searches--could, however, be made general enough to use in other parts of the demo and would be adaptable to any of the current cone search applications. * Step 2 suggests use of a resource registry. While this is a useful thing to demonstrate, it is not critical to the demo. * The X-ray flux service at CXC, needed in Step 3, is now in development. The initial version will be a simple CGI service that takes as an input an elliptical region--a center position, a minor axis, a major axis, and a position angle--representing the extent of the galaxy. Returned will be two fluxes: a background-corrected flux of the region (representing the galaxy's flux), and a background-corrected flux of a surrounding annulus of twice the size. The second version, if resources permit, will take a VOTable containing the parameters as an input and will return a VOTable containing the fluxes along with other useful data about the observations, including a pointer to a cut-out image. * The cross-matching needed by Step 4 can use the service set up by Roy Williams. * The details of how the grid job is set up and executed still needs to be worked out. The processing kernel will be based existing code by Jim Annis. * A client side tool for extracting column data from a VOTable will be needed to interface with a common plotting package. This will likely be WIP (due to Plante's familiarity with it). Canned plotting scripts will be used create the plots from the final VOTable.