Coupler choices

[aekiss]

Purpose

To decide on a coupler to use for ACCESS-OM3. ACCESS-OM2 uses OASIS3-MCT, but this may not be the best choice for ACCESS-OM3. The chosen coupler should

• provide easy, robust, flexible, high-performance coupling of MOM6, CICE6, WW3, and a file-based atmosphere for ACCESS-OM3
• handle regional and global configurations, and tripolar C-grid
• permit adoption of ACCESS-OM3 into more complete coupled models, e.g. a future ACCESS-CM3 to be developed by ACCESS-NRI
• have high performance, scaling beyond 10,000 cores (both NUOPC and OASIS3-MCT can do this --CHECK DETAILS--)

and ideally have

• ability to replace any component with an alternative model, or a data-based stub (ideally without recompilation) - makes model more versatile, and easier to test. NUOPC can do this (Vertenstein, 2020) --WHAT ABOUT OASIS3-MCT ?--
• bitwise reproducibility, irrespective of processor layout (at least as an option for testing) - NUOPC can do this (Valcke et al., 2012), as can OASIS3-MCT v5.0 (Valcke et al., 2021 sec 4.3)
• low fixed overhead (e.g. initialization, finalization) to support short, high-resolution runs in DA applications

[aekiss]

Valcke et al., 2012 provide an overview of coupling technologies and issues (pre-dates NUOPC, but mentions it in discussion of ESMF; also discusses old serial OASIS3, only briefly mentioning parallel OASIS3-MCT).
Earth System Modelling - Volume 3 also looks relevant, although similarly dated.

[aekiss]

These couplers are already supported in the model components to be used for ACCESS-OM3 and probable ACCESS-CM3:

• MOM6: NUOPC, MCT, FMS
• CICE6: NUOPC (CMEPS, DMI), MCT (CESM1)
• WW3: NUOPC, OASIS3-MCT
• UM (which I gather includes CABLE): OASIS3-MCT (what version?)
• LFRic: OASIS3-MCT (what version?); no plans to make it compatible with NUOPC

From this it seems that the main contenders are OASIS3-MCT and NUOPC (more specifically, probably CMEPS).

[MartinDix]

CMIP6 version of UM used OASIS3-MCT 3.0. Current versions of UM use OASIS3-MCT 4.0. Not sure about LFRic.

CABLE is called directly as part of the UM land surface scheme and doesn't go via a coupler. This is different to CESM for example where the land is connected with a coupler.

[aekiss]

Background: our current model architectures all use OASIS3-MCT

• ACCESS-OM2 uses OASIS3-MCT v2.0 (with assistance of libaccessom2) to couple MOM5, CICE5 and YATM:
  
  

• The BoM Sea-ice Forecast Demonstrator uses ACCESS-OM2 (coupled with OASIS3-MCT v2.0 and libaccessom2), including YATM (but forced by ACCESS-G)

• ACCESS-CM2 uses OASIS3-MCT v2.0 to couple ACCESS-OM2 CICE5 and MOM5 configurations (but not libaccessom2 or YATM) to UM and CABLE.

• ACCESS-ESM1.5 uses OASIS3-MCT v2.0 to couple CICE4 and MOM5+WOMBAT (not ACCESS-OM2 configurations, or libaccessom2) to UM and CABLE+CASA-CNP. Fig from Ziehn et al 2020:
  

[MartinDix]

CM2 and ESM1.5 also use OASIS3-MCT v2.0

[aekiss]

ta, I've fixed that

[aekiss]

OASIS3-MCT

Documentation: https://oasis.cerfacs.fr/en/documentation/

