Severe issue in snow calculations in developed SUEWS version

[ljarvi]

There is a severe issue in the model code when SnowUse is set to 1. Before major changes in the code structure after V2020a, snow was calculated in such a way that it was using snow specific equations to calculate evapotranspiration and soil storage when snow calculations are made, and the no-snow equations outside snow (controlled by snowCalcSwitch(is)). In current code version, these two parts have been separated to their own subroutines (SUEWS_cal_QE_DTS and SUEWS_cal_snow_DTS) which means that soil storages are now updated outside snow season when SnowUse = 1. This causes smd to remain small around the year causing unrealistic evapotranspiration throughout the summer.

I guess the easiest solution is to get rid of the SUEWS_cal_snow_DTS subroutine, and add MeltHeat and SnowCalc to SUEWS_cal_QE_DTS and take back the use of snowCalcSwitch. This would avoid duplication of the calculations and allow summer time evapotranspiration and storage changes to be calculated in a same way when SnowUse = 0 or SnowUse = 1. But you know the code best and what is the most suitable approach.

Also minor issues in snow calculations:

• mwh now as an output variable from SUEWS_cal_snow_DTS causing MeltWater to be zero in the main output file
• Within SUEWS_cal_snow_DTS, swe, SnowRemoval and mwstore should be initialised to zero outside do loop

---

The above is based on eade2e1 (edited by @sunt05 )

---

subtasks

• [x] #135

[sunt05]

Hi @ljarvi , thanks for documenting the issue - your efforts in looking into this are much appreciated!

Just to leave some more background here about the structural changes:

• the DTS-related changes are meant to introduce derived types to make interfaces consistent for different modules so future development and maintenance would be easier (however, this works was not finished over the summer but is ongoing).
• the snow part was de-coupled from the main QE module due to the extension work relating to a new surface temperature / storage heat module; the strong coupling between snow-related and other QE parts made that work highly challenging - but I did plan to get the snow part back in a more consistent way (this is also linked to the point above).

So my suggestions for now would be:

• please start a snow branch from master that may accommodate your needs for now with your proposed changes above
• once I've my teaching this year, you and I work together to get the snow component back to master again using the new structure (i.e. that is based on the derived types).

[sunt05]

The recent fix by @ljarvi has been added via commit d733780ade613eebabda2c2488057ee703792603 (not tested yet, though).

[sunt05]

related #234

[sunt05]

merged into #234 related branch