The Architecture of Scientific Software: IFIP TC2/WG2.5 Working Conference on the Architecture of Scientific Software October 2–4, 2000, Ottawa, Canada PDF
Preview The Architecture of Scientific Software: IFIP TC2/WG2.5 Working Conference on the Architecture of Scientific Software October 2–4, 2000, Ottawa, Canada
THE ARCHITECTURE OF SCIENTIFIC SOFlWARE IFIP -The International Federation for Information Processing IFIP was founded in 1960 under the auspices of UNESCO, following the First World Computer Congress held in Paris the previous year. An umbrella organization for societies working in information processing, IFIP's aim is two-fold: to support information processing within its member countries and to encourage technology transfer to developing nations. As its mission statement clearly states, IFIP's mission is to be the leading, truly international, apolitical organization which encourages and assists in the development, exploitation and application of information technology for the benefit of all people. IFIP is a non-profitmaking organization, run almost solely by 2500 volunteers. It operates through a number of technical committees, which organize events and publications. IFIP's events range from an international congress to local seminars, but the most important are: • The IFIP World Computer Congress, held every second year; • open conferences; • working conferences. The flagship event is the IFIP World Computer Congress, at which both invited and contributed papers are presented. Contributed papers are rigorously refereed and the rejection rate is high. As with the Congress, participation in the open conferences is open to all and papers may be invited or submitted. Again, submitted papers are stringently refereed. The working conferences are structured differently. They are usually run by a working group and attendance is small and by invitation only. Their purpose is to create an atmosphere conducive to innovation and development. Refereeing is less rigorous and papers are subjected to extensive group discussion. Publications arising from IFIP events vary. The papers presented at the IFIP World Computer Congress and at open conferences are published as conference proceedings, while the results of the working conferences are often published as collections of selected and edited papers. Any national society whose primary activity is in information may apply to become a full member ofIFIP, although full membership is restricted to one society per country. Full members are entitled to vote at the annual General Assembly, National societies preferring a less committed involvement may apply for associate or corresponding membership. Associate members enjoy the same benefits as full members, but without voting rights. Corresponding members are not represented in IFIP bodies. Affiliated membership is open to non-national societies, and individual and honorary membership schemes are also offered. THE ARCHITECTURE OF SCIENTIFIC SOFTWARE IFlP TC2jWG2.5 Working Conference on the Architecture of Scientific Software October 2-4, 2000, Ottawa, Canada Edited by Ronald F. Boisvert National Institute of Standards and Technology USA Ping Tak Peter Tang Intel Corporation USA ~. " SPRINGER SCIENCE+BUSINESS MEDIA, LLC Library of Congress Cataloging-in-Publication Data IFIP TC2/WG2.5 Working Conference on the Architecture ofScientific Software (2000: Ottawa, Canada) The architecture of scientific software: IFIP TC2/WG2.5 Working Conference on the Architecture of Scientific Software, October 2-4, 2000, Ottawa, Canada / edited by Ronald F. Boisvert, Ping Tak Peter Tang. Inc1udes bibliographical references and index. ISBN 978-1-4757-6719-3 ISBN 978-0-387-35407-1 (eBook) DOI 10.1007/978-0-387-35407-1 1. Software engineering-Congresses. 2. Computer architecture-Congresses. 3. Science-Computer software-Congresses. 1. Boisvert, Ronald F. II. Tang, Pink Tak Peter. III. Title. QA76.758 .l3452000 005.l-dc21 2001020365 Copyright © 2001 by Springer Science+Business Media New York Originally published by Kluwer Academic Publishers in 2001 Ali rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, mechanical, photo-copying, recording, or otherwise, without the prior written permission of the publisher, Springer Science+Business Media, LLC Printed on acid-free paper. Contents Preface ix Contributing Authors xv Part I Large-Scale Systems Integration Network-Based Scientific Computing 3 Elias N. Houstis, Ann Christine Catlin, Ganesh Balakrishnan, Nitesh Dhanjani, GaHyun Park, John R. Rice, Spyros Lalis, Manolis Stamatogiannakis, Catherine Houstis Future Generations of Problem-Solving Environments 29 Jose C. Cunha Developing an Architecture to Support the Implementation and 39 Development of Scientific Computing Applications Dorian C. Arnold, Jack J. Dongarra PETSc and Overture: Lessons Learned Developing an Interface 57 between Components Kristopher R. Buschelman, William D. Gropp, Lois C. McInnes, Barry F. Smith Component Technology for High-Performance Scientific 69 Simulation Software Tom Epperly, Scott Kohn, Gary Kum/ert A New Approach to Software Integration Frameworks for 87 Multi-physics Simulation Codes Eric de Sturler, Jay Hoe/linger, Laxmikant Kale, Milind Bhandarkar Code Coupling using Parallel CORBA Objects 105 Christophe Rene, Thierry Priol, Guillaume AlMon VI ARCHITECTURE OF SCIENTIFIC SOFTWARE A Collaborative Code Development Environment for 119 Computational Electro-magnetics Matthew Shields, Omer F. Rana, David. W. Walker, David Golby Part II The Architecture of Components On the Role of Mathematical Abstractions for Scientific Computing 145 Krister Ahlander, Magne Haveraaen, Hans Z. Munthe-Kaas Object-oriented Modeling of Parallel PDE Solvers 159 Michael Thune, Krister Ahlander, Malin Ljungberg, Markus Norden, Kurt Otto, Jarmo Rantakokko Broadway: A Software Architecture for Scientific Computing 175 Samuel Z. Guyer, Calvin Lin Formal Methods for High-Performance Linear Algebra Libraries 193 John A. Gunnels, Robert A. van de Geijn New Generalized Matrix Data Structures Lead to a Variety of 211 High-Performance Algorithms Fred G. Gustavson A Comprehensive DFT API for Scientific Computing 235 Ping Tak Peter Tang Using A Fortran Interface to POSIX Threads 257 Richard J. Hanson, Clay P. Breshears and Henry A. Gabb Data Management Systems for Scientific Applications 273 Reagan W. Moore Software Components for Application Development 285 Arnaud Desitter, Antoine Le Hyaric, Geoff Morgan, Gareth Shaw, Anne Trefethen Hierarchichal Representation and Computation of Approximate 301 Solutions in Scientific Simulations Wayne H. Enright Software Architecture for the Investigation of Controllable Models 317 with Complex Data Sets Dmitry Belyshev and Vladimir Gurman A Mixed-Language Programming Methodology for High 333 Performance Java Computing Vladimir S. Getov Contents vii Part III Conference Information The Architecture of Scientific Software: the Conference 351 Index 357 Preface IFIP Working Group 2.5 on Numerical Software has always been con cerned not just with strictly numerical issues, such as details of floating point arithmetic or numerical algorithms, but also with the software is sues that affect the viability of scientific computation. Previous working conferences sponsored by WG2.5 have included focus on software porta bility, programming languages for numerical software, programming and problem solving environments, parallelism, performance evaluation and software quality. These issues are, of course, of wider significance be yond numerical software. The solid basis of a practical perspective on scientific computation has lead the work of WG2.5 to be pioneering even in this wider context. This working conference addresses another such topic, one only re cently recognized as a critical aspect of software design, but a topic increasingly important as software gets larger and more complex, con structed by teams of people and evolved over decades. This topic is software architecture. Software architecture refers to the way software is structured to promote objectives such as reusability, maintainability, extensibility, feasibility of independent implementation, etc. In the con text of scientific computation, the challenge facing mathematical soft ware practitioners is to design, develop and supply computational com ponents which deliver these objectives when embedded in end-user ap plication codes. At one time, scientific computing applications were sufficiently sim ple that it was feasible with each new computational problem for one to start from scratch and construct a monolithic program specific to solving that particular problem. As these applications became more complex, it became necessary to amortize the development effort over many sim ilar computational problems. More significantly, it became necessary to be able to take advantage of rare, highly specialized, skills through em ploying off-the-shelf software components implemented by third parties. Thus for many years, the software architecture of a scientific computing application has typically been that the computation is effected not by x ARCHITECTURE OF SCIENTIFIC SOFTWARE just a single program but by the operation of a suite of related programs acting on a common database. Within such a suite, the individual pro grams are structured from subprograms. Some of these subprograms are obtained from libraries provided by various commercial suppliers, and some from public domain sources. A few subprograms will be unique to this suite of programs, representing the particular modeled science in the suite and the desired sequences of operations to be performed. Commonly, the user provides the main program that calls the subpro grams. In some cases, however, the main program is a framework that can realize different computations by making appropriate calls to the available subprograms, including any user-provided plug-in, and control over the sequence of calls and their parameters is provided by the user through a problem oriented scripting language. Today, new options for architectures for scientific computation are becoming available, and some of the older paradigms may need to be re-thought. What are the implications of widespread connectivity to networks, in terms of the construction of scientific computing applica tions in the future? Do distributed computing models such as CORBA and ActiveX, or the RMI (Remote Method Invocation) of Java, form an appropriate basis on which to build higher level protocols (e.g., for interacting mathematical and geometric objects) in pursuit of the goal of "plug-and-play" application inter-operability? Do we need to extend the notion of a common database to embrace federated databases, which may be geographically or organizationally dispersed across the Web, and only intermittently available? How can we exploit concurrency and par allel execution for monitoring, visualization and steering purposes, for instance, as well as for straightforward performance? If, as many people argue, object-oriented computing provides a more appropriate program ming basis than procedural languages, how can the properties (such as reliability, portability, efficiency, etc.) so painstakingly pursued by the developers of "traditional" subroutine libraries be preserved? With many conferences being held on the topic of software archi tecture, what is the added value of holding a conference on software architecture for scientific computing applications? Why might we antic ipate software architecture for scientific applications might differ from software architecture suitable for other situations? What are distinctive characteristics of scientific applications? Scientific applications often are very large computations that strain the resources of whatever computers are available. Clever algorithms and data structures may need to be utilized so that the computation can be done with acceptable efficiency, or even so that it can be done at all. The intended computation is often ill defined, or at least incom- PREFACE Xl pletely defined, and completion of the specification must be suggested by experience, by analogy to other computations, or by heuristics. Data types may include not just structures of text and numbers, but the full range of multimedia, from sound to simultaneous time series, from still images to video. Scientific applications typically require deep scientific and domain knowledge, and depend on subtle interplay of different ap proximations. They often implement sophisticated mathematics. In many cases, numerical computations need to be carefully arranged not just to avoid inaccurate results, but to avoid instability of processes. Sensitivity to external input data can be a problem, and inadequate in put data is common. Insightful display of computed quantities may be essential for analyzing and interpreting results or for interactive control to steer the computation. Scientific computations are often experiments, and must be controlled, recorded, and categorized so that they can be compared to other experimental observations. These characteristics make the implementation of scientific applica tions challenging, but have little direct effect on the architecture chosen for the software. Two classes of characteristics do, however, have sig nificant impact on software architectures that are, or should be, used for scientific applications. The first of these classes is the characteris tics of the context in which scientific applications are implemented, and the second class is the characteristics of the context in which scientific applications evolve. Can you suggest others? Implementation Context 1 Developers of scientific applications usually have deep understand ing of the science, and deep domain knowledge. They may have deep knowledge of the relevant mathematics. On the other hand, they typically don't see themselves as professional programmers; they see themselves as scientists. A consequence of this is that they are not familiar with modern software engineering practice and knowledge and may not recognize the need for it. As an extreme illustration, all too often they produce little or no documentation. 2 Normally, no formal specification document exists before or even after the application is implemented. 3 The development team often is distributed geographically and or ganizationally, that is, there is no single organizational manage ment in control of the development, and developers are often vol unteers from diverse organizations.
The list of books you might like
