Add MALI data mode #111
Add MALI data mode #111
Conversation
MALI data mode uses the MALI component but rather than making prognostic calculations it reads an ice thickness field from a previous simulation. For now, it is assumed there is a single datamode file per mesh. This could be expanded if needed. Details: * replace MALI%STATIC, which is not being used, with MALI%DATA * set MALI namelist options appropriate for a data mode * add an input stream for data stream to MALI streams file when data mode is activated * add MPAS_DISLISIO_JRA1p5 compset (DIS=Data Ice Sheet) * remove two unused compsets that had reference %STATIC mode
|
I placed a data mode file at Testing with: @jonbob , when I try to run this test, I get an error, because MALI is trying to read time |
|
I believe JRA starts in 1958. |
|
JRA does start in 1958, but I don't think that's the issue. By default, tests use a STARTDATE of 0001-01-01. The data models have options for how they handle dates outside their range of actual data, like cycling or extending (basically using the first or last data value). So we have two use cases for JRA forcing: one where we start at 0001-01-01 and that lines up with the beginning of the JRA data (1958) and cycles over time; and one where we run inside the JRA date range and the model date is the same as the data date |
|
Thanks, @jonbob. MALI does not currently have a way to cycle dates on forcing files, so we'll need to talk through if we need to add that capability or if we can set up a compset that uses consistent dates for what we need data mode to do. The MALI simulation I am using starts in 2000 and ends in 2300 (but I will probably keep just the first 100 years, or maybe even less). @xylar and @cbegeman , what compset/forcing and year range do you think we should set up for this? Do you think a JRA-forced G-case is the right configuration for the ocean? If so, do you want to start in 1958 (JRA start date) or 2000 (MALI simulation actual start date)? And does it matter if the start year is the actual start year or year 0? Based on what we decide, I can adjust xtime in the MALI forcing file to match that convention, which I think is fine as we intend this to be schematic and not an actual ice-sheet history. |
|
Why aren't you doing this by making a dglc model analogous to docn and datm ? |
|
@rljacob -- it is one of the things we discussed, but wasn't sure who could do that |
|
@matthewhoffman -- we can make a testdef that changes the STARTDATE and a few settings for the JRA forcing to make it all consistent |
|
It sounds like from what @jonbob is saying that there wouldn't be a problem starting in 2000 and not changing MALI's dates. JRA seems fine, but I think that we should make sure AIS ice runoff is removed in this test, which would not currently be the case (https://github.com/E3SM-Project/E3SM/blob/d4ca7d0606930f53f30eb7ff7dbb92ec83b83b84/components/mpas-ocean/bld/build-namelist#L728-L733). |
|
I concur, let's start at 2000 unless that causes unexpected issues. |
| @@ -142,6 +142,11 @@ | |||
| <lname>2000_DATM%JRA-1p4-2018_SLND_MPASSI%DIB_MPASO%IBDISMFDATMFORCED_DROF%JRA-1p4-2018-AIS0ROF_SGLC_SWAV</lname> | |||
| </compset> | |||
|
|
|||
| <compset> | |||
| <alias>GMPAS-JRA1p4-DIB-PISMF-DIS</alias> | |||
| <lname>2000_DATM%JRA-1p4-2018_SLND_MPASSI%DIB_MPASO%IBPISMFDATMFORCED_DROF%JRA-1p4-2018-AIS0ROF_MALI%DATA_SWAV</lname> | |||
There was a problem hiding this comment.
based on discussion, change to JRA-1p4-2018-AIS0ICE option?
There was a problem hiding this comment.
and switch from 1p4 to 1p5?
There was a problem hiding this comment.
Based on Slack discussion, wait for a PR that fixes things so runoff is removed from G-Cases as it is from B-Cases. The, yes, switch to JRA1p5 but do not use any of the -AIS0* options so that MPASO takes care of the zeroing out.
There was a problem hiding this comment.
Update note: this PR will be rebased, and compset adjustments made, once E3SM-Project#6693 is merged.
There was a problem hiding this comment.
We need not to forget to do the rebase once E3SM-Project#6693 goes in, which I think will be soon.
@rljacob , to follow up more on this question, we've discussed this option but feel doing this through the MALI component is critical for a few reasons. This capability is serving as a quasi-coupling mode that helps us prepare the ocean model physics for an active, evolving MALI component. By having MALI replay the ice thickness history from a previous MALI simulation, we ensure that everything about the configuration is identical to what MPAS-Ocean and the coupler will be seeing when we finally transition to fully coupled ice sheet simulations. In particular, the ice-shelf basal melting functionality is in the coupler itself, as opposed to a component model, operating on the GLC grid at the OCN timestep, and is only enabled if GLC is active (and an ocean namelist is activated). Ensuring that those complex settings are working correctly with a new DGLC component would be extra work with little benefit. In particular, this does not seem worth the work because the data MALI mode is replaying previous MALI simulation output as a stepping stone towards full coupling, as opposed to existing data components that are replaying observations and meant to represent historical conditions accurately. We don't anticipate extending this capability to historical reanalysis of ice-sheet thickness, in part because such reanalyses don't really exist and are not expected to anytime soon. (Maybe this is more detail than you were asking for, but I wanted to have our offline discussions on this question documented.) |
|
Note for this PR: we discussed today that eventually we will need to create a MALI data mode version with the MALI 4km AIS mesh, but that will happen after the SORRM v3r4 ocean mesh based on the MALI initial condition is finalized. At that point, we will run a standalone MALI 4km simulation to generate the data mode history. That will all be part of a later, follow-on PR, and the 8km AIS data mode in the PR will still be useful for development and testing of MPAS-Ocean wetting and drying in the interim. |
This is necessary for MALI data mode input file, which starts in 2000.
This suppressed irrelevant errors for the oQU240wLI mesh.
|
After help from @jonbob , I got the start time and the JRA forcing time to be 2000-01-01. I've also updated the MALI data file to include monthly thickness fields from 2000-01-01 to 2100-01-01. @xylar, this PR is now ready for review. A run using the data mode can be created on Perlmutter with: If everyone is happy with it, I still need to put the data mode file on the LCRC server - right now it only exists locally on Perlmutter's inputdata space. |
There was a problem hiding this comment.
This looks great to me! I only have one suggestion, and it fits well with moving the data file over to LCRC.
I'd like to run a longer DISLISIO test but probably on Chrysalis once the data file is there, and that can happen once this is on E3SM. I think it's ready to be moved over there.
| # in MALI data mode, read an input stream with ice thickness monthly | ||
| lines.append(' <stream name="data-mode-input"') | ||
| lines.append(' type="input"') | ||
| lines.append(f' filename_template="{din_loc_root}/glc/mpasli/{glc_grid}/{grid_prefix}_datamode.nc"') |
There was a problem hiding this comment.
I think it would be a good idea to give this file a datestamp. That way, it could at least be updated and it would be clear which version was expected.
MALI data mode uses the MALI component but rather than making prognostic calculations it reads an ice thickness field from a previous simulation. For now, it is assumed there is a single datamode file per mesh. This could be expanded if needed. A new variant of LISIO is also added: MPAS_DISLISIO_JRA1p5