Getting your feet wet with catalogs and plots at IRSA Hints

From CoolWiki
Revision as of 22:17, 16 May 2022 by Rebull (talk | contribs)
Jump to navigationJump to search

Hints/Answers for some of the questions in Getting your feet wet with catalogs and plots at IRSA

Making the search radius arbitrarily larger runs the risks of matching the source inappropriately with a star that just happens to be there in the field of view, not the actual match to the star in question. However, some of these stars have high proper motions, so in some cases, you may need a large search radius to find the match!

The columns "cntr_01", "dist_x", "pang_x", "name_01", "ra_01", and "dec_01" are pre-pended onto the catalog results by the catalog search tool. the "01" are inputs from your input catalog -- cntr is counter, ra is right ascension and dec is declination. dist_x and pang_x is the distance between your requested position and the position of the source it found in the catalog, and the position angle (in degrees east of north). It does this so that you can make plots or write code to assess whether it's making good matches. For example, you can plot ra on the x-axis and dist_x on the y axis to see if there is something systematic off with your coordinates (I have done this before to find systematic errors in positions).

Alpha Cen is in the list, but it's complicated. If you use SIMBAD to search on Alpha Cen, you don't seem to get a HIP or Gl/GJ number, which is weird. The ICRS J2000 coordinates SIMBAD gives are 14 39 29.71993 -60 49 55.9990, which converts to 219.87375, 60.832222 (both in deg). I can filter down the GJ catalog in the Gaia IRSA results by filtering ra_01 to be "> 219 and < 220" and dec_01 to be "< -60.83". That leaves 3 stars, none of which match dec= -60.832 really closely. And that’s where the super high proper motion comes in - it’s likely moved enough that this isn’t the way to find it. I used Finder Chart to search on “alpha cen” and let SIMBAD resolve the coordinates, but had Finder Chart pull the catalogs for the whole image. The star has clearly moved. The 2MASS counterpart is J14393592-6050069. The original table in the original Stauffer et al. paper lists all the 2MASS counterparts they found, from which I can extract the relevant two rows from their table, which means that Alpha Cen A = Gl 559 A = HIP 71683 and Alpha Cen B = Gl 559 B = HIP 71681. In the automatic matching to Gaia DR2 that we did, it managed to find a hit (by chance perhaps?) to HIP 71683. This star’s entry in Gaia (DR2 anyway) has no parallax, or B or R measurement, so it doesn’t show up in the CMD. And without that information, it’s hard to know right now if this is a by-chance hit or it is really matching Alpha Cen. I think it will have EDR3 data, so we will check again then.

Binaries. Things in the list with names that are xxxA or xxxB are resolved binaries, e.g., the “A” is one component and “B” is another, and the fact that they are in the list separately means that they are resolved into two components. Things that are in the list as xxxAB are unresolved, e.g., we know that there are two stars there, but we can’t resolve them into two given the catalog as it exists currently. Unresolved pairs that are equal mass binaries (or close to it) will both have the same color, but will be twice as bright. So in a CMD, they’ll be at the right color (on the x axis) but too bright for a single star (on the y axis). So they often trace out a second MS, higher than the rest of the MS. In some cases (like figure 2 here), binaries are superduper obviously above the rest of the main sequence. When I constructed this question, I had spot checked a few of the “AB” stars in the GJ list, and they were indeed above the rest of the pack of stars. So I thought this was going to work. But it doesn’t work for all of them, and the reciprocal definitely doesn’t work (e.g., clicking on some of the high stars in the MS does not yield stars with AB names). Sigh. Here I thought I was being so clever!!