Skip to content
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

Ice Shelf Front Effect #3

Open
claireyung opened this issue Sep 14, 2023 · 10 comments
Open

Ice Shelf Front Effect #3

claireyung opened this issue Sep 14, 2023 · 10 comments

Comments

@claireyung
Copy link
Collaborator

Just a quick note to show that the ice shelf front has a big effect. 2D triangular ice shelf, fixing the salinity bug as documented here https://github.com/claireyung/simple_shelf_salt_bug.

Simple Shelf:
image

Simple Shelf with an Ice Front:
image
(note run for different lengths of time)

Velocities in "fixed" (2D) case go up from 10^(-8) to 10^(-4) when vertical ice shelf front added. Probably due to "traditional" pressure gradient truncation errors with the very steep SIGMA_SHELF_ZSTAR coordinate at ice front.

@adele-morrison
Copy link
Collaborator

How vertical is that shelf front? Is it improved much if it's more sloping? And is having a more sloping front ok or not? I think you said for ISOMIP+ that most people flattened the slope of the front?

@claireyung
Copy link
Collaborator Author

Yes that one was vertical, going from 200m to 0m in adjacent horizontal cells. Making the 200m rise at the front go over 2,4 or 8 horizontal cells scales quite nicely to get smaller velocities.

Note all Boussinesq with the salt initialization hack fix.

image

@pedrocol
Copy link
Owner

Is the behaviour the same one in z-star?

@adele-morrison
Copy link
Collaborator

So that means these errors are reasonably small for this case then right? Because noone's going to complain too much if we have a slightly sloping ice shelf front?

@adele-morrison
Copy link
Collaborator

adele-morrison commented Sep 14, 2023 via email

@claireyung
Copy link
Collaborator Author

claireyung commented Sep 14, 2023

Not sure about zstar @pedrocol , I'll do that next.

And agreed @adele157 - even the 10^(-4)m/s with the 200m cliff-like front is acceptable. The issue is I was getting 10^(-3) (zstar) and 10^(-2) sigma/sigma_shelf in the 3D ISOMIP+ case. There aren't any 200m cliffs in ISOMIP+ (at least in the smoothed version I and I think most modelling groups use) so the question is still why 2D and 3D are different. Maybe the large amount of "small" cliffs in ISOMIP+?

I'm not sure what you mean by this being only due to the initialisation and not PGE. These runs all have the "fixed" salinity/thickness/temperature initialisation (though I'm not guaranteeing that the initialisation is perfect). The more steep cliffs have bigger velocities which I thought would be consistent with PGEs.

@adele-morrison
Copy link
Collaborator

The more steep cliffs have bigger velocities which I thought would be consistent with PGEs.

Agreed. I mean that even with steep gradients in layers, this case now has acceptably small PGEs. But the ISOMIP+ case has large PGEs, and I'm thinking (maybe incorrectly?) that that is because you can't fix the initialisation problem in the ISOMIP+ case, rather than the really large PGEs in ISOMIP+ arising from the sloping of the layers.

@claireyung
Copy link
Collaborator Author

I see. I'm not sure how PGEs scale from 2D->3D though.

I would clarify that it's not that I can't fix the initialisation problem in ISOMIP+, but rather that I can't say for certain that my hack works because I have no way of verifying it, since the layers are all curvy and not nicely shaped like a triangle. However, I do use the same hack in both cases (and it's been pretty robust to the change in ice front), so I'm not sure why it wouldn't work...

So it could still be that my hack doesn't fix ISOMIP+, or it could be PGEs are amplified in 3D, or both :/

Potential things to check to bridge this gap:

  • Pedro's upside down seamount with hack mode in sigma_shelf_zstar coordinates

  • Make my triangular ice shelf half a square pyramid? Then everything's still linear, so can check initialisation easily, but adds 3D angles to it.

  • everything in zstar coords...

@adele-morrison
Copy link
Collaborator

They sound like good tests.

If the problem is the initialisation, could we also use a really large viscosity to damp the initial velocities, then turn down the viscosity to something reasonable? Would that tell us if the problem is coming from the initialisation or amplified PGEs in the 3D case?

@claireyung
Copy link
Collaborator Author

More evidence that vanishing layers either at grounding line or elsewhere are an issue as Pedro mentioned in #1. This comparison of zstar with an ice front is much worse than the sigma_shelf_zstar config. (Without the ice front, just a triangle, velocities were 10^(-6)m/s) I am not sure why it's so much worse than the Gaussian seamount though.
image

There are probably a million different things to try... viscosity, min_thickness parameters, resolution etc. I believe @pedrocol has done some of this?

At some point a few months ago I tried masking out cells that were near the grounding line so I didn't have any vanishing layers. This helped a little but not that much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants