Merge branch 'preReleaseV2' into 'preReleaseV2'

    JHHSTD = 166 ,              ! day of the year to start writing the half-hourly output

    JHHENDD = 185 ,             ! day of the year to stop writing the half-hourly output

    JHHSTY = 1901 ,             ! simulation year (iyear) to start writing the half-hourly output

                                ! **If metLoop > 1, this must equal readMetStartYear**

                                ! **If leap -> true, this must equal readMetStartYear (for metLoop -> 1 as well)**

                                ! **If you're looping through the met data, this must equal runStartYear**

                                ! **If leap -> true, this must equal runStartYear (whether you're looping or not)**

    JHHENDY = 1901 ,            ! simulation year (iyear) to stop writing the half-hourly output

    dodayoutput = .false. ,     ! Switch for making daily output files 

    JDENDD = 366 ,              ! day of the year to stop writing the daily output (NOTE: if you have leap -> .true.,

                                ! and you want all days written, this needs to be 366 to get the final day of the year written!)

    JDSTY = 1980 ,              ! simulation year (iyear) to start writing the daily output

                                ! **If metLoop > 1, this must equal readMetStartYear**

                                ! **If leap -> true, this must equal readMetStartYear (for metLoop -> 1 as well)**

                                ! **If you're looping through the met data, this must equal runStartYear**

                                ! **If leap -> true, this must equal runStartYear (whether you're looping or not)**

    JDENDY = 2023 ,             ! simulation year (iyear) to stop writing the daily output

    domonthoutput = .true. ,    ! Switch for making monthly output files 

    JMOSTY = 1860 ,             ! Year to start writing out the monthly output files. 

                                ! **If metLoop > 1, this must equal readMetStartYear**

                                ! **If you're looping through the met data, this must equal runStartYear**

    doAnnualOutput = .true. ,   ! Switch for making annual output files 

The Automated Model Benchmarking (AMBER) package evaluates the ability of CLASSIC to reproduce land surface processes by comparing model outputs against quasi-observational data sets derived from remote sensing products, eddy covariance flux tower measurements, and stream flow measurements. To summarize model performance across different statistical metrics AMBER employs a skill score system that was originally developed by the International Land Model Benchmarking (ILAMB) framework (Collier et al. 2018) \cite Collier2018-jv. The amber package was created to tailor the ILAMB skill score approach for CLASSIC model outputs.

AMBER was first distributed via the [CRAN](https://cran.r-project.org/package=amber). It is planned to have AMBER available as a project under https://gitlab.com/cccma and on the Digital Research Alliance of Canada machines. 

AMBER was first distributed via [CRAN](https://cran.r-project.org/package=amber). It is planned to have AMBER available as a project under https://gitlab.com/cccma and on the Digital Research Alliance of Canada machines. 

3. **Plan for mistakes**. People are, well, people. Use 'defensive programming'.

  * Use assertions to ensure the program is running as expected. E.g. if a negative value of something is never supposed to happen, put in a check for negative values and cause the program to exit should that condition arise (with an appropriate and descriptive message explaining the issue).

  * Turn bugs into test cases. E.g. an bad value comes in from an init file and causes mayhem. Fix the issue and then add in a check so that the bad values can be more easily found in the future.

  * Turn bugs into test cases. E.g. a bad value comes in from an init file and causes mayhem. Fix the issue and then add in a check so that the bad values can be more easily found in the future.

4. **Document well!** Good documentation helps people understand the code (and the science). CLASSIC documentation should detail both the science (via doxygen) and the procedural (in the code) information needed to understand the model.

    * Document design and purpose of the code, not its simple mechanics.

* Variables should be described using inline comments for each variable (**required**). This is to allow better code inspection ('peeks') using modern code editors.

* Comments should be Doxygen readable, with LaTeX use where appropriate to allow for proper Doxygen rendering (**required**)

```

real, intent(out) :: RHOSROT(NL, NM) !< Density of snow \f$[kg m^{-3} ]\f$

real, intent(out) :: SNOROT (NL, NM) !< Mass of snow pack \f$[kg m^{-2} ]\f$

real, intent(out) :: RHOSROT(NL, NM) !< Density of snow [$kg~m^{-3}$]

real, intent(out) :: SNOROT (NL, NM) !< Mass of snow pack [$kg~m^{-2}$]

```

### Implicit None

## Acknowledgements

Several coding conventions were used as a guide for developing this document.

* [Joint UK Land Environment Simulator (JULES) Coding Standards](http://jules-lsm.github.io/coding_standards/index.html)

* [NASA Goddard ModelE Coding Conventions](https://modelingguru.nasa.gov/servlet/JiveServlet/download/1813-5-1985/ModelE_Coding_Standards.pdf)

* [GEM-MACH Coding Standards](https://wiki.cmc.ec.gc.ca/wiki/GEM-MACH/Coding_standards)

 No newline at end of file