Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider models with planet identifiability #27

Open
j-faria opened this issue Jan 14, 2018 · 5 comments
Open

Consider models with planet identifiability #27

j-faria opened this issue Jan 14, 2018 · 5 comments

Comments

@j-faria
Copy link
Owner

j-faria commented Jan 14, 2018

That's probably not the right word, but we might want to assign specific priors for a given planet (for the orbital period if detected with transits for example).
I started working on this adding a integer id argument to the RVConditionalPrior::from_uniform and to_uniform but:

  • not sure if there is a better way to go at it
  • log_pdf also needs access to id
  • this might make setting the priors very complicated...
@eggplantbren
Copy link
Collaborator

IMO, a much better way to go about this is to

  • Identify regions of planet parameter space, after the fact, that the user is happy to use to identify a planet.
  • Allow the parameters of that planet to be extracted by conditioning on one planet being in that region.

@j-faria
Copy link
Owner Author

j-faria commented Jan 14, 2018

By "after the fact" you mean a posteriori, after running the analysis?
Doesn't that assume that you somehow managed to find the planet already?

I have to say that I've been debating this option for quite some time. A few people asked me if kima could do this, and I'm always inclined to tell them "no because it's probably not a good idea". But then the answer is "the planet transits, we know it's there and we know its period!"

@eggplantbren
Copy link
Collaborator

Yes, I meant after running kima.

If there is prior information about specific identified planets, I could imagine incorporating that into the kima prior by modulating the existing prior by conditioning on N>=1 and modulating the existing prior by something like exp(-0.5*pow(period[0] - p, 2)/var).

@eggplantbren
Copy link
Collaborator

I don't think this should be for the current release. That level of customisability will require a lot of effort put into how we are going to implement it and make it user friendly.

@j-faria
Copy link
Owner Author

j-faria commented Jan 14, 2018

I agree

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants