<p>Coupler software (e.g. <a href="https://verc.enes.org/oasis">OASIS</a>, <a href="http://www.mcs.anl.gov/research/projects/mct/">MCT</a>, <a href="http://www.geosci-model-dev-discuss.net/7/3889/2014/gmdd-7-3889-2014.html">C-Coupler</a>) is frequently used to combine these different components of earth system models. Of course interfacing models with each other using these couplers or other methods always needs some technical work and sometimes also some algorithmic work. Therefore the number of model combinations will always be limited.</p>

CC BY-SA 3.0
2014-09-02T12:56:00.203Z
Interesting. OASIS looks like it's been around for more than 20 years, but it doesn't look like it's had much uptake - mostly French orgs. MCT seems newer, but also only has a small list of models that it currently works with. Do you have any experience working with any of these?
naught101
CC BY-SA 3.0
2014-09-02T13:13:03.143Z
There is a lot of OASIS usage in Europe.
BHF
CC BY-SA 3.0
2014-09-02T13:13:25.587Z
I used OASIS3 to create a coupled atmosphere, sea ice, ocean model.
BHF
CC BY-SA 3.0
2014-09-02T13:43:39.063Z
Re: '... will always be limited.' - It does seem like a bit of an uphill struggle, but it would be nice to see a standard emerge from those projects, so that other component models could at least attempt to be compatible with more combinations of other models.
naught101
CC BY-SA 3.0
2014-09-02T12:27:46.087Z
2014-09-02T13:19:28.153Z
2014-09-02T13:19:28.153Z
BHF
<p>Yes, there were many model coupling projects in the past, as well as many ongoing coupling projects in the present and near future.</p>

<p>The main motivation behind model coupling is the need for the interactive feedback processes between two or more separate physical systems, for example, atmosphere and ocean. Historically, these models have been developed independently of each other, i.e. they were uncoupled - unaware of each other. Given past and current technology and knowledge, modifying the models' source code so that they can exchange information in a consistent manner was a much smaller effort (typically few years) than it would take to develop a unified system model from scratch (i.e. atmosphere-ocean as a single dynamical core). Another advantage to the coupling approach is that different physical systems often describe processes that operate on very different spatial and time scales. Thus, it is often computationally advantageous to let physical systems have distinct models that are "coupled" through an intermediate layer.</p>

<p>The vast number of coupling projects throughout the 1990s and 2000s have demonstrated the need for more standardized coupling libraries or frameworks that would cut down on duplication of effort, software bugs and development time. @BHF's answer mentions a few of those. Probably the most mature and feature-rich framework at this point is the <a href="http://earthsystemmodeling.org">Earth System Modeling Framework (ESMF)</a>. ESMF provides data abstraction for geophysical models, field regridding, parallel computation capabilities and many others. ESMF provides Fortran, C and Python (limited) APIs. Many atmosphere, wave, ocean, land and sea-ice models are now ESMF-compliant, so coupling of these models is more feasible than ever. </p>

<p>Indeed, there are also efforts toward a standard and software design convention that would facilitate model development and coupling. Such standard is the <a href="https://earthsystemcog.org/projects/nuopc/">NUOPC</a> layer and is supported by the ESMF library. NUOPC sets the guidelines for software design and field naming conventions that promotes model interoperability. Any models following the NUOPC design conventions will be interoperable with each other out of the box, so the burdain is now moved to the actual model developers to make sure that their packages follow the new standards.</p>

<p>(My PhD thesis in progress uses ESMF to develop a coupled atmosphere-wave-ocean-model.)</p>

CC BY-SA 3.0
2014-09-02T15:34:41.520Z
2014-09-02T15:42:54.247Z
2014-09-02T15:42:54.247Z
milancurcic
<p>In climate modelling, there are three major model types that form the basis of a fully coupled Atmosphere-Ocean General Circulation Model (AOGCM):</p>

<ul>
<li>Atmosphere circulation models</li>
<li>Ocean circulation models</li>
<li>Land surface models</li>
</ul>

<p>There are at least 10-15 well-known models of each type that are widely used. Each atmosphere model usually has one, maybe two ocean models, and one or two land surface models that it has been made to work together with as an AOGCM. But if you want to use one atmosphere model with arbitrary ocean and land models, you usually have to modify the models to some degree to get them to play well together.</p>

<p>Are there any projects that aim to be a generic "glue" between any combination of climate models? This could be in the form of a software framework, or it could just be a specification for data format and exchange methods.</p>

