CDEPS
CDEPS copied to clipboard
ESCOMP
Make a data glc model
Around the time when we switch to using NUOPC as our standard way of operating in CESM – and at least before scientific testing begins in earnest for CESM3 – we want to have a data glc model. In addition to being useful in its own right, this will serve as a replacement for the current use of CISM2%NOEVOLVE – i.e., providing a static snapshot of glacier areas and elevations as well as providing a high-resolution grid onto which surface mass balance can be downscaled. So, unlike most data components, we'll want the system to remap lnd -> glc fields to the glc grid given by this data glc model.
@mvertens - see above for a high-level description.
In terms of the details of what's needed, we should involve others (@whlipscomb , @gunterl @Katetc ). My sense, though, is that the highest priority need is replacing CISM%NOEVOLVE mode. In that case, the data could be a single time slice with fields matching CISM's initial conditions. It seems like we could set this up in one of two ways (or others):
- Make the data glc directly read CISM's input file, with a bit of logic to transform the fields on the input file into the fields expected by the mediator (e.g., determining which points are ice-covered).
- Do a short run where we write glc -> lnd cplhist data. Store those data and use them to force dglc.
(2) would probably be easier up-front, but the advantage of (1) is that it would make it easier to keep the data glc consistent with CISM long-term, so if it's not too hard, this might be the best approach.
There are a couple of things that might make this more challenging than other data models:
- I'm pretty sure we'll want this to support multiple ice sheets in a given simulation, like CISM now does
- Unlike most data models, where they don't need anything sent back from the mediator, in this case I think we'll want the mediator to remap lnd -> glc fields onto the dglc ice sheet grid(s). This is useful because then you can output downscaled lnd -> glc fields. I'm not sure the dglc will actually need the capability to write these fields: it may be sufficient to write a mediator history file containing these fields... we should discuss this point further. But in any case, the mediator will need to do this remapping despite glc being a data model.
@Bill Sacks @.***> would it help to include an ice mask directly into the CISM input file to ease the work required to be done by the mediator? If so I can easily add it. I'll admit that I am a bit rusty with understanding the difference between data glc and NOEVOLVE. Shall we setup a meeting to talk about all of this?
On Fri, Apr 1, 2022 at 3:21 PM Bill Sacks @.***> wrote:
@mvertens https://github.com/mvertens - see above for a high-level description.
In terms of the details of what's needed, we should involve others ( @whlipscomb https://github.com/whlipscomb , @gunterl https://github.com/gunterl @Katetc https://github.com/Katetc ). My sense, though, is that the highest priority need is replacing CISM%NOEVOLVE mode. In that case, the data could be a single time slice with fields matching CISM's initial conditions. It seems like we could set this up in one of two ways (or others):
- Make the data glc directly read CISM's input file, with a bit of logic to transform the fields on the input file into the fields expected by the mediator (e.g., determining which points are ice-covered).
- Do a short run where we write glc -> lnd cplhist data. Store those data and use them to force dglc.
(2) would probably be easier up-front, but the advantage of (1) is that it would make it easier to keep the data glc consistent with CISM long-term, so if it's not too hard, this might be the best approach.
There are a couple of things that might make this more challenging than other data models:
- I'm pretty sure we'll want this to support multiple ice sheets in a given simulation, like CISM now does
- Unlike most data models, where they don't need anything sent back from the mediator, in this case I think we'll want the mediator to remap lnd -> glc fields onto the dglc ice sheet grid(s). This is useful because then you can output downscaled lnd -> glc fields. I'm not sure the dglc will actually need the capability to write these fields: it may be sufficient to write a mediator history file containing these fields... we should discuss this point further. But in any case, the mediator will need to do this remapping despite glc being a data model.
— Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CDEPS/issues/25#issuecomment-1086335169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6QV6ADVEQLMGM5KKKPX73VC5SETANCNFSM4QSCCE4Q . You are receiving this because you were mentioned.Message ID: @.***>
-- Gunter Leguy, Ph.D (he/him) Project Scientist National Center for Atmospheric Research cell: (575) 418 1021 desk: (303) 497 1790
Maybe. I think this needs some discussion. My recollection is that CISM determines the ice mask based on some rules about minimum thickness - though maybe the minimum thickness is simply 0 m for this purpose (I can't remember off-hand). I'm not sure if it will make a big difference one way or another if this field is precomputed and kept on the initial file or computed by data glc, but let's discuss this along with other questions about how this should be done.
Yes, a meeting would probably be good. I'm not sure if it makes sense to do this soon or wait until people have time to work on this. What do others prefer?
@billsacks, I'm happy to meet and talk. But if this isn't urgent, my preference would be to wait until after we make some progress on the time definition. I'm starting to feel overwhelmed with all the issues on the table.
@whlipscomb - this is definitely not urgent. We just wanted to put a place holder for this on the task lists for CESM3 and I offered to take it on. I agree that the time definition is a much high priority.
@mvertens - following up from our discussion today: if we go with option (1) from https://github.com/ESCOMP/CDEPS/issues/25#issuecomment-1086335169, example CISM input files are (in the inputdata repository):
Greenland: glc/cism/Greenland/greenland_4km_epsg3413_c171126.nc
Antarctica: glc/cism/Antarctica/ISMIP6_Antarctica_8km.init.c210908.nc
The associated mesh files are:
Greenland: /glade/campaign/cesm/cesmdata/inputdata/share/meshes/greenland_4km_epsg3413_c170414_ESMFmesh_c20190729.nc
Antarctica: /glade/campaign/cesm/cesmdata/inputdata/share/meshes/antarctica_8km_epsg3031_ESMFmesh_c210621.nc
We'll have to talk more about exactly what to read in and what to send to the mediator, but I think we'd need to read the thk and topg fields, and then would send fields derived from those.
@whlipscomb @gunterl @hgoelzer- I'm happy to take the lead on this. I'd like to have clarification on what to read in and what to send to the mediator.
For an initial cut, I think we should reproduce what's done here:
https://github.com/ESCOMP/CISM/blob/main/libglad/glad_output_states.F90
Also see min_thck in https://github.com/ESCOMP/CISM/blob/main/libglad/glad_constants.F90
From discussion today:
Michele Petrini and Heiko Goelzer say they'd be very interested in using the data glc model for transient runs, where you would have transient runoff from the data glc model in addition to transient glacier area and topography.
There would probably be multiple modes of DGLC: one to mimic the current NOEVOLVE mode, and a different one to handle these transient things.
From discussion today:
Michele Petrini and Heiko Goelzer say they'd be very interested in using the data glc model for transient runs, where you would have transient runoff from the data glc model in addition to transient glacier area and topography.
There would probably be multiple modes of DGLC: one to mimic the current NOEVOLVE mode, and a different one to handle these transient things.
There has been some discussion of handling the seasonal reservoirs of snow capping excess in the data glacier model rather than CLM. This could help reduce the negative ocean fluxes from CLM/glaciers in no-evolve mode. This plus the algorithm proposed by Bill L for transient simulations would both need to be implemented in this more complex mode. Details are still fuzzy here, but I'd like to connect this conversation with the CTSM negative ice fluxes issue in case we do decide to move the implementation from ctsm to dglc.
Thanks for making that connection, @Katetc . I think that this extra handling you mention would be implemented even in the simpler DGLC mode, which would be acting like the current CISM%NOEVOLVE mode.
I think this is complete with #268. @mvertens do you agree? Can this be closed as completed?
