E3SM
E3SM copied to clipboard
E3SM-Project
Add new RRSwISC6to18E3r4 ocean and sea-ice mesh
Long name: RRSwISC6to18L80E3SMv3r4
This RRS (Rossby-radius scaled) mesh has:
- 6 km resolution near the poles
- 18 km resolution at the equator
This is a proposed E3SM v3 (E3) high resolution (near-eddy-resolving) mesh. This is revision 4 (r4) of the mesh, which includes a bug fix in land-locked sea-ice cells (https://github.com/MPAS-Dev/compass/pull/752). This is the primary difference compared with #6119.
The mesh was created using compass, specifically this PR: https://github.com/MPAS-Dev/compass/pull/754 A compass tag will be created for the mesh as soon as the PR is merged.
The mesh and forthcoming simulation results will be reviewed here: https://acme-climate.atlassian.net/wiki/spaces/OO/pages/4034658887/Review+RRSwISC6to18E3r4
G- and B-case simulations will begin shortly and analysis will be posted here and on the review page as soon as it is available.
@jonbob, this branch is ready to have mapping, domain and other coupling files added. I have shortened the time step to 5 minutes instead of 6 following our discussion of #6119.
I have synced over the Compass files to /lcrc/group/e3sm/data/inputdata/. I hope I have made fewer mistakes this time than before the break...
@vanroekel @proteanplanet @erinethomas @jonbob at least one of you needs to approve this.
@vanroekel, @proteanplanet and @erinethomas -- as the reviewers, what kind of information would you like to see in order to sign off on this PR? We have a couple of G-tests that have gone over 20 years, though they all have issues. I can post the links to mpas-analysis of those tests here, if that would be useful
Here's a link to MPAS-Analysis for years 4-20 for 20240228.HR-G-3Drestore.chrysalis, which shows the mesh but ultimately failed due to thick seaice in fjords and similar Antarctic inlets:
20240228.HR-G-3Drestore.chrysalis_yrs4-20
We currently are trying to solve this issue by increased spreading of frozen runoff, but maybe this will show enough results to allow this PR to be merged
In the process of running this G-case simulation, we have run into a crash that is due to thin water columns evacuating. These water column thickness changes seem to be dynamical (no surface thickness fluxes are strongly negative).
In order to make this mesh more robust, we believe that the minimum initial water column thickness should increase to 20m. The minimum water column thickness is currently 3m in ice shelf cavities and 6m in the open ocean, 1-2m per layer over 3 layers. We would like to retain 80 vertical layer grid and "dig" the bathymetry to enforce this minimum thickness. I believe this will result in more than 3 vertical layers in these cells.
A contributing factor toward the water column evacuating in these cells is the fact that the minimum water column thickness had not accounted for the ~5m possible depression of the sea surface by sea ice pressure. Thus, in principle the current mesh could have cells evacuated by sea ice growth alone (see below). In practice, we found that dynamic ocean pressure evacuated the 3m initial water column with only ~2m of sea ice growth and caused the model to crash.
We propose a minimum column thickness of 20m. By increasing the minimum water column thickness to 20m, the maximum possible sea ice depression is limited to 25% of the water column (resulting in 15m thick water column).
A few mesh stats to put this in perspective (wct = water column thickness): total cells in mesh: 4,085,395 cells with wct < 20m: 53,312 cells with wct < 20m and land ice pressure > 0 Pa: 2,170 cells with wct <= 5m: 13 cells with wct <= 5m where sea ice could grow (i.e., lies outside ice shelf cavities and could be totally evacuated just by sea ice growth): 2
We don't want to just fix those 2 cells because dynamic sea surface height changes could potentially lead to evacuated cells elsewhere. We'd rather have a nice buffer to be confident we won't crash the model late in the game.
The "we" here includes: @alicebarthel @maltrud @proteanplanet @erinethomas
I'm onboard with those changes to the mesh.
I can keep the existing land-ice mask and horizontal grid, and proceed with those changes. That would not require new mapping and domain files.
However...
@vanroekel also pointed out to me (presumably through @maltrud or others of you analyzing the mesh) that there are many single-cell or 2-cell ice shelves around the Antarctic Peninsula:
While I believe these are part of the BedMachine Antarctica dataset, I would be glad to remove them (by flood filling the ice sheet so we only include ice that is directly attached to it).
He also pointed out that there is at least one hole in an ice shelf:
Presumably a flood-fill technique on the original data set could remove that as well.
Fixing these issues would change the coastline and land-ice mask, requiring new mapping and domain files. It would also take a bit longer than just fixing the vertical coordinate.
@vanroekel, @jonbob, @cbegeman, @alicebarthel, @maltrud, @proteanplanet, @erinethomas, please let me know what you prefer.
By the way, I'm sorry for not thinking enough about these issues when I generated the mesh. In retrospect, it should have been obvious that certain parameters needed to be re-examined with the higher vertical resolution.
I don’t have strong feelings about the fixes to the horizontal mesh. I haven't seen any troubling behavior yet from the ocean perspective in the vicinity of these grid cells (I looked closely at the "hole," less closely at the 1-2 cell ice shelves). I can't speak to whether thick sea ice cells are a concern from the perspective of MPAS-Seaice stability or whether redoing the mesh is more work than masking out these cells for certain analyses like total sea ice volume.
Even though the thick sea ice doesn't seem to be impacting the ocean solution, I think the holes may be responsible for the very thick sea ice and I would advocate that we fix that. I feel less strongly about altering the few cell land ice cavities.
@vanroekel or @maltrud, can you let me know where the hole is or if there are more than one?
@xylar -- thanks for jumping in. For my part, I'm happy to quickly make new mapping and domain files if needed -- I would advocate for doing what we think is best with the horizontal mesh and not worrying about any extra work.
@xylar here is an image from paraview with the cell IDs. remember it is C indexing (not Fortran).
cells 974168, 974167,976767,976768
@xylar I'm really happy to hear that a flood fill should fix these problems. I was thinking the same thing--I have no idea how to do it, but was sure that you do. I haven't done an exhaustive search for other holes, but I think we would have had the same runaway sea ice problem if there were others, which I haven't seen.
and independently of any stability problems, etc, I do think it is important to make sure there are no isolated bits of land ice that aren't connected to land.