Better out-of-box behavior for soil temperature scheme

[tbohn]

I've recently spoken with a user who was using bad parameters for the soil temperature scheme and getting bad results. This probably has happened to other people too, due to VIC's lack of constraint on these parameters.

I'd like to suggest the following changes to VIC's defaults and parameter validation:

1. Make the implicit scheme the default when FROZEN_SOIL is TRUE, rather than the explicit scheme. Unlike the explicit scheme, which is inaccurate under certain combinations of time step length, node spacing, and thermal conductivity, the implicit scheme is fairly robust.
2. Make the exponential node spacing the default option. This places more nodes near the surface, where spatio-temporal gradients are larger, which allows us to get greater accuracy with fewer nodes (= shorter run-times).
3. Add a validation of the number of thermal nodes as a function of the specified bottom boundary depth, such that the user isn't allowed to specify too few nodes.

[bartnijssen]

Agreed to all three. Is there a way to 'catch' users that have been running using the old default setting, so that they alerted that the default option is different? Maybe not.

On Jan 2, 2014, at 6:58 PM, Ted Bohn notifications@github.com wrote:

I've recently spoken with a user who was using bad parameters for the soil temperature scheme and getting bad results. This probably has happened to other people too, due to VIC's lack of constraint on these parameters.

I'd like to suggest the following changes to VIC's defaults and parameter validation:

1. Make the implicit scheme the default when FROZEN_SOIL is TRUE, rather than the explicit scheme. Unlike the explicit scheme, which is inaccurate under certain combinations of time step length, node spacing, and thermal conductivity, the implicit scheme is fairly robust.
2. Make the exponential node spacing the default option. This places more nodes near the surface, where spatio-temporal gradients are larger, which allows us to get greater accuracy with fewer nodes (= shorter run-times).
3. Add a validation of the number of thermal nodes as a function of the specified bottom boundary depth, such that the user isn't allowed to specify too few nodes.

— Reply to this email directly or view it on GitHub.

[tbohn]

Well, we could at least post a warning if FROZEN_SOIL is TRUE but the options in question are set to defaults. The warning could tell the user that the defaults are different from previous versions. But this might go unnoticed...

When VIC 4.2 (or whichever release you'd like this to go into - potentially 4.1.2 as a hotfix?) is released, perhaps an email should be sent outlining the major changes, including the new default behaviors.

[tbohn]

This issue depends on solving issue #67.

[tbohn]

I'm preparing the code modifications as both part of 4.2 and a hotfix (4.1.2.k).

The validation that happens as part of this fix will serve as a sort of warning to people who have been using the defaults. If they haven't paid attention to their settings, they will likely have too few nodes for the IMPLICIT/EXP_TRANS scheme, and VIC will abort with a message to that effect. The message will also tell them that they are running with IMPLICIT=TRUE and EXP_TRANS=TRUE. The message will let them know that one way to fix the problem (other than modifying the number of nodes) is to set these options to FALSE.

This won't catch users who have been running with the old defaults and a high number of nodes, unfortunately. What this means is that their soil temperatures will change (become more accurate) and their run times might decrease. Possible changes to hydrologic fluxes will likely be concentrated in runoff vs baseflow (given that most ET happens when the soil is thawed and therefore won't be very sensitive to soil temperature). But the effects become more pronounced at higher latitudes, so it's conceivable that early summer ET might change in areas with shallow active layers due to changes in how fast the ALD increases.

[tbohn]

Reopening due to updates to issue #67 (mainly to remind myself to re-test this).

[tbohn]

Currently looking at field sites to determine the minimum number of nodes for a good simulation.

[tbohn]

OK, I've committed the code changes to #73, and it's been merged into the master branch.