• OASIS-coupled models usually consist of multiple executables linked via a common library (but OASIS3-MCT v3.0 and later can also couple components within a single executable - see Craig et al 2017, Valcke et al., 2021 sec 2.1 and Theurich et al, 2016)
• Implemented as a library to be included in each model component; in ACCESS-OM2 this is achieved by including OASIS3-MCT v2.0 in libaccessom2, which is in turn included as a library in YATM, CICE5 and MOM5.
• Current OASIS3-MCT version is 5.0, but a COSIMA-customised fork of v2.0 is used in ACCESS-OM2 via libaccessom2; version changes are documented here. ACCESS-CM2 and ACCESS-ESM1.5 also use OASIS3-MCT v2.0.
• Uses MCT (Model Coupling Toolkit) internally for parallel coupling (Larson et al., 2005, Jacob et al., 2005). MCT was used in NCAR CESM (Community Earth System Model), but they've now switched to CMEPS, based on NUOPC.
• Scales competitively with other couplers up to O(10,000) cores --CHECK-- see Craig et al 2017
• Mainly used in Europe: https://oasis.cerfacs.fr/en/results-of-the-survey-2019-on-oasis3-mct-coupled-models/
• Works with Met Office Unified Model and WW3
• Would need driver code to work with MOM6 and CICE6 - can our existing MOM5 and CICE5 OASIS3-MCT v2.0 drivers be easily ported?
• doesn't support exchange grids as far as I know

[aekiss]

NUOPC

• Part of ESMF (Earth System Modeling Framework)
• Features overview: https://earthsystemmodeling.org/nuopc/ and Theurich et al, 2016
• Documentation: https://earthsystemmodeling.org/doc/
• strong commitment from many US institutions (Navy, NOAA, NASA and now CESM), with well-resourced development
• underpins many US modelling efforts, e.g. https://www.icams-portal.gov/resources/espc/esps/table.htm (a bit out of date?)
• used in NEMS (NOAA Environmental Modelling System), which underpins the Unified Forecast System (UFS)
• used in CMEPS (Community Mediator for Earth Prediction Systems), built colaboratively by NCAR, NOAA/EMC and NOAA/GFDL, used as the coupler in NCAR’s Community Earth System Model (CESM - in the forthcoming CESM3 and possibly CESM2.3, coupling MOM6, CICE6, WW3, etc), also used by NOAA/EMC to couple FV3-ATM with MOM6, CICE6 and WW3
• NUOPC defines 4 basic component types: drivers, connectors, mediators and models.
• Each model component needs a NUOPC wrapper (called a cap) to translate native data structures (grids, field data, etc) to ESMF data structures, and provide standard interfaces to model execution subroutines (init, run, finalize)
• NUOPC caps are already available for MOM6, CICE6, WW3 and several groups are working on coupling all three - which covers what we're aiming for with ACCESS-OM3
• MOM6 uses a C-grid, so it would be ideal to also use a C-grid in CICE6, but this has only just been implemented (first released in CICE6.4.0). NCAR (CESM2) and NOAA/EMC are working towards MOM6-CICE6 coupling (including with a C-grid) using CMEPS (which is built on NUOPC). The MOM6 and CICE6 caps both need updating to enable direct coupling of the C-grid velocities without averaging them to cell centres. NCAR and NOAA are fully committed to NUOPC so it is just a matter of time before these remaining coupling issues are resolved.
• NUOPC standardizes the build process, using GNU makefile fragments that build each component into a NUOPC-capped library (Theurich et al, 2016)
• ESMF/NUOPC applications are typically compiled into a single executable (but ESMF also supports running separate components as multiple executables (Valcke et al., 2012); not sure if that also applies with NUOPC) with a single top-level driver that controls component models via caps (and possibly mediators) through connectors that are automatically generated by the driver (no hard-coded field mappings).
• run sequence specified by user-friendly text file, so can be changed without recompilation
• model components switched on/off at runtime or replaced with prescribed data (no recompilation) - useful for development and testing (isolating problems, disabling feedback, faster execution, etc), as well as customised configurations for particular research needs - see Vertenstein, 2020
• executable could also contain multiple models of same type (e.g. ocean models), switchable at runtime
• runtime debugging tools: NUOPC Compliance Checker and Component Explorer
• supports exchange grids (Balaji et al., 2006) for conservative exchange between mismatched grids; NCAR is considering using this feature. However, this Comparison of the GFDL and ESMF Exchange Grids shows GFDL's exchange grid implementation (presumably in FMS) is much faster and more accurate than ESMF's - not sure if that's still the case [edit: ESMF exchange grids are now faster and more accurate - see Daniel Rosen's CW2023 talk]. Bauer et al., 2021 describe an application of coupling via NUOPC exchange grids.
• ESMF performance overhead for CESM is under 5% without significant optimization (Theurich et al, 2016)
• not supported in Met Office Unified Model or LFRic, and they have no plans to support it.
• presumably ditto for CABLE, JULES?

