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

To Do #3

Open
3 of 12 tasks
moble opened this issue May 31, 2022 · 0 comments
Open
3 of 12 tasks

To Do #3

moble opened this issue May 31, 2022 · 0 comments

Comments

@moble
Copy link
Owner

moble commented May 31, 2022

  • Add cubic-in-spin terms
  • Change quiet to more fine-grained verbosity, and pass along verbose argument to DiffEq solve. Maybe just loglevel would be adequately fine-grained.
  • Add more example systems — e.g., GWTC function that returns something like the system in question
  • Collect citations in bibtex form using DocumenterCitations.jl
  • Clarify the meaning of TaylorT4/T5 in terms of "Formal power series of logarithmic type". In particular, note the "augmentation" as an alternative to evaluation at zero. Or maybe just something simpler with residues.
  • I think a slight extension of LabelledArray.jl is what I need; SLVector is almost it, but we also need the PNOrder ot be a type parameter. Look into using StructArrays.jl for the integration, so that each time step may be a StructArray. Rather than having to re-interpret / reset the sol.u field as a PNSystem, StructArrays would do this automatically, which may lead to more threading opportunities. Alternatively, ComponentArrays.jl may be the way to go.
  • Support eccentricity
  • Switch to using S instead of chi, since this is what Alvi uses; it's easy to convert to chi, but more complicated to convert back if M is time-dependent. Also, it makes me nervous that maybe I'm making a mistake about dimensions somewhere, so this could be a good opportunity to check dimensions.
  • Think about Unitful+ComponentArrays
    See this comment et seq. for examples, but note that it can be slow for vectors with heterogeneous units. One workaround mentioned in that thread is to define a Union type, though it's still slower than without units. Maybe things are better by now.
    Maybe just accept unitful inputs to orbital_evolution, strip the units internally, and then replace the units on output.
    It would be interesting to analyze the BBH problem in terms of Buckingham's π theorem.
    Also note the package Dimensionless.jl. This actually goes the opposite way that I would go; I kind of think we need a Dimensionful package to deal with the fact that we have quantities with different dimensions that may nonetheless be measured in the same units when we use geometric units — e.g., when we measure the solar mass in microseconds or kilometers rather than kilograms. Also:
    - It couldbe helpful to formalize things a little more with Huntley's extensions and/or Siano's
    - Maybe account for affine-vs-vector quantities of each dimension
    - Support natural units (hbar=c=1) as well as geometric units (G=c=1)
    - Terence Tao has a writeup that's presumably up to his excellent standard
  • Re-enable support for TaylorT4/5
  • Redefine NS coupling as normalized parameter so we don't have to divide by M^5.
  • Check plotly-Firefox issues here and here. That's what's used in the docs, which will have squashed legends for Firefox users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant