Describe the basic user facing functionality for AEONlib

[jchate6]

Do we want to use Astroquery as a model?

• Astroquery docs / Astroquery github

[rachel3834]

The goal of AEONlib is for users to be able to request observations from a range of telescope facilities using a Python library that is independent of any other software.

Use Case Examples

Use Case 1
User is a post-doc in astronomy tasked with conducting a limited set of observations at an AEON-compatible facility. The project requires a relatively small number of observations, so she doesn't want to develop a whole TOM system to do this. The user is familiar with Python, and routinely uses a number of Astropy packages. Much of her research and software development is done in the form of a Jupyter notebook, so she would like to be able to request observations through this tool.

Her expected workflow is as follows:

1. Create a Jupyter notebook
2. Import AEONlib
3. Compose a dictionary describing the parameters of the observation she wishes to make, following examples provided in the AEONlib documentation for the facility she wishes to use.
4. Submit the observation request to the facility, using AEONlib's module for that facility.
5. Receive an identifier for the observation and status information if the facility provides it.

Use Case 2
User is junior faculty and runs a research program including a number of geopgraphically distributed collaborators. The team have previously developed a TOM system for their project, which is NOT based on the TOM Toolkit. To avoid reinventing the wheel, they would like to use AEONlib within their TOM's code to handle the submission of observing requests. These requests will go to a set of telescopes, for which they have already been awarded time.

Their TOM can provide the proposal and authentication credentials for all of these facilities, and the team created webforms for their TOM that enable the team to specify observing requests for their targets. They are happy to develop the functions necessary to retrieve the target information from their TOM, and combine it with the observing request information as a Python dictionary which is then submitted to each telescope using AEONlib modules.

Their workflow is as follows:

1. User logs into their TOM, which has telescope credentials and proposal information configured as well as information on a set of targets.
2. User selects the target they wish to observe and completes a web-form in to describe the parameters of the observation they wish to make.
3. On submitting this form, the TOM uses AEONlib modules to compose the observing request in AEON-standard syntax, and submit the request to the telescope. AEONlib returns an identifier for the observation and status information if the facility provides it to the TOM.

Use Case 3
User is an astronomy researcher with an existing TOM system, previously built using the TOM Toolkit. They would like to upgrade their TOM system to the latest verison, which uses the AEONlib library to submit observing requests to a wider range of telescopes than previously supported by the TOM Toolkit.
They have pre-existing allocations on one or more telescopes, and the TOM stores the telescope proposal and user credentials, as well as information on their targets. Most of the user's observations are programmatically designed and submitted by management commands they developed previously, but they also sometimes use the TOM's UI to request additional observations.

Their workflow is as follows:

1. User updates their TOM to the latest TOM version, which has AEONlib as a dependency.
2. Based on the version release notes and updated TOM documentation, the user is comfortable making any necessary updates to their management commands to use AEONlib modules to build and submit observation requests rather than TOM modules. However, the information returned should remain the same to ensure that observations logged for their program have consistent information.
3. Updates necessary for the TOM Toolkit's facilities module to use AEONlib are implemented in the version upgrade without user intervention, unless they have customized some aspects (e.g. observing forms).

[Fingel]

Hi Rachel,

Thank you for the use cases. There is one part common with these use cases that I think I would like to focus in on, and that
is when our astronomer "composes a dictionary" because that is really 90% of the work!

It's not easy to just type out a perfectly correct python dictionary, even if there is documentation. What instruments are available to you? What are there configurations, i.e. how do you know the names of the filters? In what format should you provide things like times, coordinates, etc? I go over this in more detail in #9. In short, I think we can do better than typing out dictionaries, and I believe it should be the goal of the library to facilitate that. Otherwise Aeonlib isn't really providing much value, as our astronomer could easily use requests to submit her dictionary directly to the observatory API and not need the library at all!

Besides that, these seems like reasonable use cases to be that a reasonably designed library should be able to handle.