Theurich et al, 2016: 4 basic component types:

Very flexible; can be be used in many different ways, such as these (and many more):

[aekiss]

Some useful links:

• Fifth Workshop on Coupling Technologies for Earth System Models (CW2020) (and videos), particularly
  • Valcke et al. (with video) on OASIS3-MCT, and
  • Dunlap et al., 2020b (with video) and Vertenstein, 2020 (with video) on NUOPC
• UFS: 2020 UFS Users Workshop, particularly Dunlap et al., 2020
• CMEPS: Worthen et al., 2020 at 2020 UFS Users Workshop
• NEMS: DeLuca 2015a, DeLuca 2015b; spreadsheet of applications; NEMS User's Guide; training slides and more
• apparently abandoned tools for NUOPC: NEMS AppBuilder and Cupid IDE and https://cupid.readthedocs.io/en/latest/index.html

Also see post below on Sixth Workshop on Coupling Technologies for Earth System Models.

[aekiss]

Summary

In summary, MOM6, CICE6, WW3 are close to coupling "out of the box" with NUOPC, whereas UM, LFRic and WW3 can couple with OASIS3-MCT, so we have a foot in each canoe trying to couple US-based (MOM6, CICE6, WW3) and Met Office (UM, LFRic) models.

For ACCESS-OM3 it seems far easier to use NUOPC, as several experienced and well-resourced groups are already using it to couple MOM6-CICE6-WW3 and we could benefit from their work, debugging etc., and it also offers nice features like changing/disabling model components without recompilation. The flexibility of NUOPC could be a significant advantage for research users of ACCESS-OM3.

UM/LFRic is outside the scope of the COSIMA Linkage grant, but within the remit of ACCESS-NRI, which will also be far better resourced than COSIMA to take on the software engineering task of coupling UM/LFRic to the other model components in a future ACCESS-CM3.

I can think of several possible ways forward:

