Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Breakout Room 2, Telluride

Session focus: Planning for model bias investigations

...

Notes

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

Breakout Room 2, Telluride

Session focus: Ecosystem Project Discussion

...

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

  • A plan is needed for Ecosystem projects that rely on E3SMProposed 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)

  • Matt Hoffman (SLR project)

  • Baylor Fox-Kemper / Manu di Lorenzo / Sam Stevenson (University)

View file
nameInterface_model_developments.pptx

ICoM: https://docs.google.com/presentation/d/1eH9wtCDEx3p5PAUVsseSIReahf9FGdcDEq_hxalrbag/edit?usp=sharing

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 20th 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.