CC BY-SA 3.0
2014-09-03T00:57:10.017Z
Meta discussion on tags here: http://meta.earthscience.stackexchange.com/questions/314/how-granular-should-tags-be
naught101
<climate-models><numerical-modelling><ocean-models><land-surface-models><software>
Are there any general-purpose climate-model coupling projects?
naught101
# Are there any general-purpose climate-model coupling projects?

(Asked by: username_0 on 2014-09-02)

In climate modelling, there are three major model types that form the basis of a fully coupled Atmosphere-Ocean General Circulation Model (AOGCM):

* Atmosphere circulation models
* Ocean circulation models
* Land surface models

There are at least 10-15 well-known models of each type that are widely used. Each atmosphere model usually has one, maybe two ocean models, and one or two land surface models that it has been made to work together with as an AOGCM. But if you want to use one atmosphere model with arbitrary ocean and land models, you usually have to modify the models to some degree to get them to play well together.

Are there any projects that aim to be a generic "glue" between any combination of climate models? This could be in the form of a software framework, or it could just be a specification for data format and exchange methods.

**Tags:** climate-models, numerical-modelling, ocean-models, land-surface-models, software

> **Comments:**
> **username_0**: Meta discussion on tags here: http://meta.earthscience.stackexchange.com/questions/314/how-granular-should-tags-be  

---

## 2 answers

### Answer by username_2 on 2014-09-02. Score: 10 | Accepted answer

Yes, there were many model coupling projects in the past, as well as many ongoing coupling projects in the present and near future.

The main motivation behind model coupling is the need for the interactive feedback processes between two or more separate physical systems, for example, atmosphere and ocean. Historically, these models have been developed independently of each other, i.e. they were uncoupled - unaware of each other. Given past and current technology and knowledge, modifying the models' source code so that they can exchange information in a consistent manner was a much smaller effort (typically few years) than it would take to develop a unified system model from scratch (i.e. atmosphere-ocean as a single dynamical core). Another advantage to the coupling approach is that different physical systems often describe processes that operate on very different spatial and time scales. Thus, it is often computationally advantageous to let physical systems have distinct models that are "coupled" through an intermediate layer.

The vast number of coupling projects throughout the 1990s and 2000s have demonstrated the need for more standardized coupling libraries or frameworks that would cut down on duplication of effort, software bugs and development time. @username_1's answer mentions a few of those. Probably the most mature and feature-rich framework at this point is the [Earth System Modeling Framework (ESMF)](http://earthsystemmodeling.org). ESMF provides data abstraction for geophysical models, field regridding, parallel computation capabilities and many others. ESMF provides Fortran, C and Python (limited) APIs. Many atmosphere, wave, ocean, land and sea-ice models are now ESMF-compliant, so coupling of these models is more feasible than ever.

Indeed, there are also efforts toward a standard and software design convention that would facilitate model development and coupling. Such standard is the [NUOPC](https://earthsystemcog.org/projects/nuopc/) layer and is supported by the ESMF library. NUOPC sets the guidelines for software design and field naming conventions that promotes model interoperability. Any models following the NUOPC design conventions will be interoperable with each other out of the box, so the burdain is now moved to the actual model developers to make sure that their packages follow the new standards.

(My PhD thesis in progress uses ESMF to develop a coupled atmosphere-wave-ocean-model.)


---

### Answer by username_1 on 2014-09-02. Score: 10

Coupler software (e.g. [OASIS](https://verc.enes.org/oasis), [MCT](http://www.mcs.anl.gov/research/projects/mct/), [C-Coupler](http://www.geosci-model-dev-discuss.net/7/3889/2014/gmdd-7-3889-2014.html)) is frequently used to combine these different components of earth system models. Of course interfacing models with each other using these couplers or other methods always needs some technical work and sometimes also some algorithmic work. Therefore the number of model combinations will always be limited.

> **Comments:**
> **username_0**: Interesting. OASIS looks like it's been around for more than 20 years, but it doesn't look like it's had much uptake - mostly French orgs. MCT seems newer, but also only has a small list of models that it currently works with. Do you have any experience working with any of these?  
> **username_1**: There is a lot of OASIS usage in Europe.  
> **username_1**: I used OASIS3 to create a coupled atmosphere, sea ice, ocean model.  
> **username_0**: Re: '... will always be limited.' - It does seem like a bit of an uphill struggle, but it would be nice to see a standard emerge from those projects, so that other component models could at least attempt to be compatible with more combinations of other models.  

---

