Quarterly Update: September 2020
Software releases
Since the Virtual SuperDARN Workshop, the following software has been released:
- RST v4.4, July 2020
- RST v4.4.1, August 2020
- pyDARN v1.1.0, August 2020
DAWG website
In June we launched a new website for our working group: https://superdarn.github.io/dawg/
The website has two purposes:
- Provide high-level updates on the working group’s main activities
- Host the working group’s documents such as annual reports and presentations
Charter update
In June 2020, we proposed an update to our Working Group’s charter. We have now updated the proposed charter based on the following feedback:
- Uncertainty about which components of the RST are classified as “secondary software”
- Concern regarding the DAWG’s power to remove “secondary software” from its scope at their own discretion
In response to this feedback, we have changed the process for removing secondary software from “discretion of the DAWG chairs” to “mutual agreement between the DAWG chairs and the Executive Council”. We believe this change addresses both of the above points, since the Executive Council will now participate in the removal process. We have also provided some additional examples of RST components that we consider to be “secondary software”. The reason for distinguishing between “primary” and “secondary” software was to give a sense of priority to fitacf
, map_potential
, and their dependencies.
- Proposed charter (updated September 2020, major changes in bold)
- Current charter (approved in 2013)
Note that we have no plans to remove any components of the RST. We just want to have a formal process in place without changing the charter to remove secondary software in the event it cannot be maintained (external library dependency issues, scope creep, etc.)
FITACF 3.0
Publication on FITACF 3.0
Emma Bland and Pasha Ponomarenko are working together on two publications relating to FITACF 3.0:
-
Description of the ACF fitting method implemented in FITACF 3.0. Comparisons between fitted data from FITACF 2.5 and FITACF 3.0 will also be presented.
-
Improved method for estimating the “sky noise” parameter, which has already been implemented in FITACF 3.0. This paper will also include a discussion of technical issues that impact on the noise level determination, which may be responsible for some of the major differences between the outputs of the two fitting algorithms for some radars.
Please contact Emma if you have questions about this work.
Source code structure
Marina Schmidt has begun restructuring the FITACF 3.0 source code to match the structure of FITACF 2.5. In particular, the linked list syntax will be removed and replaced with arrays. After restructuring the package, Marina plans to add the Shepherd (2017) elevation angle calculation to FITACF 3.0 (currently only available in FITACF 2.5). The DAWG will continue to aid and test as the phases of the restructuring are completed.
Hardware files in RST
During the Virtual SuperDARN Workshop there was some discussion about removing the hardware files from the RST. However, the DAWG chairs have decided to take no action on this issue for now, and to continue releasing RST with a complete set of hardware files included. This decision is based on the DAWG’s concerns about archiving and reproducibility. In particular, if the hardware file format changes in the future (e.g. to include more detailed TDIFF information), the new format will be incompatible with earlier versions of the RST. Therefore, RST should continue to be released with a compatible set of hardware files.
Our decision is not based on earlier concerns that removing the hardware files would create extra steps to install the RST. Our software expert, Marina Schmidt, has advised that the hardware files can easily be added automatically during the build process. To address the concern about archiving/reproducibility, her proposed solution requires that the hardware files are versioned/have a DOI, which is being discussed by the Data Standards Working Group (DSWG).
We are making one change going forward: DAWG will no longer create new releases of the RST purely due to hardware file updates. Instead, we will advise users on how to download updated hardware files into RST from the official hardware file repository. We hope that this change will allow hardware file updates to reach the scientific community faster, and not require users to install a new version of RST every time a hardware file is updated. This change in procedure will result in differences between RST’s original DOI’d hardware files and any updates between releases. Users should note these changes in their publications where relevant.
The DSWG is responsible for the contents of the hardware files, and for maintaining and distributing them. Their policy for hardware files is still under review, so any questions of that nature should be directed to the DSWG.
We will revisit our decisions about the hardware file integration with RST after the DSWG has finalized their policy for maintaining and archiving the hardware files.
New sounding mode library in RST
Evan Thomas has created a new library in RST to support the new snd
-format files produced by the interleavesound
control program, a frequency sounding mode which ran as a network-wide experiment on 9 September 2020.
The library will be included in a future release of RST, but you can try it now on the develop
branch of the RST. Some information about the code and file format are available here and here. Please contact Evan if you have questions or need assistance.
Software authorship guidelines
We have created a document outlining the criteria for authorship of DAWG software, available here. The document is still under discussion within the working group and we are not seeking formal approval from the Executive Council, but we do welcome any feedback at this stage.
Release guidelines update
After some missteps and mistakes when making a release of RST earlier in 2020, the release guidelines are being updated to include a release checklist. This checklist will help future software package leads with creating a release. In addition, some of the original sections from the guidelines are being updated to fit more with our development cycle and give some examples on what might cause a need for a release.