Tight and Loose Coupling

During the recent coupling workshop the terms “tight” and “loose” were used frequently as qualitative descriptions of couplings.  I began to wonder if everyone has the same idea in mind when using the terms.  Clearly they are relative terms–one coupling is only tight when compared to another.  Within a particular coupled model made up of multiple constituents, some couplings are tighter than others.

Even if “tightness” of coupling is not formally defined, it would be helpful to know what kinds of interactions require tight coupling and why.  There is some terminological tension here because “tight coupling” as a general software engineering principle is seen as a bad thing.  In the SE literature, the terms “coupling” and “cohesion” describe the relationship between two or more software modules.  In general, you seek high cohesion and low coupling between modules.  Cohesion is a measure of the degree to which the code segments in a software module are related to each other–such as performing a common function or operating on the same data structures.  High cohesion is seen as a good property because it means that functionally-related parts of code are collocated.  This makes it easier to understand, test, maintain, and debug the code.  Coupling is a correlated metric having to do with the degree of inter-dependence between two or more software modules.  Low or loose coupling is generally seen as good because it means that the software modules are not so intertwined that you can’t distinguish or separate them.  Highly coupled modules are strongly inter-dependent such that you really can’t have one without the other.  This makes it hard to understand what one module is doing without also understanding the other.  Unit testing also becomes very difficult since you cannot effectively define tests that target only a single module.  Instead, you are forced to test the tightly coupled synthesis as a single unit.

When used by the geoscience modeling communities (and other scientific communities), the terms “tight” and “loose” coupling are used in a different way, although there appears to be a relationship between tightly coupled physical phenomena and tightly coupled software modules.  Sets of physical processes are said to be tightly (or “strongly”) coupled when they exhibit a high degree of non-linearity.  In this case, the interaction cannot be easily broken down into distinct processes that can be computed independently and combined in a straightforward manner.  This implies that the strongly coupled interaction may be best thought of as a single unit.  As an analogy, consider that it is hard to say a lot about the properties of water by studying hydrogen and oxygen independently.  Linear systems, on the other hand, can be broken down into separate calculations and combined to get a final solution.  For example, think of computing wave amplitudes independently and adding them together to get a final picture of the combined waveform.

Perhaps a sufficiently vague definition of tight coupling that could be used to refer to both physical interactions and software interactions is “high inter-dependence.”  That being said, we can perhaps be a bit more precise about what tight coupling means.  Here are some possibilities that were mentioned at the coupling workshop and/or I found in the literature.

  • Jay Larson gives a definition of tight coupling between two constituent models based on the ratio of the models’ timesteps to the interval of time between coupling interactions [1].  In other words, as the constituent models step through time, how often is coupling data exchanged?  Two models that couple at every timestep have a ratio 1 and are tightly coupled.  A nice property of this metric is it gives us the ability to compare the relative tightness of couplings among all the model interactions in the entire coupled system (e.g., the atmosphere-land coupling is tighter than the atmosphere-ocean coupling by a factor of twenty).
  • Volumetric coupling is tighter than interfacial coupling.  Rob Jacob stated this a bit more formally by saying that an M-dimensional model coupled to another M-dimensional model via an M-dimensional interface is tightly coupled.  Inversely, an M-dimensional model coupled to another M-dimensional model via an M-1 dimensional interface is loosely coupled.  This implies that an atmosphere-chemistry coupling is tight while an atmosphere-land coupling is loose.
  • Tight coupling might also mean implicit coupling.  Again, Jay Larson provides a nice distinction between explicit and implicit coupling:  “Explicit coupling constitutes one way data delivery between source and destination constituents, for example boundary conditions or interfacial fluxes exchanged in a coupled climate model.  Implicit coupling is indicative of simultaneous, two way state-to-state coupling, for example self-consistent computation of electromagnetic fields for core-edge coupling in tokamak simulation” [1].
  • The “implicit coupling” mentioned above should not be confounded with an implicit numerical calculation which involves solving a system of equations at a given timestep (instead of a straightforward “explicit” calculation which can be determined directly from the previous timestep’s data).  The GFDL exchange grid enables implicit calculation of vertical diffusion across the surface-atmosphere boundary [2], even if the atmosphere and land do not share a grid.
  • Finally, tight coupling might also be used in the software engineering sense of the word.  For example, two constituent models might share data structures and make assumptions about the internal workings of each other.   Additionally, one module might exhibit a large amount of control over another, making many fine-grained calls to the other component.

Interestingly, it appears that strongly coupled physical processes are often implemented using tightly coupled software modules.  For example, the strongly coupled atmosphere-chemistry interactions require volumetric (3D) exchange of data.  This can be costly, so one way of handling this is for the atmosphere to expose certain internal data structures such that the chemistry module can make direct reads and writes to it.  Ideally, even strongly-coupled physical phenomena could be represented in a modular way so that the individual pieces could be verified separately, unit tested, and perhaps exchanged with other representations.  This may or may not always be possible.  As pointed out by Sophie Valcke, a good example of where this has been achieved is the GFDL Flexible Modeling System (FMS) which still allows implicit resolution of vertical diffusion over the whole atmosphere and land column while keeping the atmosphere and land components modularized, even when the two modules do not share a grid.  In this case, the “exchange grid” is the mediator that bridges the gap between the two.

[1] J. Walter Larson, “Ten organising principles for coupling in multiphysics and multiscale models,” ANZIAM J., 48, C1090-C1111 (2009).

[2] V. Balaji, Jeff Anderson, Isaac Held, Michael Winton, Jeff Durachta, Sergey Malyshev, Ronald J. Stouffer.  The Exchange Grid: a mechanism for data exchange between Earth System components on independent grids.


About rsdunlapiv

Computer science PhD student at Georgia Tech

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: