Dynamical lakes and new lake cover map

[Ivanderkelen]

Description of changes

Dynamic lakes representing reservoir construction and new lake cover input map using HydroLAKES and GRanD data.

Update (2020-08-17): this will be split into two separate PRs; this PR will just contain tools changes, and a new PR (which will come to master first) will contain all other changes.

Specific notes

Contributors other than yourself, if any: @billsacks

CTSM Issues Fixed (include github issue #): none

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)

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).

[Ivanderkelen]

Thanks, @billsacks for your feedback. I am now in the process of reviewing the diffs of this branch relative to master, and will notify you here, once this is finished and I got some testing done.

[Ivanderkelen]

I found issue #43, which might interfere with the dynlakes branch (not investigated in detail).

Also note, these developments add lake water and heat to the total gridcell water and heat content, and consequently, TWS now includes lake water, as it didn't do before.

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
A tools/mksurfdata_map/landuse_timeseries_hist_16pfts_Irrig_CMIP6_simyr1850-2015.txt
A tools/mksurfdata_map/landuse_timeseries_hist_dynlake_simyr1900-2009.txt
A tools/mksurfdata_map/surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr1850_c190722.namelist
A tools/mksurfdata_map/surfdata_1.9x2.5_hist_16pfts_Irrig_CMIP6_simyr1850_c190715.namelist

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.

[billsacks]

I found issue #43, which might interfere with the dynlakes branch (not investigated in detail).

Thanks for bringing that to our attention. My sense is that #43 should be resolved at some point, but it isn't critical for the first iteration of the dynamic lake work. It is likely needed for the correct operation of the methane code with dynamic lakes, though (which is active when running with Bgc compsets, not with Sp [satellite phenology]). If you have time to look into it at some point in the next few months, that would be great, but I don't think that should hold up bringing your initial changes to master.

[billsacks]

• One other change I realized will be needed here: adding the HASLAKE variable to the landuse timeseries file (I don't see that being written right now, but the code will require it).
  • Update (2021-12-20): I'm thinking we might want to use PCT_LAKE_MAX instead of HASLAKE (see also Improve mechanism for determining where to allocate memory for urban when running with dynamic urban #1572 (comment))

[ekluzek]

@billsacks instead of having a variable on the file -- why doesn't it just check for the existence of the lake variable on the file? I don't see the need for a separate variable to say that another variable exists. You should be able to check the variable for existence and then use that to set the logical flag for it in the code.

[billsacks]

@ekluzek HASLAKE is a spatial variable that says whether there will be any lake area at any point in the timeseries.

[ekluzek]

Ahh, now that makes sense. I should've looked at the code first. But, thanks for that clarification.

[Ivanderkelen]

since both lake and PFT's only change yearly, you just keep a yearly time axis, but have either lake or PFT repeat it's first or last years if it's not available over the same time range.
In this case PFT's change over 1850 to 1899, but lakes start at 1900. So lake will use the value of 1900 for 1850 to 1900. then at that point they are in sync until the end of the series in 2000. Similarly for future scenarios, lake would then be constant for years after 2000. That way you don't have to have two landuse.timeseries files, although you do then have a lot of times where lake has the same value for quite a few time-slices. But, I think that's OK.

Good point. As long as lakes are the ones with fewer available years, this won't be a big deal. If there were many years for lakes where we did not have PFT data, that would start to lead to wasted space, but we can deal with that later, if that ever becomes an issue.

• So then we will need logic either in mksurfdata.pl (when building the text file) or in mksurfdat.F90 (when looping over years) to replicate years of lake data when necessary. (Or I suppose we could just manually replicate the file names in the xml if both of these possible solutions end up being hard to implement.)

Thank you @ekluzek and @billsacks for looking the review! I am now back and ready to work on this.

• About the time periods: I have 'newer' the lake maps spanning the period 1850-2017. There is a file for every year, and when lake surface area stays the same it is a copy of the previous year. The raw files are located here: /glade/work/ivanderk/inputdata/rawdata/timeseries/.
  The data originates from the vector-based GRanD and HydroLAKES databases, and are converted to raster using the following tool: https://github.com/VUB-HYDR/polygon_to_cellareafraction
  They will have to be transferred to an official location at one point. Let me know if any actions are required from my side for this.

• I have also and updated namelist file on this, if desired I can add this to the repo. /glade/u/home/ivanderk/clm5.0/tools/mksurfdata_map/surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr1850_c200217.namelist

[billsacks]

@Ivanderkelen I should add: please wait to do any major work on mksurfdat.F90: I have a small set of changes coming to master today or early next week (#1119 ) and you'll get conflicts if you try to do some of the rework I suggested before then. So, once #1119 is merged, you should update your branch to the latest version of master, then can do the rework I suggested.

[billsacks]

• Comparing the changes in this PR with those done by @keerzhang1 in Enable the mksurfdata_map to generate landuse_timeseries for dynamic urban and lake #1579, one difference I see is the removal of this change_landuse call in the time loop in this PR (it was left in place in Enable the mksurfdata_map to generate landuse_timeseries for dynamic urban and lake #1579). It probably doesn't matter hugely, but I'm thinking that it's probably best to leave this call to change_landuse in place, as is done in Enable the mksurfdata_map to generate landuse_timeseries for dynamic urban and lake #1579 .

[billsacks]

The relevant changes from this PR are now incorporated into #1579 (by @keerzhang1). I have also made a few notes in that PR summarizing the relevant outstanding discussion in this PR. Therefore, I am closing this PR since it is superseded by #1579 . Thank you, @Ivanderkelen , for all of your work on this PR, which provided a very helpful basis for #1579 !