1. All-OASIS: ACCESS-OM3 and ACCESS-CM3 would both use OASIS3-MCT. ACCESS-OM3 development would probably be slower than with NUOPC, as it would require software engineering support from ACCESS-NRI to develop and maintain OASIS3-MCT coupling code for MOM6 and CICE6, hopefully porting our existing MOM5 and CICE5 OASIS3-MCT v2.0 drivers. We could expect little support/interest from the international community. ACCESS-OM3 could probably continue to use libaccessom2 and YATM.
2. NUOPC OM3, OASIS CM3: ACCESS-OM3 would use NUOPC, but ACCESS-CM3 would use OASIS3-MCT (including for MOM6-CICE6-WW3). COSIMA would develop ACCESS-OM3 using NUOPC, leveraging US efforts to couple MOM6-CICE6-WW3 with NUOPC and leaving the task of coupling MOM6-CICE6-WW3-UM with OASIS3-MCT to ACCESS-NRI at a later date. This would accelerate development of ACCESS-OM3 which could then be used as a reference for ACCESS-NRI's development and testing of OASIS3-MCT coupling code for these model components. It would also provide local experience with NUOPC, which would help the Australian community take advantage of new US developments.
3. Mixed NUOPC-OASIS: ACCESS-OM3 would use NUOPC, and ACCESS-CM3 would use NUOPC for the ACCESS-OM3 components and OASIS3-MCT for everything else. Use ESMF/NUOPC to combine MOM6, CICE6, WW3 into one executable (ACCESS-OM3), and then couple this combined executable to UM/LFRic using OASIS3-MCT. Valcke et al., 2012 say ESMF component wrappers may be layered on top of other coupling technologies (e.g. MCT, FMS), but can a NUPOC executable be coupled to something else via OASIS3-MCT? NUOPC models can be nested and driven by external code, e.g. panel c in fig above. Perhaps the ACCESS-OM3 code could be wrapped in code that drives the ACCESS-OM3 NUOPC model and interacts with UM/LFric via OASIS3-MCT calls? Could be a neat solution if it's possible, requiring "only" the development of the ACCESS-OM3 OASIS3-MCT wrapper code, a software engineering task well-suited to ACCESS-NRI. NUOPC might make it easy to switch between the ACCESS-OM3 data-driven atmosphere and the ACCESS-CM3 interactive atmosphere.
4. All-NUOPC: ACCESS-OM3 and ACCESS-CM3 both use NUOPC. ACCESS-OM3 development would be faster, but ACCESS-NRI may find it difficult to couple to the UM and LFRic with NUOPC, especially as these are proprietary codes and there seems to be no interest in NUOPC from the UKMO.

ACCESS-CM3 will probably be developed years after ACCESS-OM3. If ACCESS-OM3 uses NUOPC we will have options 2, 3 and 4 open to us, and can defer the decision between these until we are ready to design ACCESS-CM3 (by which stage there may be more options available due to ongoing international development, and more capacity at ACCESS-NRI to support the required development). We would probably need to abandon or heavily rewrite libaccessom2 if we use NUOPC and it may become redundant. We would then need to decide on a file-based atmosphere and runoff code for ACCESS-OM3, e.g. adapt YATM or use a NUOPC-compatible data atmosphere, e.g. DATM from CDEPS.

On the basis of what I've learned so far I'm in favour of moving to NUOPC for ACCESS-OM3, with the hope that option 3 will be feasible when we come to designing ACCESS-CM3 (failing that, we could try option 2 or as a last resort 4).

[micaeljtoliveira]

@aekiss Thanks for the nice summary!

On the basis of what I've learned so far I'm in favour of moving to NUOPC for ACCESS-OM3, with the hope that option 3 will be feasible when we come to designing ACCESS-CM3 (failing that, we could try option 2 or as a last resort 4).

I fully agree with this.

[dpath2o]

FWIW, I fully agree too.

[aekiss]

Thanks. My main uncertainty is how much effort it would take to port our existing OASIS drivers to MOM6 and CICE6 - if that's relatively easy, then option 1 could be reasonable.

However, I really like the opportunities presented by the modular "plug and play" design of NUOPC, which would make it easier to create and support various configurations driven by a data atmosphere, for both development and research:

• individual standalone MOM6, CICE6, WW3 configurations, with the other components omitted or replaced by data
• 2-model coupled configurations (MOM6-CICE6, MOM6-WW3, CICE6-WW3), with the other components omitted or replaced by data
• 3-model coupled MOM6-CICE6-WW3, with a data atmosphere

as well as the many useful permutations with a dynamic atmospheric model (e.g. UM or a simple atmospheric boundary layer model), with/without any/all of MOM6, CICE6, WW3.

[ofa001]

@aekiss Nice summary, I don't disagree with leveraging the work done in the US on NUOPC on coupling MOM6-CICE6-WW3 for COSIMA2.

One comment the version of CICE6 we will need to couple to the UM will need to pick up some of the code from CICE5 that we allowed us to coupled the Bl99 thermodynamics to the UM that's not part of the CICE6 release we could merge it in as an option into the system or have a totally separate code base it wouldn't be as an executable of the 3 codes that you could just couple together. Last time in our ACCESS-CM2 set up we also used CICE as an intermediate medium between the ocean and the atmosphere I haven't seen it used this way in the NUOPC diagrams but I haven't read all of them yet, not sure if we do that again.

