Skip to content

Latest commit

 

History

History
63 lines (32 loc) · 5.23 KB

software_management_plan.md

File metadata and controls

63 lines (32 loc) · 5.23 KB
Raw

macauff Software Management Plan:

Based on The Software Sustainability Institute. (2018). Checklist for a Software Management Plan (1.0). Zenodo. https://doi.org/10.5281/zenodo.2159713; meets R1 of the LSST:UK Software Development Requirements

What software will you develop?

  • macauff (https://github.com/lsst-uk/macauff) is a catalogue "cross-match" software, which takes two different photometric catalogues -- one of which will likely be LSST -- and derives probabilities of positionally coeval sources being two detections of a single physical sky object versus their being two detections of two unrelated, separate objects. It considers as many appropriate contributions to source position uncertainty as possible, and folds in the extra information we have in the brightness of objects to break degeneracies between competing sources in a catalogue that are both close enough to another source to be considered "good" matches.

  • This software will be a completely new, ground-up codebase.

Who are the intended users of your software?

  • There are two sets of users for our software.

  • The first, "actual" users of our software, as it is designed for the LSST:UK consortium, are likely to be members of the UKDAC, who will actually run the software on LSST data releases and ancillary catalogues; but there may be other users in the astronomy community who run the software for other purposes. These DAC users will need to be familiar with the installation process of a Python package, with fortran subroutine wrappers, on an HPC system, through e.g. conda, pip, or git management. (R3, R16)

  • The second set of users are the end-users: the astronomy community at large who will use our "value-added" catalogues, simply interacting with the data files generated by the DAC team during their workflow. These users should only require knowledge of how to access data files through e.g. SQL queries.

How will you make your software available to your users?

  • Software will be available through github, on e.g. the LSST:UK organisation page. Significantly major revisions will get releases through more advanced channels such as pip installation, but "dev" branches will always be available through git. (R6)

  • Software is licensed under a BSD-3 clause license. (R2.3, R7)

  • Software results will be available to the bulk of the community through the DAC, and hence those users will rely on the online services the DAC provide for access.

  • More specific to LSST:UK, we will work with the DAC team members in question to ensure that, as much as possible, specialist information required to run the code, and apply the scientific methodology to new or future catalogue pairings, is preserved. (R17)

  • We will broadly advertise the software and end catalogue products available through the DAC to ensure users are fully aware of its potential and results. (R4)

How will you support those who use your software?

  • Support will primarily be through github: support through "issues", and feature improvement through pull requests. (R9, R10, R22, R23)

  • As much as possible, DAC support will be provided through internal LSST:UK channels, subject to staff effort.

  • Software documentation will be hosted publicly, either through the LSST:UK github pages site, or e.g. readthedocs, with all relevant contact information listed. (R2, R5, R11, R12)

  • Testing suites will be provided for all code within the codebase, to ensure that updates do not break previous functionality. (R13, R14, R15, R19, R20, R21)

How will your software contribute to research?

  • End product of "value-added" catalogues will enable the tackling of a vast range of scientific problems in the LSST-era; almost all astronomical challenges will require the inclusion of some ancillary data, and we will provide a novel, robust, thorough, uniform, and easy-to-access platform to obtain these data from.

  • We will integrate both our software and the development team within the wider scientific community, through e.g. the Rubin Science Collaborations, to ensure maximum impact of the software. (R18)

How will your software relate to other research objects?

  • Software is described in published, and to-be-published, scientific journal articles, detailing the algorithms behind the code.

  • Software requires both active LSST data releases and archival datasets previously published.

  • Future collaborations will result from these datasets, and the software that enables them, both within LSST:UK and in a wider context.

How will you measure your software's contribution to research?

  • Github contains many metrics to measure the download, fork, and "watch" rate of software, as well as tracking issues, PRs, commits, etc.; additionally, we can track the metrics of any installations done separately through e.g. pip.

  • We will actively encourage citation of previous scientific papers and to-be-published JOSS paper describing the software, and use those citations as a metric for the impact of the software within the community.

Where will you deposit your software to guarantee its long-term availability?