Closed soichiro-hattori closed 9 months ago
I think your point about what we want the semantics of this operation to be for 1 vs. multi-planet systems is a good one!
My feeling is that at a high level we want to support orbits with different "shapes". For example we could have an orbit with shape ()
(a scalar), which just has one planet, or an orbit with shape (1,)
which also has only one planet. In these cases, I would expect the shapes of the light curve to be (len(t))
and (1, len(t))
respectively.
But, that thought really just pushes the question up a level to a discussion of how we handle shapes in multi-planet orbits...
So, basically I have no good answer!
Okay that's the current behavior anyways! I think this PR is ready to be merged. @dfm are there other changes that need to be made before that happens?
Great - I've sent this to the merge queue! Thank you!!
New PR to replace old PR #113. Changes were made so that these commits are independent from the
tutorials
branch changes.Same text as PR #113: This PR resolves Issue https://github.com/exoplanet-dev/jaxoplanet/issues/112 so that the light_curve() method works for multiplanetary systems.
I think we should think a bit more about whether we want to squeeze the output array into 1d when there's only one body or to always return an array of shape (N_bodies X N_time) even if it's only one body. The first option might be a bit more intuitive but the second option allows us to streamline our code since the more general code of handling more than one body will work even if only one body is passed.