[ofa001]

@aekiss One other comment of clarification of the above on the UM coupling. The way the NCAR CESM2 is set up is so that every model component can be replaced by a data model. The UM coupling works differently, The surface and boundary scheme calculates the surface temperature and some of the surface properties of each surface land/ocean/ice in its code including albedo. So its no as easily exchanged with a data model, and why we have to make code changes in CICE6.

[aekiss]

Thanks @ofa001, good point - I hadn't been aware of the reasons for that code in CICE5.
If we went with option 3 above I guess the extra code that's currently in CICE5 could instead be put into the OASIS3-MCT interface layer on top of a NUOPC-based ACCESS-OM3?

[ofa001]

HI @aekiss no it they belong in go in the CICE6 code its part of the ice thermodynamics, we could set it up as options and flags and have different subroutines in the code with similar names like icepack_therm_xxx_mo for the met_office related versions and a different driver as we already have a different driver set of code for the coupled model v stand alone one these parallel subroutine may have extra/different variable that are passed and they are some extra functions calculations that are undertaken. They will be similar ones for the intermediate steps as well passing code to it. Ed Blockley did have a comment on the CICE6 github saying how far the codes had diverged but I guess some of those differences were down to icepack and the reorganization for CICE6 and history files taking different approaches.

[aekiss]

Hm, OK - lots of intricacies there and further investigation needed. I guess the atmospheric models used with NUOPC calculate fluxes very differently from the UM.

[ofa001]

@aekiss Still trying to get my head around a mixture of OASIS and NUOPC together and see if I think its viable, I have found the CICE6 nuopc driver, and the MOM6 nuopc cap, I will see if I can find the ones CICE6 nuopc cap and WW3 nuopc cap and see if the contain all the things I am expecting there.

[ofa001]

@ aekiss just thinking of a few other issues a well as all the many differences in the driver code for CICE which was in between the atmosphere and ocean coupling last time, lots of extra variables being passed back and forth, there was also the time stepping, the atmospheric data model had explicit coupling while the UM had a mixture implicit and semi-implicit depending which surface it was coupling too. So I am beginning to worry if one executable like in option3 will handle it all even if we have lots of flags controlled by namelist variables that can send it down different code paths. I should look at the other options.

[aekiss]

NUOPC seems very flexible with coupling time stepping and supports lots of different explicit and implicit approaches, e.g. https://earthsystemmodeling.org/nuopc/#prototype-applications so maybe that would cover it?

[ofa001]

Hi @aekiss yes I saw that page several weeks ago, one of the ppts you pointed too though had some additional info I am following up now which may just be for the NCAR set up it viewed the NUOPC caps for individual model links and mediator as fixed once they had built the set up to the data models and then active components, which still make 3 and 4 a bit inflexible. We might need to build separate set ups for ACCESS-CM3 and ACCESS-OM3 with NUOPC but different settings in caps and mediators

[ofa001]

Hi @aekiss yes looking at NOAA pages they plan to have different NUOPC caps for different applications so a bit more flexible than NCAR so I think we can build it a bit more flexible as well we don't have to be identical in the ACCESS-OM3 and ACCESS-CM3 set ups which is how NCAR seem to see everything which is more plug and play with the data models and the rest of the system locked in.

[ofa001]

@aekiss one other issue is that we couple in individual ice categories in UM -ACCESS-CM2, in ACCESS1-0/3 we did it across grid box mean. Not sure how we handle this with the NUOPC system this may make option3 more difficult and possibly option 4 until we understand how NUOPC caps work.

[DaveBi]

