Problem-Solving Environments for Computational Science

4 downloads 251 Views 65KB Size Report
Sep 11, 1997 - IEEE COMPUTATIONAL SCIENCE & ENGINEERING. This issue's theme is .... Reduce the cost and time to develop complex scientific software.
.

GUEST EDITORS’ INTRODUCTION

Problem-Solving Environments for Computational Science ELIAS HOUSTIS, Purdue University EFSTRATIOS GALLOPOULOS, University of Patras RANDALL BRAMLEY, Indiana University JOHN RICE, Purdue University ♦

T

his issue’s theme is the rapidly evolving enabling technology of problem-solving environments, defined as “a computer system that provides all the computational facilities necessary to solve a target class of problems” for scientific computing.1 The 19911 and 19952 workshops on PSEs for physical simulation helped to define this research area and highlight the pertinent research issues. The first workshop made several recommendations that led to the 1995 NSF initiative on PSEs. These efforts have identified several PSE design goals together with approaches for realizing them, as shown in Table 1. The workshops concluded that to realize these PSE design objectives six research challenges must be addressed. 1. Develop a PSE architecture that supports the plugand-play paradigm. This will involve creating a systematic framework with formally defined interfaces, supporting the dynamic assembly of software components, and keeping the framework open and tailored to the needs of scientific PSEs. 2. Exploit multilevel abstractions and the complex properties of science. Recognize the pervasive multilevel structure in science and engineering objects, and allow the addition of more detail and precision at all levels. Incorporate properties such as smoothness of functions, complexity of images, shapes of objects, and performance of methods (precisely defined and measured). 3. Reuse legacy scientific software. Encapsulation is possible for reasonably designed software provided some key parts of the legacy environment persist, such as compatible hard-

18





ware and a language compiler for new hardware. Recognize that there can be serious costs to using legacy software. 4. Create test beds for components and combinations. The plug-and-play paradigm is a good start. 5. Create complex but important components involving geometric modeling, scientific visualization, symbolic mathematics, scientific databases, general optimization, object property measurement, etc. 6. Create knowledge bases for solvers and problems. Provide automation of (or help for) construction of the PSE, dynamic selection of a solver, selection of hardware, suitability of output, management of long-term computations. Some of these ideas have existed since the early days of computing. As early as 1963, Culler and Fried3 proposed the construction of “an online computing center for scientific problems” consisting of ♦ an organization that uses as elements mathematical functions rather than individual numbers, ♦ control and display features that make direction of the computer by the user and feedback of graphical information from the computer rapid and convenient, and ♦ so-called console programming, which allows the user to compose subroutines by pushing buttons. In modern terms, the first item is the idea of interaction in the language of the application (in this case the emphasis is mathematics), the second deals with facilities for pre- and postprocessing and multimedia, and the third is a precursor to visual-programming environments that have been recently incorporated as user interfaces to several PSEs such as the IRIS Explorer and Khoros.

1070-9924/97/$10.00 © 1997 IEEE

IEEE COMPUTATIONAL SCIENCE & ENGINEERING

.

Table 1. PSE design goals and some approaches for realizing them. Goal

Solutions

Reduce the difficulty of physical simulation

Use natural languages and application-specific terminology Automate many lower-level computational tasks

Reduce the cost and time to develop complex scientific software

Reuse large and small software components Raise the level of abstraction in software Create components for symbolic mathematics, geometric modeling, scientific visualization

Increase the availability of scientific software components

Provide comprehensive catalogs, component search and delivery systems, standard terminology, and interfaces

Build families of applications for science and engineering PSEs

Provide infrastructure, including a generic software architecture and associated kernel for such PSEs, facilities for composing software parts and for inserting new parts, and facilities for measuring and testing the properties of scientific software

Raise the reliability of physical simulation

Allow the reuse of reliable components Provide test beds for new components

Extend the lifetime of software

Create encapsulation methodology for legacy software Use programming-language-independent interfaces Use open-ended systems for software parts Provide extensive facilities for transforming types and representations

Identify and foster a community of PSE builders

Challenges, opportunities New challenges and opportunities have since become evident. One such area is the integration of multiple interacting applications. The growth of computational power and networking suggests that computational science will shift from the current single physical-model design to the design of a whole physical system with a large number of models interacting through geometric and physical interfaces. For example, the design of an airplane engine requires that several domain-specific analyses such as structural engineering, computational fluid dynamics, and optimization interact to find the final solution. We refer to these multicomponent-based physical systems as multidisciplinary applications. MAs will have significant impact in industry, education, and training, and will require the development of new algorithmic strategies and software for managing their complexity and harvesting the power of the expected HPCC resources. A new challenge is to identify the framework for the numerical simulation of MAs and to develop the enabling theories and technologies needed to support and realize this framework in specific applications. We refer to such frameworks as multidisciplinary PSEs (MPSEs). Each component of a MPSE is itself a difficult and sophisticated problem domain area, so the elements of a MPSE are themselves discipline-specific PSEs. The MPSE design objective is to allow the “natural” specification of multidisciplinary applications and their simulation with interacting PSEs through mathematical and software interfaces across networks of heterogeneous computational resources.

