-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat(psp): Composite PSP #301
Conversation
521adf3
to
9b130a3
Compare
Note to self: failing because of patrick-kidger/diffrax#412 |
feb7731
to
25cce1e
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #301 +/- ##
==========================================
+ Coverage 94.38% 94.88% +0.49%
==========================================
Files 60 62 +2
Lines 2351 2404 +53
==========================================
+ Hits 2219 2281 +62
+ Misses 132 123 -9 ☔ View full report in Codecov by Sentry. |
|
Signed-off-by: nstarman <nstarman@users.noreply.github.com>
The followup to this PR is to let the DF determine the PSP type. So FardalDF would produce MockStreamArm. A CoreSprayDF would produce a PSP (or some other class). The whole thing gets wrapped up into a MockStream composite object (which we might want to rename as well?). |
Signed-off-by: nstarman <nstarman@users.noreply.github.com>
This PR allows for PhaseSpacePosition that are composites of other PSPs.
A composite PSP acts like a single PSP but is a dictionary of PSPs.
This is structurally similar to CompositePotential.
In particular I apply this to MockStream so that we have distinct leading and trailing arms. Rather than doing a stepped slice index to find each arm, it's just a
mockstream["leading"]
getitem. When accessing the composite properties, e.g.q
it's just interleaved in the concatenation by the release-time.Having a composite PSP means it will be easier to support other star ejection mechanisms from progenitors, e.g. 3-body encounters. Then we'd have
mockstream["threebody"]
.The alternative to this PR is to have a string label list on on the mockstream. I don't think that's as clean (since we will need to always ensure that slicing and ordering is maintained), but it is maybe simpler.Thinking more, perhaps the string label list approach is the best thing to start with? But then we should really clean up the df sampling logic happen in mockstreamgenerator.