-
Notifications
You must be signed in to change notification settings - Fork 353
New Mesh: WC14to60kmL60E3SMv2r02 #584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Mesh: WC14to60kmL60E3SMv2r02 #584
Conversation
testing_and_setup/compass/ocean/global_ocean/WC14/init/define_base_mesh.py
Show resolved
Hide resolved
testing_and_setup/compass/ocean/global_ocean/WC14/init/config_E3SM_coupling_files.ini
Outdated
Show resolved
Hide resolved
All, I was thinking: since the mesh creation process is BFB for a specific machine (right?), would it make sense to add an entry in the metadata, something like |
I like this idea. |
All as mentioned in #555 I would like to move this forward and focus our discussion / acceptance on the regions of high resolution only. @proteanplanet, @milenaveneziani, @maltrud, @lconlon, and @qingli411 please offer your thoughts on whether these regions are acceptable or if you'd like changes. I would like to move toward testing a first revision by the weekend. |
I vote to move ahead with WC14. I'll try to slip in the Victoria Island GeoJSON by the weekend, but we should proceed regardless since that's not going to change much. Aside from that, I think we should proceed with all other passages and seas as they are. |
@proteanplanet, I don't see a feasible way of getting that transect into the mesh in time for a spin-up starting this weekend. Even if you create the geojson file, it would either need to be put in "properly" through geometric_features, requiring a new release of that software and an updated compass environment with that new version of geometric_features or it would need to be included in this mesh as a one-off using #586, which hasn't been reviewed or tested yet by anyone but me. So my vote is to hold off on transects and include all modifications together in the next iteration of the mesh. |
@proteanplanet I agree with @xylar here. I would like to approve and merge this mesh today based on the regions of high resolution only. This will definitely not be the final e3sm WC mesh and we will revisit transects, passages, islands, in a later revision. Please approve based on the resolution distribution of the mesh alone today. Also cc'ing @milenaveneziani for her approval. |
Great. Let's do it. |
Resolution looks good to me. |
Thanks all! I'm going to grab this and do the MPAS spin up shortly. @pwolfram and @mark-petersen do you want to push a fix for the mesh gradations noted by @pwolfram in #555? I'm also okay waiting for that for the next revision. I doubt it will make much impact on the large scale flow. |
@vanroekel, wait just a bit. I pushed the resolution around Norway further north east and I also realized that my fix of the Bering Sea region only went into the 12 km mesh, not the WC14 version. (I didn't realize @mark-petersen made a copy -- I don't think this is what we want to do in the future.) |
@xylar no problem. Let me know when ready. |
Okay, I pushed my changes. I'm testing them now but if you want to get started, go ahead. I'll let you know if I run into trouble in the |
@vanroekel, hold off. The problem with the international dateline is still there. I can see it in my plot. |
The features have to have different names or only the first is merged in.
It is not working as expected.
Some lessons for COMPASS meshes@mark-petersen and others who will be working on meshes with geojson regions in the future, here are a few point to keep in mind:
|
@vanroekel, I am finally done for now. I don't think a re-review by any of the others should be needed because the changes I've made were either minor or related to the lack of periodicity at the date line. |
thanks @xylar I'll take this and move toward E3SM testing. Related to your points above, do you have any suggestions on where we could post those lessons so we don't have to remember they are in this PR later? |
Once #472 gets merged to |
@vanroekel and @pwolfram, just FYI I'm still working on getting the Kamchatka Peninsula to look "right" but that will definitely be something for the next iteration. |
Thanks @xylar, that makes perfect sense. I'm starting the spin up of this revision now. |
I was able to get the Kamchatka Peninsula to transition more abruptly than beofre: @vanroekel, I'm not going to push any new commits to this branch unless you give the go-ahead. So let me know if/when you would like these changes. |
@xylar if it is easy for you to push now (I know it's getting very late for you) I can pull it in. I was just about to start the spin up |
But I should say I'm fine waiting for the next revision too. I'm happy to go with what's easier for you |
It's easy to push. Give me a couple minutes to commit. |
Two different transition masks are defined, one for east of the peninsula and one for west of it, with a transition right down the center of the peninsula. A key to a smooth transition is that the shapes defining the "east" and "west" regions have the same behavior south of the southern tip of the Peninsula.
@vanroekel, okay, I'm done and calling it a night. Thanks for letting me sneak this last bit in. |
Thanks to you as well for the hard work @xylar! I'm going to run the spin up then merge this we can then move deeper analysis to an r03 PR to be opened. |
|
||
<namelist name="namelist.ocean" mode="forward"> | ||
<template file="template_forward.xml" path_base="script_configuration_dir"/> | ||
<template file="template_monthly_output.xml" path_base="script_configuration_dir"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xylar and @mark-petersen this is causing a failure at this stage of the spin up because this line wasn't included in streams below as well, but even doing that template_monthly_output.xml
did not include timeSeriesStatsMonthlyRestart
. I can make these changes, but my question is if we should do this here, since the xml template doesn't appear to be part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vanroekel, this was part of the reason for an issue I posted in April: #525
In my view, any changes you have to make to config_test_final_settings.xml
are fair game for this pull request and hopefully would let us close #525. I would have like to have this addressed in a separate PR but that obviously didn't happen and now is the time. Sorry for the mess!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My suggestion would be to remove timeSeriesStatsMonthlyOutput
because:
- it doesn't work well unless you run for a full month
- it doesn't work well if you don't start at the beginning of a month
- spin-up isn't always compatible with running for exactly 1 month prior the
test_final_settings
stage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree I would prefer to just disable timeSeriesMonthly
. I will make the change.
Wonderful, nice to have this done! Thanks for shepherding it through, @vanroekel. |
…elop Add support for custom critical passages and land blockages #586 This is added to support potential addition of "custom" passages or blockages in #555 and #584. The custom transects could come from a local file or it could be pulled in from geometric_features, e.g. with the merge_features command.
Design discussion Water Cycle mesh, 14km high resolution region.