Table information for 'califadr3.objects'

Problem

The idea is to put all cubes at the rest frame. So if you have the velocity recession in the header (MED_VEL; or taken from NED), just have to do:

w_rest = w_obs/(1 + (recvel/c_speed))

Once I have a common wavelength reference, I want to look if I have a certain emission line. Let's say I look for Halpha. An easy way to do it without measuring the line is define a continuum an compare the fluxes. So if:

flux_6563 / [(flux_6540+flux_6700)/2.0]  > 3

it's a hint of having Halpha emission. As you see, I use to continuum points at both sides of the line.

Then, I would ask for all spectra in the cubes having this condition.

Solution

There are several ways to solve this problem using VO tools and services, but we will, somewhat unorthodoxly, use TAP, a protocol to exchanges SQL (actually, ADQL) queries and query results with servers. There are several clients that can do this; if you have no other preferences, use TOPCAT. There, open VO/TAP, push the pin in the left upper corner of the window (to keep the window open after sending off a query), and in the TAP URL field below, enter http://dc.g-vo.org/tap. Hit "Enter query", and you are in a dialog that lets you inspect a server's table metadata (look for tables in califadr3) and enter queries.

The targets of the CALIFA survey and their redshifts are in the califadr3.objects table. So, to compute the wavelengths in question you could say:

select
        target_name,
        califaid,
        6563*(1+redshift) as lha,
        6540*(1+redshift) as lri,
        6700*(1+redshift) as lle
from califadr3.objects                                         (1)

