Plots of resolution

The new EC grid can be found here:

/lustre/scratch4/turquoise/xylar/test_EC15to60/ocean/global_ocean/EC15to60/

I'm still spinning it up (and probably doing so very inefficiently) but this should be a good starting point for you to play around with the new mesh.

For now (for comparison with the EC60to30 mesh), we're running with 60, not 64 vertical levels:

nVertLevels = 60 ;
nCells = 220321 ;
nEdges = 671300 ;
nVertices = 450694 ;

@xylar or @mark-petersen before this develops too much further, can we socialize this mesh with water cycle as well, especially if there are discussions within cryosphere of this potentially being the default v2 low res mesh? I don't think anyone outside cryosphere has been a part of this discussion for developing this mesh. Looking at this, I like the cell count, but am worried the equatorial region is too coarse. I'm concerned that the transition zone will harm tropical instability wave fidelity and potentially degrade ENSO fidelity as well.

@vanroekel i've been fully involved with this, even safe to say i've been driving it. i want to emphasize that it is not intended to be the default v2 mesh, but if it looks good it could be a prototype. my main purpose is to see if a ec60to30-like grid with ~15km resolution in the subpolar gyre gives us a more realistic AMOC. i didn't notice if the latest has the narrower equatorial band--if it does, that could be interesting to test, as well.

@vanroekel, I can't find Chris Golaz's GitHub username. Feel free to mention him or add him as a reviewer.

@mark-petersen's argument for tighter resolution around the equator was based on:

1. a discussion with FESOM developers at AWI that suggested this and
2. The following figure suggesting that this should be sufficient to capture the major equatorial current:
   

However, I'm sure discussion is welcome, and would also help us with revisions to our SO refined mesh (#518)

@xylar perhaps I'm not clear from the figures about the equatorial region. Is the 30 km region 7.5degrees or 10 or something else? The figure you post suggests we should use 10, which I think is perfect, but one of your figures, I think on the SO mesh one seem to show a transition at 7.5. Could you let me know what your cutoff is? Thanks

one other question. Would you like me to suggest any parameter settings for this mesh? I saw a few spots saying values should be changed. I'm happy to help. One thing I want to make sure of is that we use the config_eddy_resolution_taper = 'ramp' and not constant.

one other question. Would you like me to suggest any parameter settings for this mesh? I saw a few spots saying values should be changed. I'm happy to help. One thing I want to make sure of is that we use the config_eddy_resolution_taper = 'ramp' and not constant.

It doesn't hurt to change these parameters here for the spin-up but it's probably more important for the E3SM pull request when that happens. I'll point out where these changes would go and you can use the GitHub suggestion feature to essentially edit the code here if you want.

I think this version looks pretty good, subpolar gyre-wise. What is the max GM that you're using?

What is the max GM that you're using?

I don't think we've got far enough to decide that yet, and would certainly welcome input. @maltrud, @milenaveneziani, etc. what is the default?

I'd imagine we would use a value of 600, which is the default for other EC6030 Gcases, but it is something we could and maybe should test.

I'd imagine we would use a value of 600, which is the default for other EC6030 Gcases, but it is something we could and maybe should test.

Sounds good. Happy to help with any testing if needed.

We used a max GM of 600 for the ARRM meshes, but in those simulations we don't have 3d GM.

@maltrud, is testing progressing on this mesh at all? Or are you still stuck? No rush, since you were the one that requested this one but figured we could put in some results here if we wanted.

At some point, we probably want to merge this just to document this version of the mesh, even if it isn't our final E3SM v2 EC mesh.

@maltrud could you summarize your testing on this mesh? I seem to remember you saying we won't want this for v2, but don't remember the reason. As @xylar mentions in a comment above we should merge this to document, but it would be great to have a summary of what we might want to change for an r02 version of this mesh.

It sounds like this hadn't made it far enough in testing that we can use it for E3SM v2. Nevertheless, I would like to have this rebased and merged for documentation purposes.

Actually, I don't want to merge until #563 and #577

Unfortunately, this branch was never merged and COMPASS has moved on to the point where it is not feasible to merge now.

I have created a branch on the new COMPASS repo to preserve this branch in case we need to recreate the mesh: https://github.com/MPAS-Dev/compass/tree/EC15to60E2r1