How is an input card for SGP4/other astro standards packages crafted?

Question

I've read through the SGP4 documentation at least 5 times, and I swear the only reference it makes to the construction of an input card is "just look at the examples". For Sgp4Prop, it looks like the only elements required (besides the TLEs) are a start epoch, time step, and stop epoch. Oh, and whatever '6P' controls. I tried changing the '0.0000' for start epoch to '10.0000', including removing the whitespace that the 1 should occupy, and instead of getting a start epoch that was TLE epoch + 10 minutes, I got a start epoch of Jan 1 1956, 00:00. There has to be some real documentation for the input cards somewhere, right?

Answer 1

I completely agree, the 6P card input is very annoying to use and its documentation is terrible. Here is an example of how to use it, as I did in preparing my answer to Failing at getting apogee and perigee from TLE The input file I made to use with space-track.org's Sgp4Prop.py, with the 6P "card" on the first line and the TLE on the second and third lines, is this:

21354165831.482 0001 21358165831.482                                          6P
1 25544U 98067A   21356.70730882  .00006423  00000-0  12443-3 0  9994
2 25544  51.6431 130.5342 0004540 343.5826 107.2903 15.49048054317816

Note in particular the "6P" all alone by itself way off in the corner. It must be in exactly that position, or nothing will work properly, so it helps to use a text editor that can display the column number your cursor is in. I use emacs, and its M-x column-number-mode is zero-based, so I put the 6P in columns 78 and 79; if your text editor starts counting columns with 1 rather than 0, you need to put your 6P in columns 79 and 80.

The next step is the time conversion. The TLE epoch is 21356.70730882, but that is not the same format as the 6P line! The TLE uses YYDDD.dddddddd, where YY is two digit year, DDD is three digit day of year, and .dddddddd is fractional day to 8 digits. To write that same time in the 6P card format, you must change to YYDDDHHMMSS.sss, where YY and DDD are the same, but HHMMSS is hours, minutes, and seconds of the 24 hour clock, with .sss as fractional seconds to three digits. 0.70730882 of a conventional mean solar day (86400 seconds) is 61,111.482 seconds, which works out to 16 hours, 58 minutes, and 31.482 seconds. To give the same two days before and two days after that the plot's in uhoh's answer to that question use, I added and subtracted 2 from the DDD part, giving 21354165831.482 and 21358165831.482 as the start and stop times. The 0001 between them is minutes between successive outputs. 0001 is the smallest number I've been able to use, and 60 seconds is pretty good for lots of purposes. The three zeroes are there to keep the spacing correct.

Now, you don't have to use 6P cards to use the space-track.org SGP4 library. It's just that the sample program they provide to show you how to use their Python code happens to choose this weirdly undocumented way of reading its time inputs. For serious use, I find it necessary to wrap their Python wrapper in another, more Pythonic wrapper, that for example has functions that return ordinary lists of floats, rather than force you to pre-declare everything in ctypes array objects. I put up with the 6P time format for things I post here, mainly so that I can remember how to answer questions like this. :)

The purpose of SGP4 is to turn TLEs, which are easy to get but complicated to interpret (see, for example, Mean to Osculating conversion for non-J2 averaged elements , Confused about SGP4 implementation published by celestrack , and How to construct $B^*$ drag term in TLE?), into a more immediately useful form, like position and velocity vs. time. Once you've done that, unfortunately, the error inherent in a TLE's approximations is baked into anything else you might do with it, as discussed in Accuracy of converting from TLE/Orbital Elements to Cartesian if used for other propagator?

The most complete and most thoroughly-tested open-source orbit package I know of is OreKit. It is written in Java rather than Python, but there are Python wrappers for it out there. Its biggest drawback is that it's very low level, so there's a lot of assembly required, but they have some really good contributors. For example, the US Naval Research Lab published a paper favorably comparing OreKit's ocean tide models with NRL's own in-house tool: Evan Ward, John Warner, and Luc Maisonobe (2014). Do Open Source Tools Rival Heritage Systems? A comparison of tide models in OCEAN and Orekit. AIAA/AAS Astrodynamics Specialist Conference, DOI 10.2514/6.2014-4429.

Answer 2

I'm going to write out this answer for anyone else who might be furiously googling in the future:

The first line of the input card for Sgp4Prop is a "6P card". It's parsed by timefunc.dll, and you can find the documentation in Documentation/librarydocuments/timeFunc.pdf. Columns 1-15 are an absolute julian date (YYDDDHHMMSS.SSS), or you can use 10-15 as a relative time, for start time in minutes since epoch. It's unclear if that can be negative. Columns 16-20 is the step size, in minutes. 22-36 is an absolute stop, again in YYDDDHHMMSS.SSS. Alternatively, 31-36 is a relative offset in minutes. 79-80 must contain "6P".