invert snow fraction for linear interpolation method

[lawfordp2017]

The rain-snow fraction calculation in the linear interpolation scheme seems to be backward, generating more snow and less rain at higher air temperatures.

[jhs507]

Thanks Peter, I will merge this after Logan gives his review.

[loganxingfang]

Hi Peter,
I reviewed this but don't find anything wrong as you pointed out. I will demonstrate this with two testing prj files when using air temperature as snow/rain determination (ie. parameter snow_rain_determination = 0).

From "snow_fraction_test.prj" file, found here
snow_fraction_test.zip

I have three HRUs, with parameter 'tax_allrain' set as 1, 3, and 7, respectively, while keeping parameter 'tmax_allsnow' same. I output three HRUs' hru_snow, hru_rain, and hru_p as well as their water year cumulative values: hru_snow_Tot, hru_rain_Tot, and hru_p_Tot. As shown, hru_p and hru_p_Tot should be same and are the same for HRUs. The total value of hru_rain or hru_rain_Tot: HRU1 > HRU2 > HRU3, while the total value of hru_snow or hru_snow_Tot: HRU1 < HRU2 < HRU3. This makes sense; parameter 'tax_allrain' is lowest for HRU1 and highest for HRU3, so it will require higher air temperature (ie hru_t or internal variable Use) for HRU3 to get precipitation phase as rainfall, and thus results in higher snowfall for HRU3.

From "snow_fraction_test1.prj" file, found here
snow_fraction_test1.zip

I have three HRUs, with parameter 'tax_allsnow' set as -2, 0, and 2, respectively, while keeping parameter 'tmax_allrain' same. I output three HRUs' hru_snow, hru_rain, and hru_p as well as their water year cumulative values: hru_snow_Tot, hru_rain_Tot, and hru_p_Tot. As shown, hru_p and hru_p_Tot should be same and are the same for HRUs. The total value of hru_rain or hru_rain_Tot: HRU1 > HRU2 > HRU3, while the total value of hru_snow or hru_snow_Tot: HRU1 < HRU2 < HRU3. This makes sense; parameter 'tax_allsnow' is lowest for HRU1 and highest for HRU3, so the higher threshold value of 'tax_allsnow' gives more snowfall for HRU3.

The obs file used for these prh files are here
Marmot_Hourly_ArrayMetData_withT_g_1Oct05-30Sept21_update_13Jan2022.zip

In addition, I changed the code as what you have in Borland CRHM shown below. The results do not change much as what I demonstrated above.

hru_rain[hh] = hru_p[hh]*(Use - tmax_allsnow[hh])/(tmax_allrain[hh] - tmax_allsnow[hh]);

[loganxingfang]

In any event, Harder method is recommended for snow/rain determination, parameter snow_rain_determination = 2

[lawfordp2017]

Hi Logan,
Thanks for looking at this. I don't think changing the allrain and allsnow parameters represents a good test for this issue. I've attached a prj and obs file which run for one day, the first 12 hours is cold (0.001 C) and should be mostly snow. The second 12 hours is warm (3.99 C) and should be mostly rain. What I actually obtain is the opposite. I ran this in the GUI version of Borland CRHM (~2018 version)
I'll try using the Harder method as you recommended although Kevin has mentioned having problems using it in the prairies. Also the linear interpolation method (0) is the default so I imagine new users would be surprised if they found the default settings behave unusually.
snowfraction_test.zip

[lawfordp2017]

I should also mention that it is not expected for runoff to vary substantially with this change, although the evolution of the snowpack (snow depth) may vary. I've found some variation when using SNOBAL. SNOBAL sensible and latent heat calculations expect snow to be cold and rain to be warm, and they seem to become unstable when the reverse is true.

[loganxingfang]

Hi Logan, Thanks for looking at this. I don't think changing the allrain and allsnow parameters represents a good test for this issue. I've attached a prj and obs file which run for one day, the first 12 hours is cold (0.001 C) and should be mostly snow. The second 12 hours is warm (3.99 C) and should be mostly rain. What I actually obtain is the opposite. I ran this in the GUI version of Borland CRHM (~2018 version) I'll try using the Harder method as you recommended although Kevin has mentioned having problems using it in the prairies. Also the linear interpolation method (0) is the default so I imagine new users would be surprised if they found the default settings behave unusually. snowfraction_test.zip

In your obs file, it does not warm up to 3.99 C, but it is 0.399 C. Please check this. In Borland CRHM 2018 version, obs module is very much same as that in the current version.

[loganxingfang]

I should also mention that it is not expected for runoff to vary substantially with this change, although the evolution of the snowpack (snow depth) may vary. I've found some variation when using SNOBAL. SNOBAL sensible and latent heat calculations expect snow to be cold and rain to be warm, and they seem to become unstable when the reverse is true.

The SnobalCRHM is mostly used for deeper snowpack, and for use in shallow snowpack, there is problem found in stability simulation, which affects the estimation of turbulent fluxes. This is not unusual problem in SnobalCRHM; I usually set the roughness length parameter z_0 small, such as 0.0001 m.

[lawfordp2017]

I've attached corrected prj/obs files. I'm unable to use EBSM as is, since I need subdaily snowmelt which EBSM doesn't provide. I'll try modifying z_0 as you suggest.
snow_fraction_test_corrected.zip

[loganxingfang]

I've attached corrected prj/obs files. I'm unable to use EBSM as is, since I need subdaily snowmelt which EBSM doesn't provide. I'll try modifying z_0 as you suggest. snow_fraction_test_corrected.zip

I ran the corrected prj and see your point. I think the revised equation as you suggested should be used for mixed phase. I will put this in Borland CRHM.

Justin, since you will merge this in main branch, should I just upload the new Borland CRHM source code files directly to the main branch instead of creating my branch and then merging it later?

[jhs507]

Actually the best way to do this will be if you add the Borland changes to this branch https://github.com/srlabUsask/crhmcode/tree/ClassObs_snowfraction_27jun2022 since that is the one we are merging into the master branch. That way all the changes will be grouped into one pull request.

So you will want to pull down https://github.com/srlabUsask/crhmcode/tree/ClassObs_snowfraction_27jun2022 make your changes to the Borland code and then push the changes.

After you do that I will merge this branch in.

[lawfordp2017]

As another procedural question, is it best for me to identify these minor modifications with new branches or with issues?
From my perspective a new branch allows for viewing code diffs most easily.

[jhs507]

Creating a new branch and then creating a pull request is proper procedure.

[jhs507]

@loganxingfang is this ready to merge?

[loganxingfang]

@loganxingfang is this ready to merge?

Yes, it is ready.

[lawfordp2017]

@loganxingfang I'm curious if this bug existed in CRHM back in 2012-2013 when Philip Harder was working on mixed-phase precipitation modeling within CRHM. (Also John asked me this question, I didn't know the answer)

[loganxingfang]

@loganxingfang I'm curious if this bug existed in CRHM back in 2012-2013 when Philip Harder was working on mixed-precipitation modeling within CRHM. (Also John asked me this question, I didn't know the answer)

That is already in the module obs before 2012-2013. I think it can be one of uncertainties but I'm not sure all the details that Phil Harder used to derive his method. Maybe you can have a chat with Phil.