search

exoplanet-dev / exoplanet

Fast & scalable MCMC for all your exoplanet needs!
https://docs.exoplanet.codes
MIT License
206 stars 52 forks source link

Luminosity of secondary #45

Closed christinahedges closed 4 years ago

christinahedges commented 5 years ago

Using exoplanet is great! I'm now wondering, starry has the capability to make the secondary luminous, meaning that it will automatically add secondary eclipses, and phase curves. Is this functionality preserved in exoplanet? How can I add secondary eclipses to my fit exoplanet model?

Many thanks! C

rodluger commented 5 years ago

@christinahedges Currently only stellar limb darkening is implemented in exoplanet. I'm hard at work at the new release of starry, which will make all of the code's features play nice with exoplanet. I'm hoping to release it this summer. At the very least, I can probably show you how to do it with the (undocumented, possibly slightly buggy) dev version.

christinahedges commented 5 years ago

I would love to learn! Especially if it will help me learn how starry works. Is this something we could set up a v. short skype call about so I can pick it up?

danhey commented 5 years ago

Hi all, I'm also very interested in this functionality! Please let me know how I could learn more :-)

rodluger commented 5 years ago

@christinahedges @danielhey Just a heads up that I'm still working on this. I'm putting together a notebook with a sketch of how things will work in the next release of starry, and I'm hoping you guys (and anyone else!) can help me test it. I'll keep you posted -- hopefully I'll have something for you later this week.

christinahedges commented 5 years ago

Very excited to test this!!

exowanderer commented 5 years ago

I just want to add my voice to the motivation for an eclipse fitting tutorial using exoplanet + starry. It would be wonderful!

Question: Does it make sense ('enough') to use exoplanet in transit fitting mode with u=[0] and r = np.sqrt(e_depth)? I did that and the results 'feel' okay.

rodluger commented 5 years ago

Hey @exowanderer, check out this tutorial. You'll need to install the dev version of starry and make sure you have the latest version of exoplanet. I'm still working on this new version, so things are likely to change slightly before the next release (which I'm hoping will be in the next month or two).

rodluger commented 5 years ago

As for the hack you suggested, that seems fine, but you won't be able to model any brightness structure on the surface of the planet that way.

exowanderer commented 5 years ago

Hey @exowanderer, check out this tutorial. You'll need to install the dev version of starry and make sure you have the latest version of exoplanet.

[Note:] I will probably make this an issue (or PR?) on the STARRY github page; but it is directly relevant to anyone trying to use starry's dev branch for eclipse observations; i.e. this issue on exoplanet.

I was able to properly install starry's dev branch and run 2 of the notebooks (the only 2 that I tried); but it required some editing of the setup.py file for two independent reasons:

exowanderer commented 5 years ago

Modifications to setup.py: add find_packages

I had edit the setup.py file, such that the ops submodule would be included in my env's site-packages directory.

To do this, I followed suggestions this SO thread. Namely, that I could

(1) import the find_packages module as from setuptools import setup, Extension, find_packages (2) use the find_packages in the setup call, as packages=find_packages(). This replaced the previous entry of packages=["starry"].

After this, I was able to import starry at all !

[Sidenote:] In case it's relevant, I started with an install of exoplanet (v0.2.2) using the auto_exoplanet.yml in the exoplanet repo; i.e. I ran conda env create -f auto_environment.yml in the docs directory; then I installed the exoplanet v0.2.2 from this repo (master branch). Then I created a new env using conda create -n autoeclipse --clone=autoexoplanet.
I say this so that my environment's package versions are all apparent and documented.

exowanderer commented 5 years ago

Modifications to setup.py for ops.py: add packaging to install_requires kwarg

The ops.py file includes a check at the top of the file for the version exoplanet; but it does so by using a package called packaging, which is not a default install for anaconda environments [any envs(?)].

As a result, I had to install that manually; i.e. conda install packaging. This obviously is a trivial fix; but I wanted to suggest adding packaging to the install_requires kwarg under the call to setup in setup.py.

Without packaging in the site-packages directory, the try: at the top of the ops.py fails, which sets exoplanet = None. Following which, the assert on line 998 of ops.py triggers with an error about the version number of exoplanet, even though I have a higher version of exoplanet installed than is required; I have exoplanet == 0.2.2, ops.py requires exoplanet >= 0.2.0.

exowanderer commented 5 years ago

Testing Notebooks:

(1) EclipseBinary.ipynb notebook worked; but the pm.sample step took way too long; so I stopped iterating. I have 16 cores, but tqdm reported that the 4 chains were going to take ~5 hours to complete. This is likely because the model has ~35 parameters in the "Ylm" from the map_soln.

(2) HotJupiterPhaseCuve.ipynb notebook worked great, including processing through the pm.sample. This is probably the exact notebook that I need to follow. I'm doing a simple eclipse fit at the moment; but I want to iterate the MCMCs with exoplanet+starry for speed and (soon) to include celerite for GPs.

exowanderer commented 5 years ago

Finale

I am wicked enthusiastic about the work that you're making for STARRY v1.0. I see that you are including the use cases for transiting and eclipsing exoplanets + phase curves. I tried to hack this together with STARRY v0.2 (with lots of help from you); but I never got it to perform with physically meaningful behaviour -- mostly in the edge cases. Your notebooks perform a lot better than my trials back in Spring!

I still do want to ask: Given the new layout for STARRY, with Maps are arguments to Primary and Secondary instances: How can we use the final results of the MAP or MCMC to compute the Eclipse Depth? Inside the existing system, it seems that all of the objects are either Theano TensorVariables or TensorConstants.

Thank you (et al.) for such great work!

rodluger commented 4 years ago

Hi @exowanderer, thanks for all the feedback. I've made the recommended changes on the dev branch of starry. Can you try running the Eclipsing Binary notebook again, and let me know if it still takes an unreasonable amount of time? Currently on Azure it's taking 1m30s to run the sampling.

rodluger commented 4 years ago

As for your other question, you can typically call the .eval() method of a Theano tensor to get its numerical value. Things can get weird, though, inside of a PyMC3 model, so @dfm wrote this convenience method to help out. I could probably give you better pointers if you told me the specifics of your problem; perhaps share your notebook?

rodluger commented 4 years ago

Finally, a heads up to anyone following this thread. As of early November, I'm developing starry version 1.0.0.dev6 on the dev branch of https://github.com/rodluger/starry. It's mostly finished, and I'm hoping to release version 1.0 in the next month. Check out the current docs for info on all the features I've implemented so far, including tutorials on how to integrate starry with exoplanet to model luminous secondary bodies.

I'm closing this issue at this point. If you have any other questions or feature requests, please open another issue, preferably in the starry repo itself.