The wavelength/fluxes pairs, on the other hand, and in tables califadr3.fluxv500 (or v1200) and califadr3.fluxposv500; in the former, flux is given over lambda, califa id (a small integer; let's use 909, corresponding to UGC 12519, as an example further down) and pixel coordinates, in the latter, it is celestial positions.

Since we cannot usefully compare floats for equality in generally, and in particular not here, to retrieve fluxes for a single wavelength you need to restrict lambda to an interval wide enough. How wide the interval needs to be, you can figure out be determining the spacing of samples. For the V500 data set, this could look like this:

select distinct top 2 lambda
from califadr3.fluxv500
order by lambda (2)

(This is fast although there's dozens of millions of lambdas in this table because there's an index on lambda, and there are not many distinct values). If you try it, you'll see that we have steps of two Ångström, so you'll want the interval to be something like 2.2 Ångström.

To obtain fluxes while while having the redshift available -- as needed here -- you need to join the objects with the flux tables; here, you can use a "NATURAL" join, which means all columns identically names are to be used for joining:

select top 5000 target_name, xindex, yindex, lambda, flux
from
  califadr3.fluxv500
  natural join califadr3.objects
where
  lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
  and target_name='UGC12519'                                 (3)

The "top 5000" is necessary here to retrieve all fluxes: to protect your nerves, the server inserts a "top 2000" unless you order something else. The restriction on the califaid makes sure we don't retrieve all fluxes between our two wavelengths in the CALIFA tables.

This table has pixel coordinates. The physical positions for each pixel are in a table called califadr3.spectra. To get them into your table, you'll need another join:

select top 5000 target_name, raj2000, dej2000, lambda, flux
from
  califadr3.fluxv500
  natural join califadr3.objects
  natural join califadr3.spectra
where
  lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
  and target_name='UGC12519'                                 (3)

At this point you could retrieve the flux maps at the three tables and use, for instance, TOPCAT's crossmatch functionality to do the match client-side. However, let's assume we want to keep processing server-side, e.g., because we want to run this on a lot of objects and don't want to download all the layers.

To retrieve fluxes at multiple wavelengths, you can query like this:

select top 5000 target_name, raj2000, dej2000, lambda, flux
from
  califadr3.fluxv500
  natural join califadr3.objects
  natural join califadr3.spectra
where (
  lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
  or lambda between 6540*(1+redshift)-1.1 and 6540*(1+redshift)+1.1
  or lambda between 6700*(1+redshift)-1.1 and 6700*(1+redshift)+1.1)
  and target_name='UGC12519'                                 (5)

The problem with this is that you cannot compute the criterion for a strong Halpha emission from this as the three fluxes are in three different rows. When you are in that situation, SQL offers grouping -- this means that rows sharing a criterion end up in a bag; you can then use "aggregate functions" on these. Note, that as most things in the relational world, the items in the bag are not sorted.

As a general word of advice: In the SQL world, thinking in array terms is typically going to lead to complicated and slow queries. Try thinking in terms of sets and matters will become manageable.

ADQL's aggregate functions are a bit limited, but for this case they're just enough -- just compare the maximum flux to the average flux:

select top 5000 califaid, xindex, yindex
from
  califadr3.fluxv500
  natural join califadr3.objects
where (
  lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
  or lambda between 6540*(1+redshift)-1.1 and 6540*(1+redshift)+1.1
  or lambda between 6700*(1+redshift)-1.1 and 6700*(1+redshift)+1.1)
  and target_name='UGC12519'
group by califaid, xindex, yindex
having (max(flux)/avg(flux)>3)                                (6)

We group on pixel coordinates here as that's much more robust (and also somewhat faster) than going by the floating point ra/dec pairs. To turn the pixel coordinates to postitions you can do something with, again do a join with califadr3.spectra as in (4), except this time you turn the entire query so far into a subquery:

select raj2000, dej2000 from (
      select califaid, xindex, yindex
      from
      califadr3.fluxv500
      natural join califadr3.objects
      where (
      lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
      or lambda between 6540*(1+redshift)-1.1 and 6540*(1+redshift)+1.1
      or lambda between 6700*(1+redshift)-1.1 and 6700*(1+redshift)+1.1)
      and target_name='UGC12519'
      group by califaid, xindex, yindex
      having (max(flux)/avg(flux)>3)) as spots
  natural join califadr3.spectra

Finally, if you want to have all such "interesting" points in CALIFA, drop the constaint on the object name:

select raj2000, dej2000 from (
      select califaid, xindex, yindex
      from
      califadr3.fluxv500
      natural join califadr3.objects
      where (
      lambda between 6563*(1+redshift)-1.1 and 6563*(1+redshift)+1.1
      or lambda between 6540*(1+redshift)-1.1 and 6540*(1+redshift)+1.1
      or lambda between 6700*(1+redshift)-1.1 and 6700*(1+redshift)+1.1)
      group by califaid, xindex, yindex
      having (max(flux)/avg(flux)>3)) as spots
  natural join califadr3.spectra                           (8)

This is a fairly long-running query, which will time out on you on when you enter it through the "synchronous" TAP endpoint that TOPCAT uses by default (because it's simple and has little overhead). To use the "async" endpoint, uncheck "Synchronous" in TOPCAT's TAP dialog (or do the equivalent thing in another client). With this, you can turn off your computer, take it somewhere else, and resume operations when you get back; in this case, the job should be done in 20 minutes or so depending on server load and similar factors.

Once you have the data, try a few of the nice VO features you get. If you used TOPCAT to query, the result is in a table. With this, start Aladin, in TOPCAT, select Interop/Send Table To/Aladin and watch your matches in Aladin. Hit, e.g., "Optical" in Aladin, and you can zoom in on the "interesting" spots and see them overplotted on sky images.

You could now load the corresponding spectrum into a spectral analysis tool like, say Splat. To do that, in Aladin click on one point, go to the load dialog and there the "all VO" tab. Optionally, go to "Detailed List", hit "Uncheck all" and just check the "CALIFA Spectra" service (this is going to speed up your queries significantly).

Then start Splat, in the Aladin load dialog set the search radius to 0.01' (i.e., .6 arcsec) and submit. You should see both the V1200 and the V500 spectra -- right click on the one you want to see, select "Open with", "Splat", and work with your spectrum there.

If you don't want to get Splat, TOPCAT will do as well, although it has much less of built-in knowledge about spectra -- in that case, open TOPCAT's VO/SSA dialog, in the list of SSA services select "califa ssa", make sure "Accept Sky Positions" is checked, in "Diameter" again say something like 0.6 arcsec. If you hover over a point in Aladin, you'll get your positions filled in, and if you hit "Ok", the spectrum will be retrieved. If you, again, use the pushpin to make TOPCAT keep the window open, you have a quick way of downloading spectra that look interesting to you.