Dynamical lakes and new lake cover map #1049
Conversation
…dynConsBiogeophysMod.f90 cv is kept constant at water cv for simplicity (altough there is a cv for each lake layer) TEMPORARY change
… as an history field. The history field only contains the heat content of the lake water itself, and is a column output.
Up until now, when computing the dynbal correction fluxes for transient glacier columns, we have been (1) counting the mass and energy in the ice column as if that is a real state, but on the other hand (2) NOT accounting for the fact that glacier columns don't represent the soil under glacier. These two issues work in opposite directions, but (1) dominates, because there is much more ice (and energy, I think) in the roughly 50 m of glacial ice than there is in a typical 50 m soil column. In discussing this issue with Bill Lipscomb, we came up with the idea of subtracting some baseline value from each glacier column. I think that, as long as we subtract the same baseline value throughout an entire simulation for a given column, we will still conserve mass and energy through dynamic landunit transitions. So, here we subtract baseline values from glacier columns, accounting for the two issues mentioned above: (1) we subtract the water and energy in the glacier ice, because this is a virtual state in CTSM, and (2) we add the water and energy from the vegetated column(s), to account for the fact that we don't have an explicit representation of soil-under-glacier (this carries the assumption that the soil-under-glacier has the same state as the initial vegetated state in that grid cell). We currently set these baselines in initialization, so they are set equal to the cold start state. Water and ice in the glacial ice stay fixed over the course of a simulation, so the cold start values should be the same as the current values at any point in time. The heat content of the glacial ice does change over time, but by subtracting this baseline value, we should be able to reduce the dynbal sensible heat fluxes. In a following commit, I plan to allow the user to reset these baselines at some desired point in the simulation. I think that, in general, this resetting would break conservation. But as long as it is done before the onset of transient glaciers, I think this should be okay. In this way, the user can minimize dynbal fluxes even further, by resetting the baselines after the system has spun up. Partially addresses ESCOMP#274
This will be needed on the restart file once we introduce a flag that allows the user to reset them at any point in the run.
Erik suggests making this a fatal error (even though Mariana at one point said that we should allow branch runs to succeed if they have the same namelist settings as the valid namelist settings for a startup run).
…namic lake land unit. Use similar to do_transient_crops
We want at least one restart test that covers the new reset_dynbal_baselines flag, to make sure restarts happen properly with this flag: the baselines set in the initial run should be preserved across restart. Also, change this test from ERS to ERP to catch errors related to changing processor count.
Ideally, we would keep begwb and endwb consistent with liq1, liq2, ice1 and ice2 in this respect - i.e., subtracting the dynbal baselines in all cases. However, this changes answers for methane in a way we want to avoid right now. See ESCOMP#659 for details.
PGI didn't like these long comment lines
…) and accounted for cases where pct urban + pct lake > 100, adjusting pct lake so that total is 100%
There are two files in NetCDF-4 format that the model uses. Copy these files to NetCDF-3 classic format and point to the new version in the CLM XML database (use nccopy -k classic). There are some machines that have trouble with reading NetCDF-4 files in pnetcdf. There are still some NetCDF-4 files for mksurfdata_map, but some of these are required to be in NetCDF-4 format. And we only support mksurfdata_map and mkmapdata on cheyenne.
The purpose of this merge is to get the dynbal baseline stuff that is in this branch tag but not on the release branch. Resolved Conflicts: src/biogeophys/TotalWaterAndHeatMod.F90
Merge dynbal baseline changes into dynlake branch
…d comments to code!
|
The dynlakes branch includes everything in branch_tags/ismip6.n01_release-clm5.0.25 and is up to date with the release-clm5.0.30 tag. I found issue #43, which might interfere with the dynlakes branch (not investigated in detail). When starting my simulations @billsacks had an first review and made the following comments: (1) You accidentally added some files. Not a big deal, but something we'll want to clean up before this is merged in eventually: $ git diff --name-status HEAD..Ivanderkelen/dynlakes | grep '^A' | grep -v dynlakeFileMod This was done intentionally, as requested by Erik to be able to update the mksurfdat tool to also take the new lake fraction map I created. (2) It looks like the code you added in surfrdMod – to read the haslake variable – will only work if there is actually a landuse_timeseries file present. Some runs don't have this, which would cause this code to crash. Not important to fix now, but we'll want to fix it eventually. (3) In dynSubgridControl, you prevent running with dynlakes and fates. I think these would be compatible. (We can't currently run with both transient veg and fates, but I think it would work to run with transient lakes & fates.) This originally came from following the harvest example. I deleted the lines preventing it but didn't test it with fates. |
|
@Ivanderkelen thanks a lot for sharing these changes with us! I won't get a chance to do a final review for a couple of weeks, but I'll look forward to doing so once I get a chance. However, there is some initial work needed here: Your branch was off of the release-clm5.0 branch, but we want to get this onto master, not release-clm5.0. I have gone ahead and moved your commits onto a new branch off of master. I thought this would be relatively quick for me to do, although it ended up being tricky due to a lot of merge conflicts. I have pushed this branch here: https://github.com/billsacks/ctsm/tree/dynlakes_master . I'd suggest the following next steps:
If you'd like, you can do steps (6) & (7) before step (5); I am partly recommending the above order because opening a PR can be a convenient way to examine the diffs. Either way is fine with me. In reviewing the diffs, pay particular attention to these files, for which there were git conflicts, but you should really look at everything because there may have been more subtle conflicts that git didn't pick up:
|
|
Closing this because, as noted above, a new PR is needed into master rather than the release branch. |
Description of changes
Dynamic lakes representing reservoir construction and new lake cover input map using HydroLAKES and GRanD data.
Specific notes
Contributors other than yourself, if any: @billsacks
CTSM Issues Fixed (include github issue #): #200
Are answers expected to change (and if so in what way)?
Any User Interface Changes (namelist or namelist defaults changes)?
New namelist handle use_dynlakes is added, off by default
Testing performed, if any:
(List what testing you did to show your changes worked as expected)
(This can be manual testing or running of the different test suites)
(Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide)
(aux_clm on cheyenne for intel/gnu and izumi for intel/gnu/nag/pgi is the standard for tags on master)
Succesfully ran test simulations with IHistCLM50Sp at f09_g17 and f19_g17 (1900-2017)
NOTE: Be sure to check your coding style against the standard
(https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review
the list of common problems to watch out for
(https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).