benmontet / k2-characterization Goto Github PK
View Code? Open in Web Editor NEWStellar/planet properties and confirmation of some K2 planets
Stellar/planet properties and confirmation of some K2 planets
so as to be able to compare immediately w/ "Max Depth"
Dan Huber claims 201257461 and 201929294 are giants. The former has a logg from RAVE which is consistent with a halo giant, while the latter comes from reduced proper motion.
This might explain some of the weirdness in the fit for 201929294. @timothydmorton, what's the upper mass limit in the Dartmouth isochrones as you use them? It looks like the default is only a couple solar masses, so if these are giants, they might just not be in the parameter space covered by Dartmouth models.
@benmontet, in the FP section, you talk about calculating the "maximum depth" that a background star could produce in a diluted scenario. Presumably you're calculating this by assuming the total flux in the aperture is F_target + F_other, where F_other is the total flux from the other star, and that F_other dims by 50%?
The problem with this is that F_other should not be the total flux in the other star but rather the flux in the aperture, which may be only a fraction of the actual flux from the background star (e.g. if only the wings leak into the aperture). So unless you know that the aperture is actually fully containing these stars, then that number won't be right.
@timothydmorton is there anything that needs to go into the paper for these? Should their presence in the ASCL be cited? Or not since this is the first time they're being presented?
hey-- just fyi, for some reason the FPP table is now having some formatting error... i can't figure out where it's coming from, but just wanted to let you know that's where the current latex error comes from...
We have two estimates of the stellar parameters from photometry (using two different stellar evolution models).
There is statistical noise (from the photometry) leading to uncertainties in the physical parameters.
Each model also comes with its own (unknown) systematic noise.
Any thoughts on the best way to combine these into one posterior that includes the statistical noise and some honest assessment of the level of systematics influencing our values?
See the figure in this repository from group meeting today for a picture of what our stellar properties look like in the two models for clarity.
Let me know any notes/annotation/etc. that you think should be in the FPP table (e.g. special notes for particular candidates). I generate it automatically, so best for me to edit the script rather than to edit the .tex directly.
@benmontet needs to read the paper to look for any weird tense issues that may have snuck in.
I've added a notebook where I use the values from dartmouth_params.txt
and my MCMC samples from Paper 1 to measure the properties of the 2 planets from Crossfield et al. It looks like I'll need to take longer chains in order to fully sample the distribution but it doesn't look too bad so far. The results are more or less consistent with what they get even though the stellar parameters in our table are somewhat different than their spectral results.
I'll add some text to the document next.
Link: http://nbviewer.ipython.org/github/benmontet/k2-characterization/blob/master/planet_properties.ipynb
I'll need the following for each candidate. Some of these are in the Paper 1 table, but others aren't. @dfm, ideally the photometry would be able to be machine-grabable (via either ketu or kplr?) so that I can build the K2 submodule of my FPP code to be as generally useful as possible (i.e. be able to give an EPIC ID, period, and epoch, and get the requisite phase-folded/detrended photometry). In the meantime, old-fashioned files/tables are OK, too, since there's only a few dozen we're working with right now.
Hey @dfm-- for some reason I can't open your .h5 files using pandas, and they show up empty...any idea why? See here.
Specific things we need:
It's my intention to send it off to all coauthors at the end of the day Thursday. We don't have to have all of these things checked off by then, but the more the better. I think having all of mine done by that point is doable, and if we can at minimum have the planet properties table and the text for that section done too, that would be ideal.
I've been hacking on trying to include dilution effects into the planet parameters and I don't think that I can do it without resampling the posteriors conditioned on this model. I'm coming around to the opinion that maybe it's actually just better re-run the MCMC chains when we settle on a final set of stellar parameters…
Another point: so far, I've been taking Tim's samples for the stellar parameters and approximating the distribution using a KDE. What do you guys think about just using the multivariate Gaussian instead? We're artificially inflating the errorbars anyways and it seems to me like the Gaussian would capture all the relevant structure. It would be easier to work with :-) Opinions?
@benmontet - I'm focusing on 201912552 to try to understand what's up with my stellar isochrones code. My MCMC stubbornly wants to give it a ~9000K temperature, which we know is absurd.
I'll be working on this by putting together some diagnostic plots showing samples & evolution tracks, but this will take some setup; in the meantime, any thoughts you have on this would be welcome.
Okay @dfm, I'm done sucking...your turn!
I need a table of planet properties, based on the latest stellar parameters, to replace Table 3. I can update dispositions, but the other columns are all you.
Hey folks-- So I re-ran the FPP calculations (shown in new table now)... but take these with a grain of salt until I fix some stuff that needs fixin'. For example, you may notice that I seem to have un-validated our prized candidate....
Have we settled on what all the data is that we're going to put up for this project? For me in particular, I think I'm going to want to put up a tar file of all the FPP-related data on zenodo (this will include the starmodel fits). Probably makes sense to combine everything into one zenodo archive.
There are a few stars that, based on their photometry (esp r-J,J-K) I would guess are more massive than the Sun.
Indeed, our stellar parameters table has Teff > 5760 for these, but this is converted into a mass of ~0.8 solar and a metallicity of ~-1 dex.
What specifically is going on here? Are we sure these aren't F stars that we're messing up somehow?
The particular EPICs are 201295312, 201403446, and 201779067; there are a few others that are close to falling in this category (201613023, 201384232, 201393098)
Just opening a general issue here; I believe I have finished my contributions to the text. In addition to the FPP table, these are mainly in Section 4, where I've done some re-organizing, a paragraph in the conclusion, and small edits to the abstract. If there's any chance we could submit before the deadline today (i.e. in the next 90 minutes), that would be fantastic; that way I could present at coffee tomorrow at Princeton before leaving for a week. If not, no worries, then I'll talk about it at Caltech on Monday!
@dfm, do you think that you could provide me with a table of aperture sizes that you use for the photometry? Right now I'm just randomly assuming an 8" confusion radius for BG objects for the FPP, but there's no reason I couldn't just use the actual sky area covered by the aperture.
I wonder whether any of the stars that show signs of bi-modality in the MCMC photometry fits are actually binaries... cross-check the following with the AO observations:
201367065
201393098
201445392 (not clear bi-modality, but funky-looking)
201546283
201569483
201596316
201855371 (*if this is a binary, I love it.)
201929294 (ditto)
We are saying that we know 201555883 is a period-epoch match with a known EB (201569483). How deep is the EB signal? What is the relationship on the detector b/w these two stars? Are they close by? On the same CCD column? How closely are they matched?
Details are important because my FPPs say "planet."
And have we checked for other period-epoch collisions among our detected signals?
I think the following is all we need:
I'd love to have this out to everyone as soon as possible and submit by the end of the weekend, before we get beaten to too many other confirmations.
To that end, I think we should proceed as if we will not have any contrast curves, and be pleasantly surprised if that changes.
Let me know what I can do to help each of you tick off your boxes as efficiently as possible.
This is similar to other things we've talked about, and this is a system we talked to Roberto about a while back---this is definitely stellar variability that's being captured by the transit algorithm. In photometry it's totally just slow starspot modulation, with no 2% transit signal. This should definitely be considered a FP.
I've now run new StarModel fits (using MultiNest rather than emcee), and the corresponding new FPP calculations. The new fit results (still based on the 3x inflated photometric errors) are up at www.astro.princeton.edu/~tdm/k2/starmodels.
I'm not sure the best way to communicate these results, as some of the fits (like 201384232) are multi-modal. @benmontet, take a look at these and think it over. One thing I found interesting was that 201257461 and 201929294, that Dan Huber said were giants, actually now both look like giants from the photometry.
The FPP results change only slightly, but a couple things shuffle between planet/candidate status. Fortunately, I don't think anything went from being a planet to being a FP, which is good. Sometime relatively soon I hope to get around to updating the paper text. Please poke me if you want me to do it quicker.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.