Comments (7)
Ted: Guys, this appears to be a simple change, to a variable that is not used in VIC's internal physics - it's just for reporting purposes. If you don't have any objections, I will look into it today and see if I can fix it.
Bart: My main concern is that others may be using the current form and that this will change their output potentially by quite a bit. I am fine with fixing it, but it would be good to document this clearly, so people are not surprised (I do not advocate a switch that allows for either the old or new implementation).
Ted: That makes sense. Perhaps this would be more suitable for VIC 4.2, rather than a hotfix.
Bart: Agreed. Since VIC 4.2 should be released in the next few weeks, that would be my preference. The rationale being that it numerically changes the results by quite a bit for people that have been using this output variable
from vic.
Regarding root_moist: are we sure we want to make this change? Under the current implementation, it is including all water that is available to the roots. Like it or not, the way VIC works is: if your root zone overlaps with a layer by even a fraction of a mm, the roots have access to that layer's water (personally I don't like this approach, which I why I say "like it or not"). So, root_moist is actually representing the water available to the roots correctly.
Some of this depends on the intended use of the variable. If you want the variable to tell you how much water is contained in the volume of soil where the roots are, then @jhamman 's proposal is the way to go. If you want to know how much water the plants have available to them, the current implementation is already correct.
I have the change coded up and ready to commit, if you decide you want to change the definition of root_moist. Otherwise, we should just close this issue without making a change.
from vic.
@tbohn , if you have the change in a new branch, go ahead and issue a pull request and we'll look at it that way.
from vic.
As I've been thinking about this, I think we should not include this change as shown in PR #152. I agree with @tbohn that the current implementation of root accessed soil moisture is less than ideal but if the roots reach any of the layer, they have access the whole layer so OUT_ROOTMOIST
should reflect that.
If users are interested in weighting the root moisture by the depth of penetration of roots or something more specific, that can either set up their soil layers to correspond with the root zones or calculate the fraction of moisture based on the penetration of the roots into each layer.
My vote is to close this issue and the corresponding PR as a wontfix
. Thoughts?
from vic.
Agreed - just make sure that the web site description accurately reflect the variable.
On Oct 9, 2014, at 12:34 PM, Joe Hamman [email protected] wrote:
As I've been thinking about this, I think we should not include this change as shown in PR #152. I agree with @tbohn that the current implementation of root accessed soil moisture is less than ideal but if the roots reach any of the layer, they have access the whole layer so OUT_ROOTMOIST should reflect that.
If users are interested in weighting the root moisture by the depth of penetration of roots or something more specific, that can either set up their soil layers to correspond with the root zones or calculate the fraction of moisture based on the penetration of the roots into each layer.
My vote is to close this issue and the corresponding PR as a wontfix. Thoughts?
—
Reply to this email directly or view it on GitHub.
from vic.
I agree.
On Thu, Oct 9, 2014 at 12:34 PM, Joe Hamman [email protected]
wrote:
As I've been thinking about this, I think we should not include this
change as shown in PR #152 #152. I
agree with @tbohn https://github.com/tbohn that the current
implementation of root accessed soil moisture is less than ideal but if the
roots reach any of the layer, they have access the whole layer so
OUT_ROOTMOIST should reflect that.If users are interested in weighting the root moisture by the depth of
penetration of roots or something more specific, that can either set up
their soil layers to correspond with the root zones or calculate the
fraction of moisture based on the penetration of the roots into each layer.My vote is to close this issue and the corresponding PR as a wontfix.
Thoughts?—
Reply to this email directly or view it on GitHub
#55 (comment).
from vic.
Thanks @tbohn for working through this. This is going to be left as a wontfix
and will be added to the output variables documentation as part of #154.
from vic.
Related Issues (20)
- classic and image drivers fail to build - Ubuntu 22.04 HOT 5
- NetCDF: Invalid dimension ID or name: Error getting dimension id MISSING HOT 1
- Segmentation fault when running image driver with LAKES = TRUE (cells with and without lakes) HOT 1
- layer 0 mineral bulk density (0.77000) must be less than mineral soil density(0.57000)
- New - Compile failure -- Resolved HOT 1
- ERROR: set_force_type.c:138: errno: None: Must supply netCDF variable name for WIND forcing file number 1
- [ERROR] ../../vic_run/src/CalcAerodynamic.c:119: errno: Numerical result out of range: Trunk space height below "center" of lower boundary
- Resloved--Can't Run vic_image.exe -g global,txt, and the error occured in the file of set_forcing_type.c HOT 1
- [QUESTION] Soil moisture fraction output with VIC v5
- Wpwp_FRACT MUST be <= Wcr_FRACT.
- multiple definition of 'xxx'; ... first defined here HOT 1
- Maximum Energy Error
- Clarification of forcing units HOT 1
- Why are there negative values in the sublimation of the snow in the canopy intercept in VIC 4.2.d?
- Compilation error with VIC5.1.0: "collect2: error: ld returned 1 exit status" HOT 3
- Erroneous VIC version reporting in image driver?
- VIC Image Driver CPU Limited? Ways to increase memory use? HOT 1
- an error in docker_vic HOT 2
- Bug in classic driver in VIC 5.1.0, not able to read forcing data HOT 1
- Dose it include the both infiltration and saturation excess runoff mechanisms like Liang and Xie (2001)?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vic.