General Format
Software organization using Gitlab and GIN
Self-written software for data acquisition must be stored, maintained and versioned properly. In the grassland group, we use two tools to accomplish this:
All self-written script or programs (subsequently referred to as programs only) have to be stored in a gitlab repository (gitlab how-to). When you deploy a program on a data acquisition system (computer, datalogger, arduino, etc.), you have to create a fieldbook entry in GIN with the SW_MOD event-tag (gin tutorial) and an URL link pointing to the exact commit of the program repository. Similarly, if you update a configuration-file for a program, you have to create a fieldbook entry in GIN with the CONFIG event-tag and the config-file attached.
As such it is clearly documented when which version of which program was installed on which data acquisition system
To simplify this organisation, some standards have to be met, which are described in the following sections.
Naming of programs and configurations
Programs used on multiple sites
Programs that are (potentially) used on multiple sites must have a site-unspecific name, i.e. the site-name or project-name should not be present. Due to the versioning in git repositories, also version numbers in the file name are obsolete.
ProgramName.file extension
whereby
ProgramName … due to the variety of possible programs, the naming is not strictly regulated. Nevertheless, the program name must clarify what the program is doing (e.g. read, write, control, etc.) and for which instrument or system (as described in Section 2.4.1, e.g. sonic, TrHW, etc.) it was designed for. The ProgramName shall not contain information about SITE or VERSION.
file extension … if necessary
Site-specific programs
SiteID_ProgramName_Location.file extension
whereby
SiteID … as given here
ProgramName … due to the variety of possible programs, the naming is not strictly regulated. Nevertheless, the program name must clarify what the program is doing (e.g. read, write, control, check etc.) and for which instrument or system (as described here, e.g. sonic, TRHW, etc.) it was designed for.
Location … as given here
file extension … if necessary
Scripts and programs which are specific for a special site and device and or data acquisition e.g. a logger program of a CR1000 logger that includes the (mostly) unique sensor configuration of a site and system.
Configuration files
Some programs use configuration files, mainly for these reasons:
- large number of settings that cannot be passed by command line arguments
- generalization of the program to multiple sites, where only the configuration is site-specific
SiteID_ProgramName.file extension
whereby
SiteID … as given here
ProgramName … must be the ProgramName of the program reading from it
file extension … must be .rc or .config (where possible)