Numerical: Up BC Improvement for High L

[thompsonphys]

The current BC code for the Up solution may struggle when the orbital index grows to be large, e.g. for . The idea would be to add two changes to improve this behavior:

• Implement radial-stepping functionality, where the recurrence loop will increase the evaluation radius when the loop doesn't converge within an appropriate number of steps.
• Improve the starting Ansatz for the Up BC evaluation. Currently this is fixed at , but this outer boundary is not necessarily appropriate again for high , as the potential grows as . Further, this choice is maybe too large for low , and moving the outer boundary inward would improve the speed of the code.

I've got a tentative change in the works, but was wondering if anyone has any comments/ideas.

[barrywardell]

Another possibility would be to use the MST series to set boundary conditions. That should be convergent at any radius.

[thompsonphys]

Yeah, I was thinking an "MST" option under the boundary condition choices would be a nice addition. The question is then about balancing speed vs. accuracy, I suppose. I'm not familiar with how long it takes to evaluate a mode object with MST compared to the numerical integration, but I could imagine that getting the boundary data using MST closer to the orbit would win out over using an asymptotic BC farther away only above a certain numerical precision requirement. Certainly something to test.

[nielsw2]

I think the MST series converges very rapidly at large radius so it would work but we'd need to test it first. Also issues around precision as MST typically needs high precision but the numerical integration does not. For eccentric orbits our plan was to have the default using MST to compute the solution at, say, rmax and then solve the ODES to get the values down to rmin.

[thompsonphys]

I've added a quick function ReggeWheelerMSTBC that will compute the MST radial function at specified domain boundaries, but I'm terrible with the rather opaque Mathematica package code, so it's not hooked into anything yet.

[thompsonphys]

I think that perhaps the best way to toggle is between MST and series initial data would be to add an additional parameter to the method options, e.g.:
Method->{"NumericalIntegration", "Domain" -> {10, 10^2}, "BCGeneration"->"MST"||"Series"}

The question is whether we want the MST initial data to have more freedom than the current implementation, such as evaluating the BC data at the boundary of the desired domain when the function is called.

[barrywardell]

I agree suboptions to the NumercalIntegration method are the way to go. Maybe we want "BoundaryMethod" -> "MST" | "Series" and "BoundaryLocation" -> r options?