search

brandon-rhodes / pyephem

Scientific-grade astronomy routines for Python
Other
767 stars 121 forks source link

Should TLE far from epoch throw a warning instead of an error? #130

Closed dronir closed 2 years ago

dronir commented 6 years ago

I think the behaviour of throwing a hard error for too old orbital elements is a bit too harsh. An informative warning would be better.

The relevant line of code is https://github.com/brandon-rhodes/pyephem/blob/592ecff661adb9c5cbed7437a23d705555d7ce57/extensions/_libastro.c#L1294

I am using TLE data for satellites to do some qualitative studies on the observability of satellites from a certain location. Very exact ephemerides are not relevant because I'm interested in questions like "approximately how many of these 2000 satellites are both above the horizon and not eclipsed during a given night?". I'm also not extrapolating for decades, but sometimes I need more than a year from the element epoch.

brandon-rhodes commented 6 years ago

I'm not sure when a new version of PyEphem might ever come out, but if one does: would it help if it included a tunable parameter you could set that moves the limit out beyond 1 year?

dronir commented 6 years ago

I'd just be happy to have it throw a warning instead of an error. The validity of the TLEs is a concern after all, but sometimes one needs to consciously ignore it.

brandon-rhodes commented 6 years ago

The problem is that warnings are too often invisible — for programs written using PyEphem that present data on a web page or in a GUI, warnings often disappear on to unwatched console screens or log files. Given how many questions I have had to field over the past two decades about why an ISS prediction with 2-year-old elements didn't wind up being correct (and how many crashes folks have reported from dealing with 2-year-old elements that the libastro code can no longer extrapolate from without running into an error), I'm not inclined to remove this error by default, since it feels like it has substantially cut down on the number of reports of user confusion and crashes.

But for folks who know what they're doing, and who won't be a support burden when they see the results of extrapolating past the point where results are realistic, I'll be happy to add an escape hatch to widen the time over which results are valid!

cpbridges commented 5 years ago

I'd just be happy to have it throw a warning instead of an error. The validity of the TLEs is a concern after all, but sometimes one needs to consciously ignore it.

I agree. I will be removing this warning myself also. Any sgp4 propagation longer than a few weeks becomes speculative anyway.

Edit: Turns out, I get 'None' responses for calculations now. Need to figure out how to force the propagator to continue... Any pointers welcome!

cpbridges commented 5 years ago

Perhaps @brandon-rhodes knows how to turn this off to extend propagation (albeit with caution)? Many thanks in advance!

brandon-rhodes commented 5 years ago

Turns out, I get 'None' responses for calculations now. Need to figure out how to force the propagator to continue... Any pointers welcome!

If the underlying algorithm runs into floating point NaN, then I'm not aware of any way to recover. Here's the most comprehensive recent paper I know about the algorithm, in case you want to dig in and start experimenting to learn more about the NaN:

http://www.celestrak.com/publications/AIAA/2006-6753/

Perhaps @brandon-rhodes knows how to turn this off to extend propagation (albeit with caution)?

Having read the code, I don't see a way to do it without a full new release, which I currently don't have all the tools for (I'd need to set up new Windows and Mac development environments etc to do all the building). The value is hard-coded down at the C level in _libastro.c, which would be difficult to modify at runtime after PyEphem had been compiled and built.

But propagation out that far won't be returning good data, either statistical or otherwise, as far as I know. Averaging or tallying dozens of incorrectly modeled orbits shouldn't give results too close to real orbits, I don't think? I guess to be convinced of the value here, I'd need to see a statistic generated for, say, a 2-year time period using 102 real TLE's each covering a week, then see the same statistic generated by propagating the middle TLE out to a year on either side, and see that the two agree. (And also see that the statistic can't be simply generated by a simple run over the 2 weeks covered by a single TLE.)

If PyEphem should ever get scheduled for a new release, I'd certainly be happy to throw in a way to adjust the parameter.

Have you considered using the Python sgp4 library directory? It doesn't have any limits to try to make users call it sanely. :) https://pypi.org/project/sgp4/

brandon-rhodes commented 2 years ago

Coming back to this issue a few years later, my attention is drawn to something I didn't notice before: this isn't specifically a behavior of PyEphem, but is a behavior built into XEphem which supplies the libastro library. Given that I intend PyEphem to simply wrap XEphem and provide the same numbers that a user would get from it interactively on their screen, I'm going to keep the 365 day limit. Thanks for asking, though, so I could reason through it!