Enceladus shells

Just a note: Helmi is interested in locating Enceladus shells, using RR Lyra.
Plan is to make plots in R_GC and look for peaks in p(R_GC) at low v_tan

Reconstructing the center to edge spectra of stars in eclipsing binaries

Anish Amarsi showed (at GC Retreat 2018) that for the Sun, it is highly informative to analyze spectra from different parts of the disk, effectively spectra emerging under different angles from the photosphere; this is "straightfoward" for the Sun, as it is well resolved.

It looks like the math of doing this from multi-epoch spectra of eclipsing binaries is very straightfoward.

A very cursory check of the literature indicates that some efforts have been made in this direction (using H-alpha line profile to make a surface map etc..); but HWR has seen nothing comprehensive
to solve the problem:
Given a set of high-quality spectra of eclipsing binary stars, with sufficient phase coverage and known orbit geometry, is there a straightforward way to reconstruct rigorously the entire spectra of both stars, as a function of distance from the center; presuming cylindrical symmetry.

The answer to this question seems to be "yes, there is a simple way to do this"; see below.
This would afford spectra of the stars as function of the angle in the photosphere under which
these spectra emerge.

But before doing anything about this, HWR (who has chatted with Kareem about this for a minute)
would like to know/understand a few things form the stellar spectra experts (i.e. Anish/Karen):

• Is this actually an established approach, and HWR has just not found the relevant literature?
• How useful would it be to have spectra = f(cos theta) for different (mostly) MS stars, presumably across a wide range of Teff, and a modest range ( - 1.  <[Fe/H]<0.3 ) of metallicities (because bright eclipsing binaries are not that common..)?
• If useful, is it important this for testing models, or mostly for getting more accurate precise abundances? Or is this just a curiosity?
• If it is interesting in some Teff, FeH regime, what regime is the most interesting?

Having said that, here's a stab at the math of doing this "data driven"; in the naive version this seems very interesting.

Gaia DR2 day0 queries cut and paste

# get all stars with good parallaxes and RGC>12 kpc
SELECT top 100000 *
FROM gdr2mock.main
   WHERE
     parallax/parallax_error  > 8.
      AND
      sqrt( power(8.2-(1./parallax)*cos(l/57.29),2) + power((1./parallax)*sin(l/57.29),2.) )> 12.
      AND
     random_index between 1 and 100000



# find the Ophiuchus stream
select *
from gaiadr2.gaia_source
where
l between 1 and 9
and
b between 27 and 34
and
1./(7.2+0.66*(6.5-l)) < parallax + 2*parallax_error
AND
1./(7.2+0.66*(6.5-l)) > parallax - 2*parallax_error

# get all stars with good parallaxes and RGC>12 kpc

SELECT top 100000 *

FROM gdr2mock.main

   WHERE

     parallax/parallax_error  > 8.

      AND

      sqrt( power(8.2-(1./parallax)*cos(l/57.29),2) + power((1./parallax)*sin(l/57.29),2.) )> 12.

      AND

     random_index between 1 and 100000

# find the Ophiuchus stream

select * 

from gaiadr2.gaia_source

where

l between 1 and 9

and

b between 27 and 34

and

1./(7.2+0.66*(6.5-l)) < parallax + 2*parallax_error

AND

1./(7.2+0.66*(6.5-l)) > parallax - 2*parallax_error 

select *

from gaiadr2.vari_rrlyrae left outer join gaiadr2.gaia_source on (gaiadr2.vari_rrlyrae.source_id = gaiadr2.gaia_source.source_id)

select *

from gaiadr2.vari_cepheid left outer join gaiadr2.gaia_source on (gaiadr2.vari_cepheid.source_id = gaiadr2.gaia_source.source_id)

select *

from user_hrix.apogee_the_payne_coords left outer join gaiadr2.gaia_source on (user_hrix.apogee_the_payne_coords.source_id = gaiadr2.gaia_source.source_id)

select *

from gaiadr2.gaia_source 

WHERE 

random_index between 1 and 600000

select *

from gaiadr2.gaia_source 

WHERE 

radial_velocity IS NOT NULL
and 
random_index between 1 and 600000

select ra,dec,l,b,parallax,parallax_error,pmra,pmra_error,pmdec,pmdec_error,phot_g_mean_mag,phot_bp_mean_mag,phot_rp_mean_mag

from gaiadr2.gaia_source 

where parallax > 20. 

select ra,dec,l,b,parallax,parallax_error,pmra,pmra_error,pmdec,pmdec_error,phot_g_mean_mag,phot_bp_mean_mag,phot_rp_mean_mag,radial_velocity,radial_velocity_error,teff_val

from gaiadr2.gaia_source 

where

radial_velocity IS NOT NULL

