pysky: An Application for the Planning of Multi-Target Astronomical Observations

To automate the process of planning and curating multi-target observation sessions, pysky application builds on the astroplan Python package to identify visible objects during an observation window and produce relevant information about those objects in visual and graphical form. The package calculates object visibility based on a provided time window and observing location as well as maximum airmass and limiting magnitude requested by the user. The pysky application images of the target objects with identifying and astrometric data to provide context for the images. In addition, pysky creates polar plots of each object’s horizontal coordinates, and the images and plots are designed to be shown side-by-side. The package also generates an HTML table of the selected target objects with their related data to relay the entire target list as one. The pysky application draws on a variety of Python packages to collect and process data from databases such as JPL Horizons and SIMBAD. Results for a test event were verified by hand using database web interfaces. The pysky application provides a platform for further integration of auto-mated observation planning with websites and apps to enhance multi-target observation sessions.

focus on an array of objects to observe within a scheduled timeframe rather than a single specific target, and judging which targets to include may be aided by the relative astrometry and visualization of the target objects.
For educational observational programming, the program designer usually seeks to curate an array of observation targets to present to program participants, and visualization is an important component to support participants' astronomical learning [4]. Presenting astrometric data may supplement prior knowledge, which has been shown to increase awe during science learning experiences [5], and, by making the gaps in knowledge salient, awe has been shown to promote scientific investigation [6], an important goal of observatories offering public programming.
The pysky application seeks to fill the need for multi-target observation planning and curation by: 1) automating the identification of available observation targets within a time window given observational constraints; 2) collecting pertinent data about the targets; 3) formatting and visualizing these data for session planning as well as public event promotion and presentation.

System Overview
The pysky source code is hosted on GitHub 1 . After the pysky application is installed, the user edits a preferences file to specify an observing latitude, longitude, and elevation, minimum apparent magnitude, maximum air mass, and particular solar system objects and stellar systems that the user wishes to check visibility for. By default, the application searches all of the Messier [7] and Caldwell [8] catalog objects for visibility within specified observing parameters.
The user interacts with the application via their terminal or command prompt by invoking "pysky" with a required start date and start time in ISO 8601 format to query their specified celestial bodies as well as the default catalogs. If the ending day or ending time is not specified, the application will set the observation time to be for one hour after the specified starting time. The user may also specify a multi-threaded model to speed up the calculation (see Section 1 for results).
Using astroplan [3], the application downloads and caches the IERS Bulletin A to accurately predict the apparent position of a celestial object from the Earth.
Next, the application loads the predefined dictionaries of Messier and Caldwell objects. For solar system system objects defined by the user, the application queries JPL Horizons [9] to retrieve and store the objects' right ascension, declination, azimuth, elevation, magnitude, constellation, and illumination. Next, the application makes a request to SkyView [10] to retrieve the image of the object using the beautifulsoup4, urllib3, and requests libraries for Python. For the non-solar objects, the application uses astroquery [11] to retrieve the object's astrometry, brightness, and classification from SIMBAD ( [12]). The application then uses astroplan [3] and astropy [1] [2] to compare the object's airmass and 1 Journal of Applied Mathematics and Physics apparent magnitude to the user's specified cutoffs and eliminate disqualified objects from the observation list.
Finally, the application generates outputs for each of the visible objects. The first output (if generated) is the image of the object overlaid with astrometry and brightness information (see . This information is retrieved from JPL Horizons [9] for solar-system objects or from astroquery [11] for extrasolar objects. The images of stars and star systems are retrieved from SkyView [10] using Python's Pillow package. The next output generated is the HTML table containing each object's name, classification, astrometry, and brightness as shown in Table 1. The final output generated is a polar scatter plot for each object using astroplan [3], astropy [1] [2], and NumPy. One point is plotted for every 15 minutes   Figure 1 depicts system overview described above. Parallelization over threads is implemented for JPL Horizons and SIMBAD queries, SkyView image retrieval, visibility cutoff evaluation, image overlays and plot generation. In each case, the total number of objects processed will be divided by the number of threads requested. Tests of the efficiency of thread parallelization are described in Section 1.

Main Results
For the following experiments, we choose an observation time frame that includes the Great Conjunction of 2020 from 2020 December 21 at 22:00:00 UT to 2020 December 22 at 00:00:00 UT, observed from the Schoolyard Observatory at Hawthorn Hollow Nature Preserve and Arboretum 2 in Kenosha, Wisconsin, USA, located at −87.8791˚ +42.6499˚. We choose a minimum apparent magnitude threshold of 5.0 and a maximum sec z threshold of 11.0. The astronomical objects parsed for each experiment are: all Messier objects, all Caldwell catalogue objects, the eight solar planets, and a selection of bright and multiple star systems: Polaris, Mizar A, Vega, Sirius, Capella, Procyon, Castor, Albireo, 145 CMa, Achird, and ι Cnc. Parallelization tests were performed on three different machines, increasing the number of threads and repeating the calculation. At the end of the run, the application produces a sky plot for each object's movement during the observation time window, an image of the object with its properties overlayed, and a row in a generated HTML table. Figures 2-5 show the resulting overlaid images and plots under the conditions described above for a prototypical object in each major category: solar system (Jupiter), deep sky (Andromeda Galaxy), stellar (Polaris), and the Moon. The image of Jupiter was taken from the Hubble Space Telescope and scaled to approximate the apparent diameter seen in the observatory telescope. The image of Andromeda Galaxy and all deep-sky objects, as well as the Moon phase images, are sourced from Wikimedia Commons. The images of star systems such as Polaris come from the Mellinger Optical Survey ( [13]).
The astrometry data overlaid on each image is designed to place the object  Images are overlaid with naming, categorizing, and astrometry information to contextualize the data. A polar plot of the horizontal coordinates during the observing window is generated for each of the identified visible objects (see also . Such plots are intended to ease observatory use to look for the location and movement of the object in the night sky away from the telescope.
in its astronomical context. The polar plot identifies each object's position in horizontal coordinates during the viewing window to enable observatory users to find that object in the sky away from the telescope.
A. E. Rocha, W. D. Parker     Table 1 were manually cross-checked with Stellarium [14] and, for solar-system objects, the web interface of JPL Horizons. All distances were converted to petameters (10 15 m) for uniform depiction of solar and interstellar distances in a unit comparable to a light-year yet easily reducible to a human-scale length.
The application was developed to leverage multithreaded CPUs in order to reduce the execution time. Results of parallelization tests depicted in Figure 6 show a reduction in wall time with increasing thread number that appears to become insignificant after reaching 50% of single thread time at four threads.

Conclusions and Suggestions
The pysky application is a Python-based multi-target observation session planning application that produces overlaid images and sky plots of potential viewing objects together with an HTML table of their basic information. The pysky application allows observation planners to focus on their session goals, reducing the need to sort through maps or visualization software to bring together information on the fly while promoting ready visualization and curation of information for an observation session. Future directions for pysky include: sorting the viewing list by the right ascension to assist with planning the order of viewing, adding a marathon functionality for all-night observation sessions focused on a particular catalog or object type or observing field, integration with mobile apps designed to provide easier access to the output data, and use of astronomical visualization metadata standard [15].