@aekiss Thanks for the very objective summary!
While I am open to all the options, especially options 1-3, I feel like to make some specific comments on option 1, which has been in my mind since I started thinking about building ACCESS-CM3. To me, having all the component models working/communicating under a single coupling framework is much more appealing than combining different software engineering work to form an even more complicated coupled system.
I fully understand the benefit of using NUOPC for ACCESS-OM3 at CISIMA and would be very happy to see such a model available for the community. However, I would feel more excited to see the oasis3-mct version of ACCESS-OM3 built at COSIMA, not just for the convenience of using it in ACCESS-CM3, but for its "unique" feature (that is different to the NUOPC approach taken by other groups). This is somewhat similar to the situation of ACCESS CM using MOM, not NEMO -- we all know that if we went for NEMO, a very straightforward, resource/effort-saving approach, there would be no need for the COSIMA-ACCESS collaboration at all.
Regarding the timeline for ACCESS-CM3 development, I don't think it should be put a few years behind ACCESS-OM3. If we want to (or say, are luckily endorsed to) deliver ACCESS-CM3 or ESM3 to CMIP7, we need to have it technically ready as soon as possible (I would say no later than 2024/25), We need take into account the very time-consuming tuning and debugging process.
Indeed, taking the OASIS-MCT approach for CICE6-MOM6-WW3 coupling may cost some extra effort at COSIMA, but I don't think it is really a big hurdle unless we try and find so. My own experience with ACCESS-OM (i.e., AusCOM) tells me that, with some necessary help/advice from IT experts, this challenging technical work could even be done by a person who was very amateur in terms of IT and understood very little about MPI (which is the core of OASIS code). We now have much better resource than we had 15 years ago, and more importantly, we can have ACCESS-NRI IT expert(s) work on this as high propriety.
Yes, technically I feel pretty positive about option 1, and I have no opposition against other approaches.
ACCESS-NRI colleagues/experts may surprise everybody by providing different versions of the model for us to choose😊

[DaveBi]

For everyone's interest --
6th Workshop on Coupling Technologies for Earth System Models: January 18-20, save the date !
Dear colleagues,

Following the workshops in Toulouse (2010) Boulder (2013), Manchester (2013), Princeton (2017) and the last virtual one (2020), we are planning to hold the 6th Workshop on Coupling Technologies for Earth System Models in Toulouse, France Jan 18-20, 2023. Remote participation will be possible.

A formal announcement and registration site will follow soon. Please mark your calendars.

Sincerely,
The CW2023 Program Committee

---

Sophie Valcke
Research Engineer
Climate Modelling and Global Change team
CECI UMR 5318 CNRS/CERFACS
42 Av. G. Coriolis
31057 Toulouse Cedex 01, FRANCE

[ofa001]

I back @DaveBi timeline that ACCESS-CM3/ESM3 should not be seen far off in the future, I was a bit worried about timeline mentioned in @aekiss 'document', We have been holding off on detailed planning here internally waiting for ACCESS-NRI to get fully underway, which does now have projects to build the higher resolution coupled models with the upgraded UM 12.2 into them, but planning for the upgrade to coupling in CICE6 and MOM6 could be in parallel with ACCESS-OM3.
Option 1 and 2) should not be removed from consideration in the discussion, there is an always an element of upgrading incrementally rather than radically, though leveraging work already done in the US has is attractions for the ACCESS-OM3 set up.

[aekiss]

Thanks @DaveBi, glad to know that option 1 doesn't seem infeasibly daunting to you. We'd need to bear in mind that getting high performance with high-core-count high-resolution global ACCESS-OM3 would require additional effort beyond what is needed for lower-resolution configurations suitable for CMIP7.

I see your point re. having one coupler for all components (rather than a hybrid approach like option 3), but I also think what matters for ACCESS-OM3 is the scope of research it enables, so if NUOPC can provide at least as many options for research as OASIS3-MCT, I don't think we should use OASIS just to be different. This doesn't seem equivalent to choosing between MOM and NEMO, which have different science capabilities.

