Difference between revisions of "Getting your feet wet with catalogs and plots at IRSA Hints"

From CoolWiki
Jump to navigationJump to search
m
m
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
Hints/Answers for some of the questions in [[Getting your feet wet with catalogs and plots at IRSA]]
+
'''Hints/Answers for some of the questions in [[Getting your feet wet with catalogs and plots at IRSA]]''' -- don't read until you've really tried to figure things out on your own!
 +
 
  
 
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!
 
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!
Line 6: Line 7:
 
'''meaning of dist_x column:''' 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).  
 
'''meaning of dist_x column:''' 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.
+
'''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. EDR3 does have GBR, and parallax, but BOY that is blue. I don't think it's really finding Alpha Cen! Need to dig into literature to find someone else who has found the EDR3 counterpart to Alpha Cen. This is really turning out to be a MUCH harder question than I thought!
  
 
'''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 [https://iopscience.iop.org/article/10.3847/1538-3881/aae9ec 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!!
 
'''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 [https://iopscience.iop.org/article/10.3847/1538-3881/aae9ec 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!!

Latest revision as of 17:48, 5 October 2022

Hints/Answers for some of the questions in Getting your feet wet with catalogs and plots at IRSA -- don't read until you've really tried to figure things out on your own!


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!

meaning of dist_x column: 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. EDR3 does have GBR, and parallax, but BOY that is blue. I don't think it's really finding Alpha Cen! Need to dig into literature to find someone else who has found the EDR3 counterpart to Alpha Cen. This is really turning out to be a MUCH harder question than I thought!

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!!

Gliese-Jareiss vs. Taurus. The nearby stars aren’t generally young, and the Taurus stars are all young. Ages are hard to get for stars if they’re not in clusters, but really none of the nearby ones are as young as Taurus age. Looking at the range of distances in the GJ catalog, the most common distance is ~20 pc (the catalog is supposed to be within 20 pc), and the most distant is something like 45 *kpc*. Taurus is at ~140 pc. The GJ catalog was assembled based on things people *thought* were nearby based on their apparent brightnesses.

Points below the MS. The error on those photometric points is large, so they appear erroneously below the MS. The B band is particularly subject to errors. (Remember the shape of a dust-free star, e.g., the blackbody curve – these things are going to be faint at B!) If you do G vs. G-R CMD, they’ll fall into line.

Why reverse the y-axis? For a CMD, you want the bright objects at the top. Magnitudes are "backwards" in that small numbers are bright. So reverse the y-axis to put bright objects at the top. Don't reverse any axis when it's a color-color diagram. You want blue objects to be at the bottom or left and red objects to be at the top or right.

What is going on with the WISE GJ plot?? Yes, this is a complicated plot! :) There is more than meets the eye here, in both plots, and some complicated non-astrophysics effects at both the bright and faint ends. For GJ: We’ve just pulled the matches, we’ve not vetted anything. So the catalog has obediently given you back what you asked for – “do you have matches at this location?” “Yes, I do have matches at this location; here.” It also did, in fact, tell you in the catalog that things brighter than [w1]~3 or 4 are saturated (the ph_qual flag!). But we’ve not paid attention to that at all, because I didn’t tell you to look for it. So, everything brighter than [w1]~3 or 4 is saturated in w1 (but not in w4). So the “main sequence” which should be at w1-w4~0 veers off left (and does even wackier things past w1~0 as w4 also saturates) because the measurements at w1 aren’t reliable brighter than that. So you’re absolutely right to be suspicious of the MS that isn’t vertical! Now, what’s up with the lower end? Because down to mid-M, that too should be w1-w4~0. What’s happening is that the W1 detections fall off after ~9 or 10 mag. So in order for anything to even be detected at all for things that are intrinsically fainter than w1~9 or so, it has to be brighter than a photosphere, e.g., it has to have an excess. So the lack of points down near w1~15, w1-w4~0 is entirely a result of instrument sensitivity. There are really sources that live there, we just can’t detect them given this catalog. Something that has a big excess is rare. Small excesses are more common, so you get that sensitivity line sort of traced out. (also true that when you go down past mid M, even disk-free photospheres will have w1-w4>0.) That is what you see in both plots, actually. The blob at w1-w4~0 at a variety of brightnesses doesn’t exist in Taurus because very few of the Taurus stars have no IR excess at these bands. There are some, though, just not many bright ones. And the Taurus catalog is vetted, so there aren’t any saturated things in that catalog. And Taurus has plenty really big excesses (whereas GJ has only a very few).

Why not IRAC? Check the units... Can you figure out how to fix them? or approximately fix them?