Table information for 'califadr3.fluxv500'

General

Table Description: Flux and errors versus position for CALIFA setup v500. Positions are pixel indices into the CALIFA cubes. The associate positions are in califadr.spectra; use "JOIN califadr3.spectra USING (califaid, xindex, yindex)" to join that table (or use the fluxpos tables).

This table is available for ADQL queries and through the TAP endpoint.

Resource Description:

The Calar Alto Legacy Integral Field Area (CALIFA) survey provides spatially resolved spectroscopic information for 667 galaxies, mainly within the local universe (0.005 < z < 0.03).

CALIFA data was obtained using the PPAK integral field unit (IFU), with a hexagonal field-of-view of 1.3 square arcmin, with a 100% covering factor by adopting a three-pointing dithering scheme. has been taken in two setups: V500 (6 Å bin size, 646 galaxies) and V1200 (2.3 Å bin size, 484 galaxies). A final product ("COMBO") combining both data sets, covering 3700-7500 Å at 6 Å bin size, is made availble for 484 galaxies.

CALIFA is a legacy survey, intended for the community. This is the (final) Data Release 3.

For a list of all services and tables belonging to this table's resource, see Information on resource 'CALIFA (Calar Alto Legacy Integral Field spectroscopy Area) survey DR3'

Citing this table

This table has an associated publication. If you use data from it, it may be appropriate to reference 2016arXiv1604.02289G either in addition to or instead of the service reference.

To cite the table as such, we suggest the following BibTeX entry:

@MISC{vo:califadr3_fluxv500,
  year=2016,
  title={{CALIFA} (Calar Alto Legacy Integral Field spectroscopy Area) survey DR3},
  author={Sánchez, F.; The {CALIFA} collaboration},
  url={http://dc.zah.uni-heidelberg.de/tableinfo/califadr3.fluxv500},
  howpublished={{VO} resource provided by the {GAVO} Data Center}
}

Resource Documentation

A TAP example

The CALIFA cubes are available in database tables at this site. Here's an example for how to solve a little problem using VO tools.

There are two additional examples for how to use TAP to explore the CALIFA data in our TAP examples:

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.

Fields

Sorted by DB column index. [Sort alphabetically]

NameTable Head DescriptionUnitUCD
lambda λ Wavelength Angstrom N/A
flux flux Flux 1e-19 J/(s.m**2.Angstrom) N/A
error Err. flux Error in Flux 1e-23 J/(s.cm**2.Angstrom) N/A
califaid Id CALIFA id number of the target. N/A meta.id
xindex x X index in the CALIFA grid; V1200 indices are pixel+1000. N/A pos.cartesian.x
yindex y Y index in the CALIFA grid; V1200 indexes are pixel+1000 N/A pos.cartesian.y

Columns that are parts of indices are marked like this.

Other

The following services may use the data contained in this table:

VOResource

VO nerds may sometimes need VOResource XML for this table.

Copyright and such:

CALIFA asks you to acknowledge:

"This study uses data provided by the Calar Alto Legacy Integral Field Area (CALIFA) survey (http://califa.caha.es/)."

"Based on observations collected at the Centro Astronómico Hispano Alemán (CAHA) at Calar Alto, operated jointly by the Max-Planck-Institut fűr Astronomie and the Instituto de Astrofísica de Andalucía (CSIC)."

and to cite both of 2014A&A...569A...1W and 2012A&A...538A...8S