select ra,dec,l,b,parallax,parallax_error,pmra,pmra_error,pmdec,pmdec_error,phot_g_mean_mag,phot_bp_mean_mag,phot_rp_mean_mag

from gaiadr2.gaia_source 

where parallax > 10.


# select RC stars around sag
SELECT source_id,ra,dec,parallax,parallax_error,pmra,pmra_error,pmdec,pmdec_error,phot_g_mean_mag,bp_rp,phot_variable_flag,teff_val
FROM gaiadr2.gaia_source
WHERE
(l < 20) or (l>352)
and
b between -45 and 25
AND phot_g_mean_mag + 1.27 -1.5* (bp_rp) between 17.1 and 17.6
and
power( (pmra+2.7)*(pmra+2.7)+(pmdec+1.4)*(pmdec+1.4), 0.5) < 0.7

Last Things I did on the ESA Gaia Aerchive before it went down

Selection of Cepheids from PS1 and WISE data

The thought is to use the known sample of 85 Cepheids (with PS1 data) to do explore
by hand cuts.  The basic philosophy is:

1. Cepheids have to appear as bright sources in W1 and W2. Why? According to Freedman et al 2006-ish (LMC-based) even the short-period (2-day) least luminous Cepheids have M_W1 or M_W2 of about -3.55. So, if we consider a DM_max=15 for now, and A_V~15mag (A_W1~0.7mag), then we have m_W1 and m_W2 < 12.5
2. Cepheids have intrinsic W12 colors in a narrow range, -0.07<W12<0.2
   
3. The 84 Cepheids with PS1 data fall into a well defined patch of Hernitschek's variability amplitude omega_best and time-scale tau_best space: 0.08<omega_best<0.5 and 0.7days < tau_best<30days.
   

Taking the test regions from Laura (15' around Cepheids?) , we go from 1Million sources to 220, and still retain 79 of the 84 Cepheids

Note added: a W12 -- (J-K) cut may also be interesting

That leads to a candidate list that is very peaked to the plane

or, as seen on sky:

The file with the candidate sample is n this fits file: https://www.dropbox.com/s/5zoi4o9diip01pg/Hernitschek_catalog_WISEbright_W12-JKcut_omnega-tau-cut.fits?dl=0

Is the next step to run period fitting on these 7000 candidates?

Topcat GPS1 exercises

This is the basic color-color locus of stars

Went to the 30deg around the anticenter,

and picked red stars with low proper motion (RA82DEC0)

among those, there are stars that are very red in r-z. If we pick those they have a distinct angular distribution away from the plane, and in W1 apparent magnitude.

What are they?

If I look at a proper motion selected sub-sample in TGAS, I see

taken  together we see (at 350 pc???

according to TGAS)

What is it?

Puzzlingly the colors are those of giants not dwarfs

Things don't quite fit with a 1Gyr isochrone

Bringing in APASSS settles it; it's a lounging stellar population at 350 pc

That's a query to look at the wide area


SELECT
   *
   FROM gps1.main as ps1
   WHERE
      1=CONTAINS(POINT('ICRS', ra, dec),
                 CIRCLE('ICRS', 82. ,0., 15.))
   AND
ps1.magi BETWEEN 13. and 19.
   and
        (ps1.magg - ps1.magr) between 1.05 and 1.40
   and
        (ps1.magr - ps1.magi) between 1.0 and 2.0
   and
(3.6e6*sqrt( power(pmra,2) + power(pmde,2))) < 7.

This is the spatial distribution of the stars (that don't move and lie on the color-mag sequence)

if we superimpose the much brighter TGAS stars (in red), we get (Y-axis flipped)

What I learned about ADQL queries at the Gaia sprint; WD binaries

Morgan F. ran some tutorial with me on ADQL etc..

the idea is to find WD wide binary candidates that commove with TGAS

stars within 300 pc. Go to TOPCAT;  preload a table of TGAS stars within

300 pc; activate that table and then go to TAP queries; select GAVO; select gps1; 

Then:

SELECT

   TOP 10000  *

   FROM gps1.main AS db

   JOIN TAP_UPLOAD.t2 AS tc

   ON 1= CONTAINS(POINT('ICRS', db.ra, db.dec),

                 CIRCLE('ICRS', tc.ra, tc.dec, (10.3*tc.parallax/3600.))) 

   WHERE  db.e_pmra * 3.6e6 < 5. AND db.e_pmde * 3.6e6 < 5.

AND

                 SQRT( (power(tc.pmra-db.pmra*3.6e6 , 2) + power(tc.pmdec-db.pmde*3.6e6 , 2)) /

                 (power(db.e_pmra* 3.6e6,2)+power(db.e_pmde* 3.6e6,2)) ) < 5

Morgan's version of that query yielded nice results.