Version of pycraf compatiable with version 2.11 or later of python-sgp4

[OrbitalMechanic]

Will there be a version of pycraf compatible with version 2.11 or later of python-sgp4? If so, what time frame can we expect to see it?

Sam Dupree.

[bwinkel]

Indeed, it is planned to work on the satellite sub-package in the near future (few weeks), to add some functionality for satellite constellation simulations. The current plan is to migrate to cysgp4 in the process, as it integrates nicely with numpy arrays (and broadcasting). Under the hood, it uses a different C++ library such that the results will be slightly(!) different from python-sgp4. Do you have strong feelings about this? If there are good reasons to also continue to support python-sgp4 one could probably make it so that both 3rd party packages are supported.

[OrbitalMechanic]

First, permit me to apologize for not getting back with sooner. Secondly, to answer your question concerning python-sgp4 versus cysgp4 I looked into the code baseline for the two. According to their documentations both appear to trace their baselines to the document "Revisiting Spacetrack Report #3." However in checking the change-log for python-sgp4 the code base seems closer to Vallado's C++ code reflected in "Revisiting Spacetrack Report #3: Rev 2." I've attached a copy of this report to this note from your convenience. In short, I would stick with python-sgp4 since it appears to comes closest to Vallado's C++ code reflected in "Revisiting Spacetrack Report #3: Rev 2" which is best documented implementation outside of AFSPC. Hope this helps. Sam Dupree.

…

On May/25/2020 02:56:54, Benjamin Winkel wrote: Indeed, it is planned to work on the |satellite| sub-package in the near future (few weeks), to add some functionality for satellite constellation simulations. The current plan is to migrate to cysgp4 <https://github.com/bwinkel/cygrid> in the process, as it integrates nicely with |numpy| arrays (and broadcasting). Under the hood, it uses a different C++ library such that the results will be slightly(!) different from |python-sgp4|. Do you have strong feelings about this? If there are good reasons to also continue to support |python-sgp4| one could probably make it so that both 3rd party packages are supported. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEO35ZFNBJK6DHFF3PMUPLRTIJDNANCNFSM4NJFY3SQ>.

[bwinkel]

Thanks a lot, this is very good information indeed. I may make this a user option then, perhaps. It should not be a huge problem, as pycraf already "wraps" the python-sgp4 (and adds azimuth/elevation calculation). However, because of this, python-sgp4 will likely perform somewhat worse, as cysgp4 does everything in parallelized C-loops. Not sure, if it is a big problem in practice though.

If I may ask, what do you use pycraf for?

[atrawog]

I just started to use pycraf, but this appears to be a quite simple problem. The Satellite object in the current python-sgp4 version 2.12 has been moved from sgp4.io to sgp4.model.

I made a small fix #32 and pycraf together with sgp4 2.12 appears to work fine now