This release has been in development for the last six months as a program overhaul to produce a scalable framework to move towards a stable user-program interface. With the overhaul came a framework remodel, process changes, and many feature additions.
Framework Remodel
The program structure of prior releases was constrained by the lack of proper abstractions and strict interdependency between various classes such as the `Satellite` and `Encounter` classes. Additionally, there existed confusing entity relationships, most predominantly seen with encounter generation which required `Satellite`, `GroundPosition`, `EncounterSpec`, and `Encounter` class initializations. Much of this functionality was redundant and provided user functionality that was not practical or useful.
The 0.2.0 release experienced an increase in the program abstractions through the following changes:
* The `Satellite` class was remodelled to incorporate only high-level satellite-related calculations. As of now these satellite-dependent calculations are minimal but will be expanded in future releases through the incorporation of solar energy and solar radiation pressure calculations.
* The `Time` and `Coordinate` classes were produced to strip the time and position conversion details from the `Satellite` class and perform only their respective conversions. This change allows for scalability in future releases. This change also induces clarity in the entities' purposes making user interactions more clear.
* The `Encounter` class was reduced to a function to generate windows. The previous construction of the encounter workflow required an confusing interdependency with other classes which was clunky to use. Additionally, the `Encounter` class only contained one piece of useful functionality being window generation. Reducing down to one function made all the additional methods go private as they provided no use to users in the scope of the program. In this reconstruction, we were able to remove the need for the `EncounterSpec` class which unfortunately limits the encounters options available to user. We intend to increase the customizability of selected encounters in future releases.
* The addition of the `Windows` and `Window` classes introduced more implementation-specific data structures that provide more meaning to users than do the previous NumPy arrays. They are also expandable to future additions of a scheduler program that will take in a `Windows` object and return the scheduled `Windows` object.
Process Changes
The development of Celest is taking on a more professional workflow through employing proper testing and validation procedures to ensure the presented library provides value to those who use it. Some specific development goals that have been learned over this past release are as follows:
* Always produce production-ready code. This means we endeavour to create a program that is ALWAYS properly documented, formatted, tested, and validated before adding to the program. As such, the goal is for the library development to always be ready for a release when the time comes. This workflow will allow for better user documentation while the content is still fresh, as well as quick turnaround times.
* Test-driven development and continuous integration. A new testing paradigm will be taken on to ensure code is mindfully developed by paying attention to inter-entity interactions and developing for future extensions.
Feature Additions
Time Class
The `Time` class was added to segregate `Satellite` class functionality. With the creation of the time class, the following time conversions were added:
* True and mean solar time,
* True and mean hour angle,
* UT1,
* datetime,
* Greenwich mean and apparent sidereal times, and
* Local mean and apparent sidereal times.
The incorporation of a sexagesimal function allows many of the `Time` class' angular returns to be displayed in a sexagesimal format.
Coordinate Class
Much like the `Time` class, the `Coordinate` class was added to remove the conversion methods from the `Satellite` class' scope. New conversions that have become available since the prior release include:
* Geographical coordinate conversions,
* Altitude calculations, and
* Distance-to-location calculations.
With the `Coordinate` class, the ECI and ECEF terminology was switched to the GCRS and ITRS terminology as we are moving towards higher fidelity conversions that will be rigorously defined using IAU coordinate frame definitions.
The incorporation of a sexagesimal function allows the altitude and azimuthal coordinate returns to be displayed in a sexagesimal output. Additionally, functionality to allow geographical data to be returned in the ISO6709 format was added.
Private Coordinate and Time Dependencies
Many dependencies were required and will be required for coordinate and time conversions. These functions have been made private but we debate making them public in the scope of the project. Such functionality includes:
* Nutation angles,
* Nutation components,
* Mean and apparent obliquity,
* Julian to day-month-year conversions,
* Julian to day-of-year conversions,
* Equation of time,
* Equation of equinoxes, and
* Sun right ascension calculations.
Private Encounter Dependencies
The `Encounter` class was overhauled by making private many of the uninteresting methods. But most prominently, this release incorporates a new method of generating raw encounter opportunities using an analytical mathematical basis for encounter planning. Such a change makes encounter generation more efficient and is scalable to future "algorithmic" changes to improve runtime.
Private Satellite Attitude Calculations
Satellite attitude calculations necessary for ground tracking were added but not made public in the documentation due to residual issues. The code issues will be resolved and the process improved for future releases.