Tracking unique sensor calibration values

[patricktokeeffe]

Base version of EasyFlux-DL relies on unique sensor calibration values being updated in the program file. Any changes to those unique values would be (hopefully) tracked by the user before they deploy their changes.

Our version is modified so users can update unique values without editing (and subsequently redeploying) the program file. Since changes to the unique values file are not tracked in version control, we conditionally add relevant columns to the final data tables which contain the sensitivity values used for that record:

Table name	Relevant columns
Flux	NRLITE_SENS, NR01_SW_IN_SENS, NR01_SW_OUT_SENS, NR01_LW_IN_SENS, NR01_LW_OUT_SENS, CNR1_SW_IN_OUT, CNR1_SW_OUT_SENS, CNR1_LW_IN_SENS, CNR1_LW_OUT_SENS, PYRAN_MULT, PYRAN_OFFSET, QUANTUM_SENS, QUANTUM_OFFSET, SI111_m0, SI111_m1, SI111_m2, SI111_b0, SI111_b1, SI111_b2, SHFP_1_SENS, SHFP_2_SENS, SHFP_3_SENS, SHFP_4_SENS
LTAR_Met	SHFP_1_SENS, SHFP_2_SENS, SHFP_3_SENS, SHFP_4_SENS
LTAR_Met_1min	SHFP_1_SENS, SHFP_2_SENS, SHFP_3_SENS, SHFP_4_SENS

These unique sensor calibration values change very infrequently and consequently we store large amounts of identical values.

• Should these kind of metadata be abstracted into a separate data table which gets called just once after compilation?
• If so, should the structure of that table be rigidly defined such that adding/removing sensors does not cause that table to reset?
• Are there other relevant metadata to retain that aren't specifically calibration values?
  • Sensor presence & quantities Can be deduced by columns present in output data files
  • Fine wire thermocouple diameter? No, already in Flux_Notes
  • Sonic azimuth Present in Flux
  • Rain gage multiplier? (presuming rain gage sensor choice is refactored back to on/off constant + unique constant)
  • Cup & vane azimuth?