pedrocol / MOM6_pge_tests

1 stars 0 forks source link

Impact of non-Boussinesq implementation #1

Open adele-morrison opened 12 months ago

adele-morrison commented 12 months ago

Test across a range of different ice shelf configs with ALE coordinates. Need to make sure we have Bob's most up to date code (I think he said he hadn't merged all the relevant changes yet?).

claireyung commented 11 months ago

Perhaps https://github.com/Hallberg-NOAA/MOM6/tree/nonBoussinesq_dev ?

pedrocol commented 11 months ago

A first test was performed using the last version of MOM6_examples. The configuration is a double seamount in order to be able to compare the spurious velocities generated at the bottom and at the ice-shelf

First run as a seamount only salinity_seamount

And then run as an ice-shelf with the same seamount shape salinity_shelf_seamount

Both cases have constant temperature, linear Salinity and linear equation of state. The density calculated with the linear equation of state is not dependent on pressure, so there isn't a non-linearity from pressure.

The Boussinesq and Non-Boussinesq formulations of the pressure gradient scheme are implemented for each case, and run for 1 month. Giving the following maximum velocities in the domain time-series

timeseries

Both formulations seem to work similarly in the seamount test case. But the Boussinesq formulation produce spurious velocities that grow in time for the ice-shef case. On the contrary, the Non-Boussinesq formulation produce similar max. spurious velocities with an asymptotic behaviour in time for the ice-shelf case.

If we take a closer look to a transect in the middle of the domain at the last time step, we can see in both cases that the spurious velocities are related with the vanishing layers.

In the seamount case there might be a reflection of the internal waves generated at the base, and this might explain why the max. spurious velocites are a bit larger than the ice-shelf case. Also the pressure values at the base of the seamount are larger than in the ice-shelf case, and therefore a pressure difference may lead to larger values

vel_seamount

Some odd strange vertical lines are also present in the ice-shelf case.

vel_shelf_seamount

adele-morrison commented 11 months ago

Have we tried ISOMIP+ with non-Boussinesq?

claireyung commented 11 months ago

ISOMIP+ with non-Boussinesq:

See this notebook. I tried the MOM6-examples/ocean-only/ISOMIP/layer config with corresponding MOM_override's to change to the ALE coordinates and use non-Boussinesq functionality (note I used Bob's branch)

Perhaps https://github.com/Hallberg-NOAA/MOM6/tree/nonBoussinesq_dev ?

Note that this branch does not yet have the hack mode for salt initialization bug fix.

The velocities are similar to the original Boussinesq case, unlike Pedro's version which also lacks the salinity initialization bug fix but shows improvement with non-Boussinesq usage.

image
claireyung commented 11 months ago

I also tried adding some ISOMIP+ standard protocol viscosity and it decreased the velocities a little but didn't make much difference to the Bouss vs non-Bouss comparison (if anything, made the non-Bouss version worse, see figure below).

Note that the ISOMIP+ geometry doesn't have a super steep ice front - it has already been smoothed from the original Asay-Davis protocol by folks at GFDL.

Next step: put hack mode in the new non-Bouss MOM6 branch to fix salinity/temp initialization. The executable if you want it @pedrocol for your seamount is /scratch/x77/cy8964/mom6/MOM6-nonbousshackmode

Unfortunately hackmode + non-bouss caused the model to crash. Error logs: https://github.com/pedrocol/MOM6_pge_tests/blob/main/Confs/ISOMIP/zstar-nonbouss-hackmode/mom6.err

So only showing hackmode+bouss (which makes it worse???) image

