Skip to content

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

Merged

Conversation

mark-petersen
Copy link
Contributor

Design discussion Water Cycle mesh, 14km high resolution region.

@milenaveneziani
Copy link
Contributor

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 creation_machine, or something like that?

@proteanplanet
Copy link

@milenaveneziani

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 creation_machine, or something like that?

I like this idea.

@vanroekel
Copy link
Contributor

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.

@proteanplanet
Copy link

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.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

I'll try to slip in the Victoria Island GeoJSON by the weekend

@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.

@vanroekel
Copy link
Contributor

@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.

@proteanplanet
Copy link

@xylar

So my vote is to hold off on transects and include all modifications together in the next iteration of the mesh.

Great. Let's do it.

@milenaveneziani
Copy link
Contributor

Resolution looks good to me.

@vanroekel
Copy link
Contributor

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.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

@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.)

@vanroekel
Copy link
Contributor

@xylar no problem. Let me know when ready.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

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 base_mesh or culled_mesh stages. You can let me know if you run into trouble but @mark-petersen will likely be more help than me today.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

The latest images showing resolution and mesh construction steps:
cellWidthGlobal
mesh_construction

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

@vanroekel, hold off. The problem with the international dateline is still there. I can see it in my plot.

xylar added 4 commits June 4, 2020 19:57
The features have to have different names or only the first is
merged in.
It is not working as expected.
@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

Once again, the latest images showing resolution and mesh construction steps:
cellWidthGlobal
mesh_construction

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

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:

  • The geojson files need to have points that are strictly between -180 and 180 longitude and -90 and 90 latitude.
  • Shapes that cross the international date line must have exactly the same points at -180 and at +180 longitude to ensure they are periodic
  • A given "feature collection" from geometric_features can't have two features with the same name. So the "name" property really should contain something unique and meaningful, not just "region for CUSP mesh". A shape that crosses the international date line will need an "east" and "west" piece with unique names.
  • A transition in resolution must either be smooth or take place on land. The transition at the Kamchatka Peninsula (once I fixed the Kamchatka region, which was past -180) was not smooth in the ocean and will need to be revisited.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

@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.

@vanroekel
Copy link
Contributor

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?

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

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 ocean/develop, I'll be putting together COMPASS documentation. That's the proper place. Until then, I'm just trying to make people aware who happen to be paying attention.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

@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.

@vanroekel
Copy link
Contributor

Thanks @xylar, that makes perfect sense. I'm starting the spin up of this revision now.

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

I was able to get the Kamchatka Peninsula to transition more abruptly than beofre:
cellWidthGlobal

@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.

@vanroekel
Copy link
Contributor

@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

@vanroekel
Copy link
Contributor

But I should say I'm fine waiting for the next revision too. I'm happy to go with what's easier for you

@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

It's easy to push. Give me a couple minutes to commit.

xylar added 2 commits June 4, 2020 23:32
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.
@xylar
Copy link
Collaborator

xylar commented Jun 4, 2020

@vanroekel, okay, I'm done and calling it a night. Thanks for letting me sneak this last bit in.

@vanroekel
Copy link
Contributor

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"/>
Copy link
Contributor

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.

Copy link
Collaborator

@xylar xylar Jun 5, 2020

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!

Copy link
Collaborator

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.

Copy link
Contributor

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.

@vanroekel vanroekel merged commit cc6fd59 into MPAS-Dev:ocean/develop Jun 5, 2020
@xylar
Copy link
Collaborator

xylar commented Jun 5, 2020

Wonderful, nice to have this done! Thanks for shepherding it through, @vanroekel.

mark-petersen added a commit that referenced this pull request Aug 18, 2020
…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.
@mark-petersen mark-petersen deleted the ocean/WC14to60kmL60E3SMv2r02 branch March 3, 2021 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants