Since 1986 - Covering the Fastest Computers in the World and the People Who Run Them

Language Flags
December 11, 2013

Adding MUSCLE to Multiscale Simulations

Joris Borgdorff, Derek Groen, and Mariusz Mamonski
muscle6

Multiscale models help understand phenomena with a wider scope or an increased level of detail. These models allow us to take the best from multiple worlds, for example by combining models with a fine-grained time or space resolution with models that capture systems over a large baseline.

Classical examples of multiscale modeling include coupling atomistic models to coarse-grained models, where several atoms are represented instead as a single fused particle, or coupling fine fluid dynamics models to coarser structural mechanics models. In both cases, we have a fairly good understanding of the single scale phenomena, but still have little knowledge of the interactions between these phenomena. As understanding these interactions is key to understanding these phenomena as a whole, many researchers are now actively developing and using multiscale modeling techniques [1].

Researchers from different disciplines recognized their common need for a general multiscale computing approach, and started the European e-Infrastructure MAPPER project in 2010. The project aimed to bring their demanding multiscale applications to HPC, in an approach that uses the commonalities in multiscale modeling for applications in biomedicine, hydrology, nanomaterials, fusion, and systems biology.

muscle5The project settled on the theoretical and components-based Multiscale Modeling and Simulation Framework [2], which defines a multiscale model as a set of coupled single scale models (see Fig. 1). This approach allows code reuse, since single scale models often already exist, and defines clear opportunities for scheduling and distributing multiscale models, since the coupling is separated from the single scale code. Single scale models (or submodels) are implemented, verified, and validated in isolation, after which their interaction is added. They interact through input and output ports, sending or receiving simple parameters there, or entire datasets or geometries. A conduit transports the data from one port to another and intermediate components transform the data, implementing so-called scale-bridging techniques.

The Multiscale Coupling Library and Environment 2 (MUSCLE 2, http://apps.man.poznan.pl/trac/muscle) was created to implement and execute multiscale models with feedback loops, which we call cyclic coupling topologies. MUSCLE is truly a domain-independent approach, as it has so far been adopted, amongst others, by the abovementioned applications in MAPPER, and run on several supercomputers and clusters in Europe, as well as the Amazon cloud infrastructure. It consists of a library,  scripted coupling and a runtime environment.

Figure 2. Layered design of MUSCLE 2, separating implementation, coupling and execution.

Figure 2. Layered design of MUSCLE 2, separating implementation, coupling and execution.

By design, submodels do their computations independently, and MUSCLE 2 allows them to be implemented in different programming languages (C, C++, Fortran, Java, Scala, Python, or MATLAB) and for them to run on multiple machines. Conduits in MUSCLE 2 use shared memory communication where possible, and TCP/IP communication otherwise.  Using TCP/IP makes communicating between different computers as transparent as running on a single host. A central simulation manager acts as a white-page service for the submodels in a simulation, but after a submodel is registered there it does decentralized message passing with other submodels to prevent possible bottlenecks. By running each submodel in a separate process or thread, MUSCLE 2 has inherent multiscale parallelism.

MUSCLE 2 separates the submodel code, which just knows about input and output ports, from coupling code, which knows which ports will be coupled. This allows users to change the coupling topology without recompiling or redeploying code. Additionally, the coupling code is independent from the resources that the simulation will be eventually run on, so the same coupling can be submitted to multiple machines or be spread out over them, even when they reside in different countries. This allows us not only to use more resources but, more importantly, to take advantage of architectures that are optimal for each of the models involved. For example, some models in a simulation may greatly benefit from GPGPUs, whereas others have large memory requirements.

Within a supercomputer, MUSCLE 2 can make direct connections between processes, but almost all supercomputers have firewalls in place that prevent direct connections between worker nodes in different supercomputers. In MUSCLE 2we resolve this by providing a TCP/IP forwarding service, the MUSCLE Transport Overlay, that runs on interactive nodes of the cluster and forwards messages between MUSCLE 2 installations on different clusters.

To optimize the speed for large messages, MUSCLE 2 has the option of using the MPWide library (http://www.github.com/djgroen/MPWide), a high-performance communication library that was used to cosmological simulations in parallelized across multiple supercomputers [3]. MUSCLE 2 processes can be run directly as a supercomputer job and have few dependencies, but require the address of the site simulation manager to connect to other processes. This can be done manually or automated via a dedicated service such as provided by the QosCosGrid software stack (http://www.qoscosgrid.org/). QosCosGrid provides middleware solutions, notably on the Polish national grid (PL-Grid), that allow users to schedule and coordinate simulations running in multiple distributed HPC resources [4]. MUSCLE 2 is open source software (LGPL version 3 license) that runs on Linux and OS X and can be freely installed without administrative privileges.

In memoriam Mariusz Mamonski (1984 – 2013)

We wish to dedicate this paper to the memory of Mariusz Mamonski, whose sudden decease came as a shock to us all. The MUSCLE 2 team would like to thank Mariusz for all his professional and personal contributions to distributed multiscale computing. His dedication to end-users, his insight in software quality and his experience with infrastructures was truly impressive, and he will be sorely missed.

Biographies:

muscle3Joris Borgdorff is a PhD candidate at the Computational Science group of the University of Amsterdam, researching the formal background of multiscale and complex systems modeling and the applied aspects of distributed multiscale computing. He received a BSc in Mathematics and in Computer Science (2006) and an MSc in Applied Computing Science (2009) from Utrecht University. He is involved in the European MAPPER and Sophocles projects.

 

muscle2Derek Groen is a post-doctoral researcher at the Centre for Computational Science at University College London and a Fellow of the Software Sustainability Institute. He has expertise in high performance and distributed computing, as well as multiscale simulation. Derek has worked on a range of applications, and modelled star clusters, cosmological dark matter structures, clay-polymer nanocomposite materials, turbulence and human bloodflow using supercomputers. He obtained his PhD in Computational Astrophysics in Amsterdam in 2010.

 

muscle1Mariusz Mamonski (1984 – 2013) received his diploma in Computer Science at the Poznan University of Technology (Laboratory of Computing Systems) in 2008. He started working at the Application Department of the Poznan Supercomputing and Networking Center in 2005. He contributed to several research EU projects, in particular: GridLab, InteliGrid, BREIN and QosCosGrid, and was involved in the national and European e-Infrastracture projects PL-Grid and MAPPER. His research primarily focussed on web services, queueing systems and parallel execution and programing environments. He was an active member of the Open Grid Forum Distributed Resource Management Application API (OGF DRMAA) working group.

Acknowledgements

We would like to thank the Bartosz Bosak and Krzysztof Kurowski from the Poznan Supercomputing and Networking Center for their support and input, and we thank Alfons G. Hoekstra from the University of Amsterdam for his feedback.

References:

[1] Groen et al., Survey of Multiscale and Multiphysics Applications and Communities, IEEE Computing in Science and Engineering, http://dx.doi.org/10.1109/MCSE.2013.47.

[2] Borgdorff et al., Foundations of distributed multiscale computing: Formalization, specification, and analysis, Journal of Parallel and Distributed Computing http://dx.doi.org/10.1016/j.jpdc.2012.12.011

[3] Groen et al., A lightweight communication library for distributed computing, accepted by the Journal of Open Research Software, http://arxiv.org/abs/1312.0910.

[4] Kravtsov et al., Grid-enabling complex system applications with QosCosGrid: An architectural perspective, Proceedings of the 2008 International Conference on Grid Computing & Applications, Las Vegas, Nevada, USA, 2008, pp. 168–174.

[5] Borgdorff et al., Distributed Multiscale Computing with MUSCLE 2, the Multiscale Coupling Library and Environment, submitted to the Journal of Computational Science, http://arxiv.org/abs/1311.5740