A quick note to begin with, the next OpenFOAM UK & Ireland user meeting will be held on the 18th and 19th of April 2016 at the University of Exeter. This is a free event but requires registration, so if you are interested then please head on over to http://ukri-openfoam.ex.ac.uk/ where you can register. This will be the fourth time this event has run, with the third being held at Daresbury Laboratory in Warrington that saw nearly 100 people come together.
All told these events are proving more and more useful, so anybody either using or developing OpenFOAM (or interested in either) should come along!
On to the topic of this post. Coupling. Of course I don't mean speed-dating or anything like that, I mean the act of getting two or more pieces of software to work harmoniously on a single problem. This is not a new concept, indeed it has probably been around as long as scientific software has existed. In fact as a concept it is even deeply embedded into fundamental computer science things like Object Orientation. However, it is something that is receiving more and more attention as of late, perhaps due to an ever increasing capacity for computation becoming available and a realisation that creating a "monolithic" solution to solve all physics problems is simply unrealistic. However, one issue at the moment is a lack of standardisation.
There are lots of projects out there, some huge, some very small, some aiming at generic solutions, some offering very specific capabilities to make one piece of software talk to one other. One common trait though is that terminologies are still often interchangeable and the best approach for most situations has yet to be defined.
I don't want to harp on too much in the space of a single blog, however I thought it might be nice to at least define what this author thinks is meant by some of the most common terms used alongside "coupling", it would be interesting to see if there is agreement or not as to their general applicability:
- Loose coupling: A system comprised of multiple discrete components where each may able to transfer data to and/or from another but none are reliant on any other for their continued operation.
- Tight coupling: As per loose-coupling but where at least one component in the system is reliant on another to operate.
- Monolithic coupling: A system in which two or more discrete components are combined to the point where they can no longer be distinguished from each other, effectively becoming a single entity.
In my experience, when people say "code coupling" they are most commonly speaking about the second type, however it would be nice for these phrases to become formalised so no explanation is needed (some may argue that has already happened, however a recent review excercise undertaken by the author has lead him to believe that not to be true).
How about if you have your own piece of code and want to make it work with something else, but you don't know where to start. You could create your own interface, however it may be more sensible to see if something that already exists fits your bill already. As a starting point, here are a few notable projects:
- MpCCI (Fraunhofer SCAI; commercial; http://www.mpcci.de/mpcci-software.html): This commercial solution can be found embedded into many existing and well-known software packages and even has an interface for OpenFOAM. It provides a library to connect into new software, however it should be noted that for it to work, you will need to purchase a license to operate the server which acts to coordinate all coupled applications.
- MUSCLE2 (MAPPER Project; Open-source; http://www.mapper-project.eu/web/guest/muscle): A result of the European funded MAPPER project, the MUSCLE2 library and suite is an in-depth solution to code coupling and management. It is perhaps a little too heavy-weight for many situations, but for those serious about coupling, it's well worth a look. The MAPPER project has now evolved into the new EU COMPAT project, with lots of member institutions (http://www.compat-project.eu/), which is focussing more specifically on the multi-scale aspect of coupling.
- CouPE (ANL; Open-source; http://sigma.mcs.anl.gov/coupe-coupled-physics-environment/): Part of ANL's SIGMA tool-kit, this takes a similar approach to MUSCLE2 and suffers the same problems in terms of the learning curve and overheads involved with framework set up. However, a very complete solution with lots of good publications associated.
There are many other examples, so it is always worth having a look to see what exists before assuming you need to reinvent the wheel!
Code coupling is a hot topic but one that now needs its respective communities to begin to come together. There are too many competing efforts out there for something that, really, can only be done in a few ways for nearly all cases. Ultimately it is reasonable to say that the general need, when scientific code coupling is considered, can be boiled down to "one piece of software needing to communicate with another and impart information about its physical state at a specified point, at a known point in time."