Update lake dataset in mksurfdata_esmf
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
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.
This may be done. @slevisconsulting will check.
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.
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 https://github.com/ESCOMP/CTSM/issues/1106#issuecomment-1242560614, 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
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.
This post earlier in this issue suggests that files already existed for time-slice cases, so I will point to those.
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).
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.
[...] the recommended solution is to [...] always read PCT_LAKE from the transient files.
This is now done in #1732
This was addressed in #1732 so I'm closing this issue.