JULY–SEPTEMBER 1997

The future computational paradigm for PSEs will be network-based, enabled by HPCC advances in network hardware and software. This is driven by three needs:

♦ most scientific computing work is now multidisciplinary and involves researchers geographically distributed across wide distances, ♦ compute servers are now typically distributed, and ♦ PSEs involve large numbers of software components from multiple sources, each requiring updates, bug fixes, and licensing. Users of PSEs are increasingly geographically distributed, a situation that will worsen for MPSEs involving multiple domains of application expertise and hence multiple expert users. Collaborative PSEs allow distributed users to interact on a single problem, simultaneously selecting and building a solution strategy. Collaborative PSEs will play an increasingly important role in industry, distance education, and large-scale scientific-computing research—in general wherever human resources cannot be concentrated in a single geographic location. Several enabling technologies for network-based collaboration have been developed in the past two years based on object request brokers and Java-based tools. However, much research needs to be done before they can provide practical systems for computational science PSEs. Issues include security (limiting collaboration), mediation of conflicting requests from multiple users, sharing of active graphics objects among several GUIs, and asynchrony—since collaborators may want to work at different times, particularly if six or more time zones separate them.

19

.

Products become services In the same way that users will be distributed, future PSEs will have vital pieces of software and information spread across the network, pieces that will be identified and linked only at runtime. This network-computing (NC) paradigm contrasts with the current software usage model where one purchases a copy (or copies) of a general-purpose, monolithic software package for use on local hosts, possibly distributed on a collection of local hosts. With network-accessible software repositories and NC, the view of software changes from a product to a service. A network-accessible repository provides access to up-to-date copies of software components on an as-needed basis, so-called “disposable software.” With NC, the software developer provides a computing service to interested parties over the network. The disposable software and NC models do not apply to all computing services; basic operating system and network access software, as well as low-level math routines that are tuned for the particular machine architecture, will be permanently resident on the user machine. One advantage of the NC model is that as the software provider improves the product, there is no need to release new versions and upgrades. The user simply sees an improved service. The analogy could be to the phone system: changes in the software of the local switch are completely transparent to the user, save for the availability of additional or enhanced functionality. Similarly, the service provider can upgrade the hardware without affecting the user. The emphasis on networking is not accidental: the “Internet revolution” took everyone by storm and luckily, the CSE community was the first to profit. Our community appears committed to exploit these advances to the fullest, as indicated by this theme issue, a companion book on PSEs which the IEEE Computer Society is planning to publish, ideas such as metacomputing,4 and efforts such as Internet 2. We will thus avoid what was predicted at the 1991 workshop, namely that “scientific PSEs” would fare much worse than PSEs for tasks such as architectural CAD, desktop publishing, and tax preparation.

Toward the network paradigm We envision that the network-based paradigm of software usage will eventually become fully automated and effectively transparent to the user. The realization of this scenario will require research in four areas. Resource selection

NC development is critically dependent on how we specify problems, extract content information, build knowledge bases, infer answers, and apply collaborative reasoning to identify software and hardware resources to support problem solving. System software

In order for the NC paradigm to be realized, we in the

20

PSE community must standardize both low-level and high-level library interfaces. Network-based software delivery systems must be able to transparently resolve issues regarding local and networked computational resources and configurations, as well as software licensing and accounting issues. We must address the architectures of network servers and clients, clients’ GUIs, client-server communication protocols, security, and software reliability in the context of scientific software. We must also evaluate implementation technologies such as WWW, CGI, Java, client-server computing, Corba-compliant object request brokers, JSPA, Inferno, Oblets, and Aglets. Software testing

The “network” is ideal for linking test suites in various scientific domains, forming national repositories and making them available in the form of servers. However, reliable testing still requires standardization of testing data and automatic ways to collect and analyze the results of this process. Domain-specific scientific software servers

The effectiveness of any computing paradigm depends in great part on the availability of powerful problem-solving capabilities for application domains (in the jargon of telematics, this is referred to as content). As PSE systems proliferate, users will want to move data from one PSE to another in order to share data, benefit from system synergies, and disseminate results. Therefore standardization and interoperability, at higher levels than ever before, will be critical. One such example is the OpenMath project,5 which is addressing this issue by providing standards for communicating mathematical objects between programs. It also offers various generators for high-level-language and text-processing-oriented output and other mechanisms for interaction with commercial packages.

Theme articles One PSE design objective is the so-called machine-independent programming-in-the-large environment, which must be able to generate efficient execution code for different machine architectures and runtime support systems. The article by Robert van Engelen, Lex Wolters, and Gerard Cats, “Tomorrow’s Weather Forecast: Automatic Code Generation for Atmospheric Modeling,” discusses a software system that takes a high-level description of a weather forecast model—in the form of a set of PDEs, including a specification of the discrete method used and computer architecture details—and generates executable Fortran 77 or HPF source code. The scientific computing community has managed to establish modular programming and to encourage and support many state-of-the-art libraries for a variety of scientific computing problems. However, it is obvious that we cannot have libraries for every possible mathematical problem, and very often engineers and sci-