Also please don't take my guessed timeline to ACCESS-CM3/ESM3 seriously - this was pure uninformed speculation on my part.

[MartinDix]

On the basis of what I've learned so far I'm in favour of moving to NUOPC for ACCESS-OM3, with the hope that option 3 will be feasible when we come to designing ACCESS-CM3 (failing that, we could try option 2 or as a last resort 4).

This recommendation looks reasonable to me.

Option 4 is not necessarily a last resort. I think it's worth trying to scope what a NUOPC cap for the UM would look like. If it's a new wrapper around some minimally modified existing top level routines (e.g. replacing um_shell and u_model but keeping atm_step and everything below) it might not be too hard to maintain it ourselves even if the Met Office aren't interested. A comparison of the MOM NUOPC cap c.f. the OASIS interface would be a start.

If this is feasible, some intermediate steps before CM3 could be

1. UM AMIP configuration with NUOPC driver, no coupling
2. UM AMIP configuration with SST and ice as a separate data model

[aekiss]

Thanks @MartinDix, it will be interesting to see whether option 4 would be feasible.

[aekiss]

A comment from Ben Galton-Fenzi:

We routinely use ESMF and it is the coupler we use for our ice-sheet/ocean modelling. This approach would be easy to adopt for MOM6 I think and conversations I’ve had with Bob Hallberg have been positive as to relative ease of approach.

Here is a link describing our Framework For Ice Sheet–Ocean Coupling (FISOC) V1.1 built using ESMF https://gmd.copernicus.org/articles/14/889/2021/

The start of the methods section contains some discussion about the merits of ESMF and why it was chosen. We did look at other couplers but none have as much flexibility and relative ease of approach as ESMF, which I think should be easier with NUOPC included.

[aekiss]

For reference, here's the plan for building ACCESS-OM3 we had in the Linkage proposal. Some steps involve standalone (e.g. steps 1, 2, 4) or coupling a subset of MOM6, CICE6, WW3 (e.g. step 5).

[aekiss]

Alexander & Easterbrook 2015 provide an interesting overview of climate model architectures, contrasting the "star" approach often taken in the US (everything goes through the coupler) and the European "two-sided" approach, e.g.

[MartinDix]

UM ticket with NUOPC feasibility test https://code.metoffice.gov.uk/trac/um/ticket/6904 (need a MOSRS account to see it)

[MartinDix]

Here's my presentation from the COSIMA TWG
UM_NUOPC.pptx

[DaveBi]

@MartinDix Great start! Very encouraging.

[aekiss]

Thanks @MartinDix, great to see that it seems feasible to drive the UM with NUOPC.

Does it also look straightforward to couple the UM to the other model components via NUOPC/CMEPS, or is that a potential roadblock?

[aekiss]

Slides and videos from the Sixth Workshop on Coupling Technologies for Earth System Models (CW2023) are here. Talks relevant to NUOPC include:

• Mariana Vertenstein on CMEPS, CDEPS and exchange grids: slides and video
• Daniel Rosen on ESMF, the ESMX executable and NUOPC driver, and exchange grids: slides and video
• Ufuk Turuncoglu on exchange grids in UFS with CMEPS: slides and video

There are also several talks on OASIS.

[aekiss]

Interestingly, NOAA are considering moving away from API-based "loose" coupling (e.g. NUOPC) towards "close" (integrated code) coupling to get greater control of load balancing, timestepping and numerical stability - see Tolman's talk and slides from the 5th workshop on waves and wave-coupled processes.

[anton-seaice]

I think NUOPC can be used in more closely integrated coupling than how CMEPS uses it but I don't understand the details!

[micaeljtoliveira]

@aekiss Thanks for sharing the link to the talk, quite interesting!

I fully understand the need for "close" coupling regarding fine-grained control of stepping, stepping algorithms and parallelisation, but I'm quite sure that can be done with an API-based coupling, as that's precisely what I did in Octopus 😉