A short summary of the current status of the project is helpful for understanding why the sequence of spending is what I've proposed below.
I a package several years ago that propvides the skeleton for what I'm suggesting in this proposal.
The package, called stellarphot, currently does these functions, which use a broad range of astropy functionality:
- Alignment and stacking of optical images based on WCS
- Aperture photometry of stars, and mathcing of those stars to a catalog. There are options for doing photometry for all sources in an image, a list of sources, or at the position of sources drawn from a catalog.
- Transformation to a standard magnitude system (currently defined by APASS DR9) can be done.
- Differential photometry can be done as suggested by the AAVSO, though the color corrections they recommend cannot be done.
- Flux ratios, which are used widely in the exoplanet community, can be calculated.
- Data can be read from, or output to, other tools used broadly by amateurs, like AstroImageJ and EXOTIC.
- Measurements can be prepared for submission to the TESS Follow-up Observers PRogram, SG1 (ground-based photometry)
- Measurementsof variable star light curves can be saved in the format required for submission to the AAVSO.
This functionality is presented to users through:
- A JupyterLab extension which presents, from the Launcher,
- a series of Jupyter notebooks, in which users choose appropriate settings, backed by
- a set of function calls and objects that implement the core functionality.
There are five primary problems at the moment:
- There is no consistent API or design to the core functionality in
stellarphot. It has grown organically over the last few years, with changes often made as users (students) were using the software. In some places the approach is functional, in some places it is more object-oriented and in no place is there an attempt to present a consistent API. - The notebooks are a mix of widgets for entering settings and calls to stellarphot to perform tasks like photometry for all of the images in a directory. Wdigets in notebooks are ephemeral -- the widget state is not saved in the notebook, and is lost when the notebook re-opens. The result is that some of the user choices are not saved in a transparent way, making it difficult to reporduce work and impeding a more automated workflow.
- The package is not yet in a state that it can be bundled as a stand-alone app, though it is getting closer. There is already package that allows bundling JupyterLab-based projects into something installable, JupyterLab Desktop. However, the user interface at the moment is essentially JupyterLab plus a couple extra buttons.
- The package has little documentation.
- The fraction of code tested is low overeall and is not consistent across the codebase.
Given this state of affairs, the proposal is to:
- Spend some of the money this spring semester to get advice from a Research Software Engineer or other professional on restructuring the code and designing an API. I am unsure how to hire such a person or how much it will cost.
- Implement the suggestions made by the RSE over Summer 2023. Money will be spent three ways:
- Hiring advanced undergraduate students in copmuter science using grant funds to do some code work.
- Hiring physics students (not with grant funds) to do some work on the code and to test the code over the summer as they carry out observations.
- Paying myself some summer salary to coordinate the work and do some coding.
- Perform extensive testing with users in the Fall 2023 offering of the observational astronomy course at MSUM. During this phase
- Some students will continue to be paid to do code work.
- I may, depending on the remaining budget, buy out some teaching time that semester.
I anticipate submitting an additional proposal at the appropriate time to present the software at a couple of workshops at AAS meetings.