General Facility Module

[jchate6]

A General Facility would have a default, generic form that was populated from either an online DB if one exists or from a local DB that is set up one time.

The primary use case would be to quickly add a large number of manual facilities that require an email or something similar for observation submission. The facility and instrument details would be stored in the DB and need to be set up once when adding the observatory.

Moving facility classes out of settings.py and into apps and a DB would be important so facilities can be added from the admin interface.

[jchate6]

@talister @carrholt
Could you please describe your needs for an Observatory model.

[talister]

For FOMO, and I think for BHTOM also looking at their Observatory model, we have a need of storing and using information about telescopes at observatories which are not full Facilityies in the TOM Toolkit sense of being able to submit requests to and get data from. There would be of order 10's of these Observatories compared to the ~4 full facilities (LCO, SOAR, ESO, Gemini). Things That We Would Want To Do:

• compute visibility of objects (rise/set times, hours of visibility, max altitude/min airmass)
• amount and time of hours of darkness at the observatory
• perform the name to MPC site code mapping
• (later) estimate of imaging SNR using simplified estimator ala NEOfixer and find_orb and my ETC

An interface to the MPC's ~2600 observatories has been written that retrieves and stores the basic parameters (MPC site code, lat, long, elevation, names and observation type (optical, radar, satellite)). With the recent scramble to look at 3I and assess visibility at several facilities, I needed to make "fake" Facility modules for Rubin (X05) and Lowell Discovery Telescope (G37) which duplicated all the name and positional information and needed additional stubs, NotImplemented or fake forms for the observations submittal and retrieval parts.

If the facility module could be split into two with a lower level for the un/slowly-changing site parameters (site code, positions, names, primary mirror diameter, central obstruction, typical seeing) with a higher level built on top that handles the proposals, observation requests and data retrieval for the full facilities that need that, that would allow basic planning and visibility for the larger number of non-robotic/remotely accessible telescopes to happen much easier.
As for time frame, we (FOMO) would be looking to need this in the September-October time frame for new shiny Rubin things.