search

Starfish-develop / Starfish

Tools for Flexible Spectroscopic Inference
https://starfish.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
69 stars 22 forks source link

support for binary star modelling #68

Open EdGillen opened 8 years ago

EdGillen commented 8 years ago

Currently the code can model single stars with starspots @gully (with a single temp. and fill factor). We (@tofflemire, @gully and @edgillen) want to extend that to do full modelling of intrinsic (e.g. logg, Teff) and extrinsic (e.g. vsini) model parameters. This would describe double-lined binary stars.

The main changes would be to update_theta.

iancze commented 8 years ago

This is very exciting! I have been monitoring the progress over at https://github.com/gully/Starfish/tree/mix_model_omega2 (and #CS19 in general), and it seems as though you all have made significant progress in implementing a binary model.

As you mentioned, the primary changes would need to be in the update_theta step. Do you have any running examples yet, on either fake or real data? How does the computational time scale? One of the difficulties I was worried about was that the parameter range of the spectral emulator would need to be expanded to cover the parameter range of both stars, making it a lot slower to tune.

gully commented 8 years ago

Hi all, a little follow-up:

We successfully wrote and compiled the double-lined spectroscopic binary code at the Cool Stars 19 Hack Day. It was exciting.

Our approach was a bit simplistic- lots of copying, pasting, and tweaking existing lines of code to hack a second spectrum component. A more elegant approach would have been to abstract-away some of the _2's into something more general-- N components, classes, etc. But it was a hack day and our singular focus helped us achieve the goal at the expense of violating DRY (Don't Repeat Yourself). So the code should be considered experimental.

At the Hack Day wrap-up/demo we showed the first 20 samples of a 40-walker emcee MCMC chain, just for proof-of-concept purposes. I've moved that notebook to a place-holder location in the starfish-demo repository, it is "demo10": https://github.com/gully/starfish-demo

The sampling actually halted shortly after the 20 samples, so that should be looked into...

The next steps would be to demo the code on either some real spectroscopic binary data, or synthetic data constructed for the purpose of recovering "known" or "injected" stellar parameters to convince ourselves that the machinery works. It could be fun to add a fake binary to an existing real data spectrum, for example.

Ian's point about training the spectral emulator should also be considered for real-world applications. Simultaneously modeling an A-star and an M-star would be infeasible. Near-equal mass binaries should be fine, I suppose. Another approach would be to train isolated islands of parameter space and alter the code to emulate the two spectral components from these isolated ranges. Needless to say this isolated islands approach would require some thinking about the implementation that I have not done.
Related task-- experimentally determine the complexity of training the spectral emulator. I have a coarse intuition that training the emulator is much slower for larger ranges because there are many more eigenspectra weights in the kriging step, but I haven't quantitatively assessed the scaling with N_spectra from the model grid. Anecdotally, the spectral emulation for a large (3000 - 4200 K) range in Teff performed well enough to see two-component photospheres in my starspot work.

gully commented 7 years ago

Support for binary modeling has largely been superseded by this new package that supports radial velocity variations from multiple components. The only reason I can see for adding support for binaries in Starfish would be if you had only one epoch available, since much of the value from PSOAP comes from access to multiple epochs.

https://github.com/iancze/PSOAP

Unless someone objects I propose to close this issue.

iancze commented 7 years ago

I don't know about closing this just yet. While the GP framework in PSOAP is certainly complementary to Starfish, it is purely data driven, meaning it never touches physical models of the star, which are necessary for determining Teff, log g, etc...

Certainly aspects of PSOAP could be borrowed to use in Starfish, but I would be in favor of leaving this issue open for now.