IEEE COMPUTATIONAL SCIENCE & ENGINEERING

.

entists need to write significant customized code that has little chance to be reused. Another PSE design objective is the capability of symbolically generating execution code out of a high-level specification of the problem together with features of the solution algorithm. This is an important goal, especially for 3D problems where the complexity of the geometry increases greatly. The challenge here is to combine the geometric features of the problem domain with the corresponding solution features. In “SciNapse: A ProblemSolving Environment for Partial Differential Equations,” Robert Akers, Elaine Kant, Curtis Randall, Stanly Steinberg, and Robert Young address some aspects of symbolic code generation for initial-boundary-value problems based on systems of PDEs defined on simple geometries. The development of domain-specific PSEs that integrate libraries and “coupled” software systems, at multiple levels (presentation, data, and execution) across several computational platforms, has been identified as a necessity to empower the practitioners and the developers of new algorithmic solutions.1 The Internet and particularly the Web have helped scientists envision this software in a NC setting. This vision promises the availability of powerful PSEs and computational servers anytime and anywhere without the overhead and cost associated with installing, maintaining, and upgrading software and hardware resources. The article “Scientific Computing via the Web: The Net Pellpack PSE Server” by Shahani Markus, Sanjiva Weerawarana, Elias Houstis, and John Rice describes a domain-specific PSE for PDE-based problems and demonstrates the feasibility of the NC scenario in the context of PDE computing. The predicted growth of computational power and network bandwidth suggests that computational modeling and experimentation will shift from the current single physical or biological system modeling to the modeling of multiple physical or biological systems interacting with each other through a large number of parameters. Robert Knox, Virginia Kalb, David Kendig, and Elissa Levine have developed a PSE for linking models of ecosystems and performing coupled simulations. The design of this PSE is reported in their contribution, “A Problem-Solving Workbench for Interactive Simulation of Ecosystems.”

S

everal of these computational and infrastructure advances are fundamental to many more human endeavors than science and engineering. PSEs, however, occupy a central role in CSE. Their design and construction requires collaboration among scientists and engineers and thus represents the type of cross-disciplinary activity that characterizes the field. As one of us has argued before,4 PSEs are the product of the field we call CSE. ♦

References 1. E. Gallopoulos, E.N. Houstis, and J.R. Rice, “Computer as

JULY–SEPTEMBER 1997

2.

3.

4.

5.

Thinker/Doer: Problem-Solving Environments for Computational Science,” IEEE Computational Science & Eng., Vol. 1, No. 2, Summer 1994, pp. 11-23. J.R. Rice and R.F. Boisvert, “From Scientific Software Libraries to Problem-Solving Environments,” IEEE Computational Science & Eng., Vol. 3, No. 3, Fall 1996, pp. 44-53. G.J. Culler and B.D. Fried, “An On-Line Computing Center for Scientific Problems,” Proc. 1963 Pacific Computer Conf., IEEE, Piscataway, N.J., 1963, pp. 221-242. E. Gallopoulos and A. Sameh, “CSE: Content and Product,” IEEE Computational Science & Eng., Vol. 4, No. 2, April-June 1997, pp. 39-43. OpenMath home page: http://www.openmath.org (current 11 Sept. 1997).

Elias N. Houstis is professor of computer science and the director of the Computational Science and Engineering Program at Purdue University. His research interests include PSEs; computational finance; parallel, neural, and mobile computing; performance evaluation and modeling; expert systems for scientific computing; numerical analysis; and distributed learning. He received a PhD in mathematics from Purdue University and a BS in mathematics from the University of Athens. WWW, http:// www.cs.purdue.edu/people/enh. Randall Bramley is associate professor of computer science at Indiana University, director of the IU Scientific Computing Program, and director of its NSF-funded SCAAMP project. His research interests include parallel computing, methods for largescale linear systems, visualization, problem-solving environments, and applications to CFD. He is also IEEE CS&E’s Technology News & Reviews editor. E-mail, [email protected]. Efstratios Gallopoulos is professor of computer engineering and informatics at the University of Patras, Greece. He received a PhD in computer science from the University of Illinois at UrbanaChampaign and a BSc (first class honors) from Imperial College, London. He participated in the development and practical application of the Cedar multiprocessor at the Center for Supercomputing Research and Development, and the Goodyear MPP at NASA Goddard Space Flight Center. His research interests include algorithms and environments for large-scale scientific computation, and CSE education. He is an IEEE CS&E editor and a member of IEEE and SIAM. E-mail, [email protected]. John R. Rice is the W. Brooks Fortune professor of computer sciences at Purdue University. He is the author of several books on approximation theory, numerical analysis, computer science, and scientific software. He founded ACM’s Transactions on Mathematical Software in 1975 and was its editor-in-chief until 1993. He is also an IEEE CS&E area editor for software. Rice received his PhD from Caltech and his BS and MS from Oklahoma State University, all in math. He is a member of the National Academy of Engineering, the IEEE Computer Society, ACM, IMACS, and SIAM. WWW, http://www.cs.purdue.edu/people/jrr.

21