-
Notifications
You must be signed in to change notification settings - Fork 13
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
From initial conditions to geodesic #37
Comments
Number 2. can be done in closed form analytically at least for bound/unbound orbits. For plunging orbits the p,e,x parametrization breaks down anyway. |
How exactly? I know only of one method, and that is finding the roots of the R(r;E,L,Q) polynomial - and that one is a quartic. (The Schmidt method gives only p,e,x -> E,L,Q, not the other way around afaik.)
Sure. I guess this is a nuance, but given numerical data the roots may jump around in an unexpectedly large band around the separatrix. Having discrete jumps due to root indexing is way worse than just getting a noisy inaccurate result. |
The four roots of a quartic can be given in closed form. Using the value of E, Q, and the discriminant of the radial potential, you can determine which of the four roots to use (or whether the orbit is plunging). With a bit of effort, you can get a closed form expression for the two roots that define p and e (for non-plunging orbits). Alternatively, given numerical input, you can evaluate all 4 and pick the two that bracket the initial position. |
I've written a prototype function, which takes initial data as input and produces (a,p,e,x). |
Ok, I see. Here is my jab at it as well. First step:
Second step using
I assume that Mathematica recognizes the quartic and uses an analytical formula when using |
Leaving it as |
An alternative would be the nighborhood representation of
Of course, for that one would first need to obtain sufficiently accurate/stable guesses with |
My version (works for bound and scattering orbits): Step 1:
Step 2:
With a bunch of explicit definitions:
|
Cool, I created a branch |
Ok, pull requested, for more see https://github.com/VojtechW/KerrGeodesics/tree/InitialConditions. |
At the mini BHPToolkit workshop at UCD last week we merged this branch into master. After some discussion we decided we should extend the work from only applying to KerrGeoOrbit to apply to all functions. A preliminary, and very hack-y version of the code is now in the With this you can do things like KerrGeoFrequencuies[0.9, "ELQ"->{0.96, 3.1, 2.3}] I still need to hook in the initial data code (hopefully later this week), and then we need to think about parametrizations for non-bound orbits so we can finally merge the plunging orbit branch from Conor. Also, looking back at Vojtech's original post and Maarten's follow up regarding point 2, is the analytic function we use to get (p,e,x) from (E,L,Q) the same as what Scott has in his note: https://arxiv.org/abs/2401.09577? |
Scott uses the standard formula for quartic roots, but as Leo noted, this formula can apparently be numerically unstable at certain critical points (I assume at transitions between various types of motions). What we do is let Mathematica handle these issues by simply using Solve, and then sorting the roots by their real parts. The only trick on top of that is the computation of the discriminant of the quartic, which classifies the motion (bound, vortical, plunging). |
Almost anyone who comes to the KerrGeodesics package without knowing that much about Kerr geodesics expects it to do the following:
Currently, this is actually not implemented in KerrGeodesics, since
KerrGeoOrbit
gives you a geodesic based on p,e,x and initial orbital phases.The easiest way to implement the initial-condition approach would be to
KerrGeoOrbit
.Point 1. and point 3. are easy to do in closed form.
However, point 2. cannot be done fully analytically. The x parameter is a quadratic root. The p,e parameters are then obtained by finding the two "correct" roots of a quartic. For this, one could trust the Mathematica function
Root[]
. The issue is with indexing the roots, sinceGiven numerical initial data, this could make the algorithm make discrete jumps due to indexing changes near transitions between bound/unbound/plunging. But I guess such an implementation is a good start.
Any other thoughts?
The text was updated successfully, but these errors were encountered: