Omega Group Breakouts: 2023-06

Breakout #1 - Monday June 26 - 3:20 pm MDT

Breakout Room 2, Telluride

Session focus: Planning for model bias investigations

Purpose: Translate the initial OHC, AMOC, SSS ideas into clear plans for investigation (simulations, capabilities, analyses)

Agenda

Notes

Breakout #2 - Tuesday June 27 - 10:50 am MDT

Breakout Room 2, Telluride

Session focus: Ecosystem Project Discussion

Purpose: Engage ocean focused ecosystem projects to make them aware of OMEGA plans and timeline and hear about needs of ecosystem projects for the ocean model.

Agenda

What	Who	Notes

What	Who	Notes
OMEGA Plans and MPAS-O support straw man	Luke Van Roekel	Omega is a replacement for MPAS-O designed to be performant on new architectures Eddy resolving Omega will be released early 2026, with a LR model to follow later that year All E3SM project attention from the ocean team will be focused on this effort. There is not enough bandwidth to continue to integrate and support new features to MPAS-O. With v3.1, MPAS-O will be moved to ‘maintenance only’ (nothing but bug fixes). Proposed plan for new developments in the transition
Brief Presentations from ecosystem projects with focus on (4-5 minutes each) Ocean related plans any new features being developed for ocean (and timeline for delivery) missing features desired for project	Darren Engwirda (ICoM) Nicole Jeffery / Ethan Coon (InteRFACE) Matt Hoffman (SLR project) Wilbert Weijer / Milena Veniziani / Wieslaw Maslowski (HiLAT/RASM) Rob Hetland (COMPASS-GLM / Seahorce) Baylor Fox-Kemper / Manu di Lorenzo / Sam Stevenson (University)	Open ICoM:
Discussion	All	A few questions to consider for ESMD focused (and others) projects is there interest in a broad ESMD wide C++/YAKL hackathon (or series of them)? Any potential issues with timeline? Possibilities for collaboration amongst projects?

Notes

From Wilbert Weijer

• What happens if OMEGA is not complete in 3 years? Will there be a gap in user support?

From Sam Stevenson

• Lack of documentation makes use of MPAS-O / E3SM difficult

• Zstash causing most problems and lack of BGC in historical ensemble

• Worried most about gap in user support as well.

Notes from break-out #1

Notes were just rough, taken by @Mark Petersen

Notes 6/26/23 Ocean break-out 

Nicole: Are there other signals we can look at?

Rob: is E3SM AMOC more sensitive than other ocean models?

Mat: Definitely more sensitive than POP.

Luke: we may want to consider the two hemispheres separately

Mat: We could add a horizontal viscosity, especially in ACC, to diminish ocean heat up-take.

Some questions about dense water formation.

Dave: Is there a theoretical foundation for adjusting viscosity locally?

Luke: no. It would be better to do GM in a better way.

Andrew discussed some issues in the sea ice model, which were discussed in the sea ice session. Could turn frazzle into a mushy layer.

Luke: Southern ocean warming – formation of low clouds could alter conditions.

Wieslow – he found that in RASM, 3D restoring for spin-up was very helpful. Monthly varying, and 3D. U. of Washington has a 3D 20^th century data set for T,S.

Mark- we could run ocean stand-alone, to see if we can see the sensitivity of the AMOC to the ocean model numerics and internal variability- we could even use constant surface forcing.

Dave – we should not use constant surface forcing (without seasonality), that is too far from reality.

Mark – we could easily do that.

Auxie Hu (NCAR)– Then you can also adjust the surface forcing, like wind strength and surface forcing to see how sensitive AMOC is to that.

Carolyn – Made some comments on ocean heat uptake, it is off, particularly in particular locations.

Auxie Hu (NCAR)– Ghokan did a study on CESM – ocean is always loosing heat. When we change the coupling frequency, that changed the heat uptake.

Wieslaw – ocean heat content is increasing over 300 years of the EC60to30.

Dave – can you do some sort of run with all sorts of additional diagnostics?

Luke – that is what the list is about, fleshing out the heat transport.

Dave – you should be able to run high res and diagnose all your heat fluxes, and then compare your low res. to that.

Alice – if there are two different mean states, you can’t compare them.

Chris – it is hard to diagnose, because the model settles into a state which is completely self-consistent. But it is a biased state, so it is hard to track down what the problem is.

Carolyn – is the first few decades of spin-up useful for the diagnostics?

Chris – yes, it is helpful. You can see biases in the spin-up.

Wieslaw – We have two runs, that compare EC30to60 between low resolution atmosphere and high-resolution atmosphere.

Luke – we reran a high res. ocean with a 25km atmosphere, and it had an AMOC of 17-18Sv.

Dave – can you do supercycling on a high res, and advection on a standard grid?

Mat – I saw a talk on that by the UK Met office, and it takes a LOT of infrastructure.

Luke – we should start a standard res. atmosphere with a high res. (18to6) ocean. If we get a robust ocean, that would indicate that the ocean numerics are not fundamentally limiting.

Luke - In a G case 18to6 core, AMOC was at 18Sv. For low res. and 30to10, it and AMOC can still be very low.

Wieslaw – I ran a low-res G case and the AMOC fell below 8Sv.

June 27, 2023

Carolyn – should we have Polaris tests for all new ecosystem project features?

Luke – yes, would be good to include tests for all new features. We just want to be careful to not be responsible to fix things when they break.