Update lake dataset in mksurfdata_esmf

[ekluzek]

We have a new updated lake dataset from @Ivanderkelen that we will put into place for the next set of surface datasets that we create.

Here's Inne's current sample file:

/glade/u/home/ivanderk/clm5.0/own_inputfile/mksurf_LakePnDepth_3x3min_simyr2009_csplk_c190603.nc

This file is currently in the PR #1073

[Ivanderkelen]

A small update and more info on this: lake surface datasets are available for each year 1850-2017, reflecting the construction of reservoirs. These are created based on the GRanD and HydroLAKES databases and rasterised using this tool: https://github.com/VUB-HYDR/polygon_to_cellareafraction

The sample files (for 1850,1900 and 2017) are located here:
/glade/work/ivanderk/inputdata/rawdata/timeseries/mksurf_LakePnDepth_3x3min_simyr1850_MODISgrid_c200304.nc
/glade/work/ivanderk/inputdata/rawdata/timeseries/mksurf_LakePnDepth_3x3min_simyr1900_MODISgrid_c200310.nc
/glade/work/ivanderk/inputdata/rawdata/timeseries/mksurf_LakePnDepth_3x3min_simyr2017_MODISgrid_c200305.nc

These contain also the lake depth from HydroLAKES and could be created for any year.

[billsacks]

This may be done. @slevisconsulting will check.

[slevis-lmwg]

The new mksurdata_esmf has been pointing to the new transient lake files.

However, it has NOT been pointing to the new baseline lake files for time-slice simulations. To correct this I will change code to pick up the 1850 file for 1850 simulations and the 2000 file for 2000 simulations. Pls let me know if this sounds incorrect.

[wwieder]

Sounds correct to me, Sam

On Fri, Sep 9, 2022 at 5:43 PM Samuel Levis ***@***.***> wrote: The new mksurdata_esmf has been pointing to the new transient lake files. However, it has NOT been pointing to the new baseline lake files for time-slice simulations. To correct this I will change code to pick up the 1850 file for 1850 simulations and the 2000 file for 2000 simulations. Pls let me know if this sounds incorrect. — Reply to this email directly, view it on GitHub <#1106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5IWJAPCAQRYVROB3JEAPDV5PDQHANCNFSM4P6WOD7Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Will Wieder (he/his) Project Scientist & Land Model Working Group Co-Chair CGD, NCAR 303-497-1352

[slevis-lmwg]

For mksurfdata_esmf to generate fsurdat files for time-slice cases using the new lake files, I had to add the variable LAKEDEPTH to the year-2000 and year-1850 lake files. For simplicity I hardwired LAKEDEPTH = 10 m.

[slevis-lmwg]

This post earlier in this issue suggests that files already existed for time-slice cases, so I will point to those.

[slevis-lmwg]

This post earlier in this issue suggests that files already existed for time-slice cases, so I will point to those.

Discussed this with @ekluzek who expressed concern about consistency between the time-slice files, which contain LAKEDEPTH and PCT_LAKE, versus the transient files, which contain only PCT_LAKE. Suggested options:

• Add LAKEDEPTH to the transient files to ensure consistency with PCT_LAKE. Likely not trivial.
• Change the code to read LAKEDEPTH and PCT_LAKE from separate files, the former from time-slice, the latter always from transient. Does not ensure consistency between the two variables, but ensures that the model uses the same PCT_LAKE for the same years (e.g. 1850 or 2000) regardless of transient or time-slice.
• Do nothing. I have confirmed that PCT_LAKE is the same in both 1850 files and both 2017 files (transient and time-slice). Inconsistency in PCT_LAKE will arise when running a 2000 time-slice versus transient simulations that include the year 2000.

Note that mksurfdata_esmf fills the map with LAKEDEPTH = 10 when it needs to.

@ekluzek will add this to the agenda of next Thursday's software meeting (9/22).

[slevis-lmwg]

From 2022/9/22 software meeting:
@billsacks asked and I confirmed that LAKEDEPTH in the three baseline files 1850, 1900, 2017 is identical. With this in mind, the recommended solution is to stop reading PCT_LAKE from the baseline files and to rather always read PCT_LAKE from the transient files.

[slevis-lmwg]

[...] the recommended solution is to [...] always read PCT_LAKE from the transient files.

This is now done in #1732

[slevis-lmwg]

This was addressed in #1732 so I'm closing this issue.