-
Notifications
You must be signed in to change notification settings - Fork 22
Improve demand #334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve demand #334
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work and great additions! Looks good to me, just a couple of small typo's and questions, after that we are good to merge I think!
elevtn_map="dem_subgrid", | ||
) | ||
|
||
assert "RiverDepth" in mod.grid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets say the manning method did produce a RiverDepth map, but the gvf method did not. Will this test capture that? I think it will not flag it right, since the RiverDepth is already part of the grid due to the previous method.
In addition, should we also do a similar test for the powlaw method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not the best test but if there is any error (eg missing dem_subgrid map which was the curretn issue) then the method itself will error. So the assert is not really the goal but justchecking that the method runs without errors. For powlaw we are testing when we build models as this is the default method. Is this test okay then? Or do you want me to test further with some values check or other?
Discussed this with Hélène, the one remaining comment is not to bad, I just added an explanation as a comment for future reference. Since Joost seems to be out of office, so I'll be merging this. |
* add domestic from population * add irrigation from vector * small bugfixes * update changelog * small adjustment * improve docs of setup_rivers * bugfix river depth with manning or gvf methods * add infiltcapsoil mapping from texture * update after review * proper pin of hydromt to avoid getting v1 alpha installed * Update test_model_methods.py * fix: linting --------- Co-authored-by: Sam Vente <[email protected]>
Issue addressed
No issue created.
Adds two new methods for water demands:
It also adds an extra argument to setup_allocation_areas to filter subbasins that would be too small (eg if a river meanders very closely to another admin area then very small allocation areas can be created).
Explanation
I already encountered twice that local irrigated areas are in vector format rather than raster and we have a good method in core to treat vector data (grid_from_geodataframe with method fraction) so that avoids to loose too much data for a user that would first need to rasterize the map themselves and risk loosing info.
Secondly I think getting demand based on consumption per capita was already on the wishlist and it already poped up for the same study so I went ahead and added. In another version, I guess we may want to have these statistics stored in a admin area shapefile rather than a constant value but this will be a new feature for later.
Checklist
main
Additional Notes (optional)
I should have done it in another PR but while working on the same model, I realised that computing river depths in setup_rivers using manning or gvf methods was apparently broken for two years....
And while this PR is still open for review, I also added that parameters can be derived based on soil texture mapping with default values for InfiltCapSoil. I'll put the references (USDA, FAO) when we update the v1 docs together with the review of parameters for landuse.