In summary, none of our hat tricks worked for ISOMIP (yet) - smoothing the ice front (it's already smoothed), using hackmode to fix the initialization, or using non-Boussinesq.

adele-morrison commented 11 months ago

Confusing? But I guess there are other parameter differences between the ISOMIP and seamount ice shelf cases? Maybe is it worth running the ISOMIP case with the exact parameters used in the seamount ice shelf case above to narrow down if it's due to the cavity geometry?

pedrocol commented 11 months ago

@claireyung could you plot a transect in the very first time steps to see where the spurious currents are coming from?

claireyung commented 11 months ago

Yes agreed Adele. @pedrocol can you do this please? You should be able to find the geometries from the initial conditions files in my output.

pedrocol commented 11 months ago

I did the same test in the ISOMIP+ and I got large spurious velocities in both Boussinesq and Non-Boussinesq, but I think this is related with another issue isomipp_time

The spurious velocities seem to be coming from the part of the domain where the ice-shelf and the bathymetry meet.

section-3

In this problem I didn't set a minimum distance between the ice-shelf and the bathy, so we should expect large spurious velocities due to the abrupt change in the vertical coordinate. But I think this should be treated as a different issue, in the same way the shelf front represents another issue.

claireyung commented 11 months ago

Next step: put hack mode in the new non-Bouss MOM6 branch to fix salinity/temp initialization. The executable if you want it @pedrocol for your seamount is /scratch/x77/cy8964/mom6/mom6-ninja-nci/ocean_only_symmetric/MOM6

Just noting I moved the executable to /scratch/x77/cy8964/mom6/MOM6-nonbousshackmode

claireyung commented 11 months ago

@claireyung could you plot a transect in the very first time steps to see where the spurious currents are coming from?

This is at t=300s

image image
adele-morrison commented 10 months ago

The time series of the ISOMIP case in zstar above are quite different for the plot by Claire (starts large, but flat time series) and for the plot by Pedro (starts small, but increasing time series).

Are these very different configs? Do we understand why these are different?

claireyung commented 10 months ago

The time series of the ISOMIP case in zstar above are quite different for the plot by Claire (starts large, but flat time series) and for the plot by Pedro (starts small, but increasing time series).

Are these very different configs? Do we understand why these are different?

There are a few differences, comparing the MOM_parameter_doc.all of Pedro's non-bouss shelf run(zco/archive/GPC004/output000/MOM_parameter_doc.all on gadi, I think) and mine

Main ones of note to my eyes are different MIN_THICKNESS (Pedro's is 0.001, mine 1E-12) (and the use of TRIM_IC_FOR_P_SURF (False for Pedro, True for me) and KH being bigger (1000 vs 6) in Pedro's. I've previously found that all of these parameters are important for the magnitude of the currents, so that makes sense.

adele-morrison commented 10 months ago

Ok, that's good that the difference can be explained. Do we know which choice of these parameters is better? If your choices are justifiable Claire, then perhaps we should use them for @pedrocol's next tests with increasing the grounding line thickness in ISOMIP, because the trend of the spurious velocities looks better?

claireyung commented 10 months ago

I think the best combination (from the POV of the magnitude of spurious currents, not sure about realisticness) is Pedro's higher viscosity KH = 1000 and my TRIM_IC_FOR_P_SURF = True, MIN_THICKNESS = 1E-12.

Reasons for the latter two are these tests (admittedly in Boussinesq mode though) that I posted about https://bb.cgd.ucar.edu/cesm/threads/spurious-velocities-in-mom6-ice-shelf-cavities.8160/

Screenshot 2023-10-18 at 12 24 14 pm

Ignoring the effect of viscosity, Pedro's is like the purple dashed line and mine is the orange one.

claireyung commented 10 months ago

I think the best combination (from the POV of the magnitude of spurious currents, not sure about realisticness) is Pedro's higher viscosity KH = 1000 and my TRIM_IC_FOR_P_SURF = True, MIN_THICKNESS = 1E-12.

Reasons for the latter two are these tests (admittedly in Boussinesq mode though) that I posted about https://bb.cgd.ucar.edu/cesm/threads/spurious-velocities-in-mom6-ice-shelf-cavities.8160/ Screenshot 2023-10-18 at 12 24 14 pm

Ignoring the effect of viscosity, Pedro's is like the purple dashed line and mine is the orange one.

That said, small MIN_THICKNESS can also have problems at the grounding line (issue https://github.com/pedrocol/MOM6_pge_tests/issues/7). So, maybe it's not clear what we should be using.

adele-morrison commented 10 months ago

Perhaps for now we could try the impact of increased grounding line thickness on a couple of different ISOMIP configs (e.g. the two above).

Maybe it would be useful to have a doc we can edit on this repo where we can keep notes of the impact of changing these different parameters on the spurious velocities?

On Wed, 18 Oct 2023 at 12:56, claireyung @.***> wrote:

I think the best combination (from the POV of the magnitude of spurious currents, not sure about realisticness) is Pedro's higher viscosity KH = 1000 and my TRIM_IC_FOR_P_SURF = True, MIN_THICKNESS = 1E-12.

Reasons for the latter two are these tests (admittedly in Boussinesq mode though) that I posted about https://bb.cgd.ucar.edu/cesm/threads/spurious-velocities-in-mom6-ice-shelf-cavities.8160/ [image: Screenshot 2023-10-18 at 12 24 14 pm] https://user-images.githubusercontent.com/61528379/276047444-95535c4a-9c47-4545-9f70-c5efdba4498c.png

Ignoring the effect of viscosity, Pedro's is like the purple dashed line and mine is the orange one.

That said, small MIN_THICKNESS can also have problems at the grounding line (issue #7 https://github.com/pedrocol/MOM6_pge_tests/issues/7). So, maybe it's not clear what we should be using.

— Reply to this email directly, view it on GitHub https://github.com/pedrocol/MOM6_pge_tests/issues/1#issuecomment-1767486009, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA44U4N6J32HRZI6WYTJG3X74ZMXAVCNFSM6AAAAAA4VRYTOSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRXGQ4DMMBQHE . You are receiving this because you authored the thread.Message ID: @.***>