Smalltalk — the next generation scientific computing interface?

Mathematics and Computers in Simulation 31 (1989) 371-381 North-Holland

371

SMALLTALK - THE NEXT GENERATION SCIENTIFIC COMPUTING INTERFACE? Richard L . PESKIN, Sandra S . WALTHER and Andy M . FRONCIONI Center for Computer Aids For Industrial Productivity, Rutgers University •, P.O. Box 1390, Piscataway, New Jersey 08855-1390 U.S.A .

The need for rapid prototyping of numerical simulations is considered, and an object-oriented, graphical based system (Smalltalk) is proposed as a basis for a new approach to user interfaces for scientific computing . The interface system requirements for problem expression . automatic programming, visualization, computational steering, and concurrent computing are discussed .

1. Introduction While scientific and engineering computation needs have been a major driving force in the development of high performance computer hardware, accompanying software practices in the scientific community have remained nearly static for about 30 years . This mis-match between hardware and software development has several consequences, two of which are (a) inability of the user community to fully utilize hardware capabilities, and (b) primary use of the computer as a "numerical production" tool as opposed to a tool for interactive prototyping and design . The former is a result of poor support of concurrent computing, interactive graphics, etc. by traditional software . The latter is a result of the labor intensive aspect of traditional software methods and their poor interface to end-user needs . This paper discusses the primary features of an interactive computation system for scientific prototyping, and how well those features might be provided by a modern interactive software system, namely Smalltalk-80 * * when used in conjunction with high performance computing systems . We distinguish between "production" computing, and prototyping . The former is characterized by relatively static models and codes ; the latter by models which are evolving . Our interest is primarily in the user interface requirements for interactive scientific-engineering computational prototyping. These requirements include : 1 . problem or model expression in natural (mathematical) manner, not "computerese" ; 2. automatic program generation and execution with reasonable speed and accuracy ; 3 . graphical visualization of computational output and interactive capabilities to manipulate the graphic views ; 4. provision for in situ model changes and computational steering ; software-hardware (most likely parallel computer) systems powerful enough to support realistic scientific and engineering problems . * This research was supported in part by the Parallel Computing Laboratory of the Center for Computer Aids For Industrial Productivity (CAIP) . CAIP is supported by the New Jersey Commission on Science and Technology, Rutgers - the State University of New Jersey, and the CAIP Industrial Members . "" Smalltalk-80 is a registered trademark of Xerox Corp . 0378-4754/89/$3 .50 J 1989, Elsevier Science Publishers B .V . (North-Holland)



372

R.L. Peskin et al. / Smalltalk

2. The Smalltalk environment Smalltalk-80 is the latest instantiation of an interactive computing environment that has been under development for over a decade [1]. Smalltalk is a totally object-oriented system. As such, it has two essential features for scientific prototyping, data abstractions (objects) which can model behavior of physical world objects and dynamic binding which is essential to permit run-time model changes needed for computational steering . In addition, Smalltalk supports a tightly coupled interaction of the computational model, its graphical view, and user control of the model thru interaction with the view . According to Pinson and Wiener [2], a true object-oriented environment must support four properties : abstraction (concise representation of more complex data types), encapsulation (clear scope of an object's internal software with defined user interface and protected internal implementation), inheritance (ability of an object to inherit "behavior" from parent objects), and polymorphism (ability of objects to respond differently to identically named behavior requests) . In effect, a Smalltalk system consists of a collection of classes arranged in an hierarchical manner . These classes have associated behaviors, i.e . the ability to respond to requests to perform some function ; the requests are called messages . These behaviors are implemented privately by each of the classes, and as such are protected from inadvertent modification . Programming consists of defining new classes, and appropriate behaviors for those classes (the collection of behaviors for a class is called its protocol) . To "run" a program, one creates a specific instance of a class (this instance is an "object") and sends this object a collection of messages . An important feature of Smalltalk is its ability to effect "dynamic binding" . This is the ability to have messages to objects interpreted at run time (as opposed to static message assignment at compile time) . Dynamic binding turns out to be a key feature for an interactive scientific-engineering environment. It will permit interactive modifications of the model equations . Much of the work in Smalltalk is done in Workspaces and in the System Browser . The source code for the system (except for the machine level components) is available to the user through the Browser. Programming involves changes to the (very extensive) provided code, and new additions . The editorial functions, compiler, and execution all form a "seamless" (uniform operating mode) environment . Smalltalk has a simple syntax ; messages are sent in the form : Object message : (parameters) . Unary operators are in post-fix notation, that is the square root of 3 is 3 sqrt .

The system is supplied with numerous transcendental functions and primitive floating point support (if present on the computer) . Current floating point support is single precision but this can be modified using user-added primitives . Very large precision arithmetic is possible in many cases by simply preserving fraction data typing . Complex numbers are straightforward to include. [2] There is a large collection of code available in the user community implementing FFT, matrix operations, signal processing, image processing, etc . Because Smalltalk run-time involves incremental compilation and byte-code interpretation (or its equivalent), the scientific community might question its ability to effect reasonable performance . We will address this issue in a later section ; it is sufficient to state here that modern Smalltalk implementations allow interfaces to C and Fortran based programs, machine language primitives, and distributed processing via networking . We next consider how object-oriented computation supports the five requirements stated above.



R . L. Peskln et at / Smalltalk

373

2 .1 Problem expression

Effective rapid prototyping of scientific models requires the ability to express the model in familiar mathematical notation . For example partial differential equations (pde) need mathematical input for the equations themselves, the boundary conditions, and initial conditions . Graphical definition of the solution region is also required, together with interactive grid generation . Smalltalk's interactive graphics interface allows a straightforward means to support user input for scientific problems . We have developed a user problem specification system that accepts on-screen graphical definition of the geometric region of interest . The user can specify the pde's to be solved in the interior, the initial conditions, boundary conditions to he applied over various segments, and the discretization (gridding) . Under development is a more flexible mathematical font input system, and grid generation system . Modeled after Mathscrihe [4] and equation editor tools like those available for the Macintosh, this input sub-system will allow the user to enter equations in a familiar form, provide context editing for the input equations, and provide access to an algebraic manipulation system such as Mathematica or Views [5]. The output of this "problem expression" subsystem is a complete problem specification in a format appropriate for the automatic program generation sub-system or a Smalltalk based solution system . 2 .2 Automatic programming

One of the serious roadblocks to rapid prototyping in traditional scientific computation environments is the need for the user to do "computer programming", e .g. Fortran programming. Engineers and scientists should be free to concentrate on the physical problem, not on detailed programming issues . The combination of tedious edit-compile-link-run processes typical of traditional Fortran programming, together with commitment to large source code programs fosters a static computing environment, not the changing environment needed for experimental prototyping. There have been attacks on this problem for special classes of pde's, e .g. Ellpack [3]. We have developed a general automatic programming system . This system (called AGNES [9]) accepts user input in the form of the set of pde's to he solved, the appropriate boundary and initial conditions, the geometric region, etc . AGNES converts this input information to a program source code (C at this time) after doing consistency and error checking . The generated program employs either user defined or default solution methods (various finite difference methods are implemented and spectral methods are in progress) . The system then compiles the program, runs it, and presents the results graphically . AGNES is implemented in object-oriented Prolog and C . It can handle various classes of pde's, ode's, and algebraic systems . AGNES details can be found in the literature [6,7,8] . AGNES can be coupled to a Smalltalk system, or it can exist as a stand-alone system . Because Smalltalk is well suited as a simulation environment, an alternative approach is to use a "physical" (as opposed to general pde) approach, that is deal with conservation properties as the basis for problem representation and solution. Traditional tools for analyzing fluid dynamics problems have required that CFD problems be reduced to a single pde . The mathematical manipulation required to perform this reduction is both tedious and error prone . As a result, systems which are architectured in this manner tend to be useful only for a single, narrow class of physical problems, thereby discouraging repeated



R .L . Peskin et al. / Smalltalk

374

reformulations of the physical system . In addition, the reduction of the physical problem into a single pde may lead to non-physical behavior . Current work is involved in bringing two separate ideas together to eliminate the problems mentioned above . The first portion of the work involves the implementation of a more physically-based system based upon three generalized physical relations : a density relation, a current relation, and a conservation law . This provides an automatic framework in which to formulate CFD problems . The second portion of the work involves the implementation of the system described above in an object-oriented environment . Through the creation of some Smalltalk-80 classes which respond to both computational and graphical messages, the environment allows the user to specify a physical system, solve it, and then view it interactively . The object-oriented approach provides a framework to incorporate computational steering as well as a way to deal with the parallelism inherent in the problem . The recent work of Balaban et al . [16] has investigated the use of an alternate equation formulation approach, based upon a generalised conservation law for physical systems . Of course, not all systems conform to this law but Balaban et al . have enumerated broad classes of problems amenable to this type of problem-solving . The framework of this system is based upon observables (u), densities (d), currents (f), and sources (s). The above quantities are all functions of time and space and are related to one another via three equations : the current relation (A), the density relation (B), and the conservation law (C) . These three relations define the physics of the problem being modelled . The conservation relation can be applied to a problem domain to generate the partial differential equation (pde) equivalent . For example, for the heat equation, the three relations are : A : f=-kvu

B : d=c,,u C: s=div(f, d)

= et c„u-V kpu The final relation expresses the pde in terms of the observable, u, (in this case, the temperature) . The conservation relation (C) is applied over a number of subdomain "cells" which define the problem domain . The appropriate forward, central, or backward differencing schemes are substituted for the operators in the conservation law to generate a local matrix relation for each cell . These equations may be combined to generate a global matrix relation for the entire problem . In this way, the automatic programming system is flexible enough to develop explicit or implicit differencing schemes . The object-oriented paradigm fits into the above structure quite well . A prototype Smalltalk system is currently being developed which exploits the features of object-oriented programming to implement the automatic programming system described above . This forms the basis for a computational environment in which a user may create Smalltalk objects corresponding to subregions and send various methods to them for discretization, solution and displaying of the solved field. The classes should be augmented with the classes Term, ScalarFunction, and VectorFunction, each of which provides protocols for moulding the conservation law from the representation of the observables along a face . In addition to the manipulation and computation methods listed



R .L. Peskin et at / Smalltalk

Object subclass : #Grid

375

"∎ Finite Difference Grid Class"

Grid instance methods : subdivide

Grid subclass : #Cell

-> subdivides the grid interactively

"Lowest Geometric Subdomain"

Cell instance methods : integrateSurface -> integrate flux over a cell surface

Cell subclass : #Face

"A Call Face Class"

above, the classes Grid and Cell respond to the graphical methods described in Section 1 .3. A typical workspace session to solve the heat equation might be : aGrid aGrid aGrid aGrid

<- Grid new . subdivideEvenly : (HeatEquationCell class) . setBoundariesTo : 1 .0 and : 0 .0 . setICTo : 0 .0 . morphismA . "perform current relations' morphismB . "perform density relation" morphismC . "perform conservation laws' applyConservation . "compute relational matrix"

aGrid acrid aGrid aGrid aGrid solveSystem . acrid display .

The encapsulation and inheritance aspects of the Smalltalk environment allow the user to concisely and simply state the desired chain of behavior . In addition, the structure inherent in this design allows for logical and efficient subtasking of the computational work . The system therefore permits logical computational blocks to be dealt to processors in a parallel processing environment .'Also, because of dynamic binding of the Smalltalk code, the model above may be changed at every step in the chaining process . This represents a powerful computational steering paradigm . 2 .3 Graphical visualization

The key to effective rapid prototyping is a combination of fast means to alter the model and immediate visualization of the results . Smalltalk's tightly bound computation to graphical interface is ideal for presentation and manipulation of graphical results . Smalltalk has a





3 76

R.L . Peskin et al. / Smalltalk

Model-View-Controller paradigm . The Smalltalk system is fundamentally a concurrent process

system (although implemented to date on single processors) . As such there is a mechanism for registration of process dependencies . The system uses this for a number of its own utilities (screen updates, browser views, etc .), and it is available for use by application programs . In a typical case, the Model (the data set and/or the calculations to generate data), has one or more registered Views (graphical representations) . The View typically knows to change itself when the model changes . The Controller (keyboard, mouse, etc .) is known by the View or Model, or both, allowing the user to interact via a controller with the Model and View . The Model-View-Controller paradigm allows direct coupling of the user's model, a set of graphical views of that model, and the interpretation of user manipulation directives via mouse and keyboard . We have implemented a general graphics display and manipulation capability in Smalltalk . The data to be plotted is treated as the model . This allows transparency to the data

~i ~ to~tt>>~~~

[

Fig . 1 . Smalltalk screen showing graphics utilities . Clockwise from top : a Model (LogisticEquation) in xytool format ; Contourtool ; Surfacetool ; xytool running a phase plot .

R.L Peskin et at / Smalltalk

377

Fig . 2 . Spreadsheet on a domain decomposition problem . Each cell is computing a region of the problem's physical space. Initial conditions are shown in the graph at top left . The final computation at each subdomain is shown at the bottom left. The solution as reconstituted from the cells can be viewed and manipulated in the tool shown at the right .

source, which can be produced on the local workstation or come via file stream from a remote source . The user has complete freedom to re-scale, rotate, and otherwise transform the graphical view, as well as manipulate line styles, colors, annotation, etc . This graphics system exists as a "standalone" tool, and its methods are available to be called by other Smalltalk programs, such as those involved in computational steering . In the present iteration, we are working off a ubiquitous class, DataModel, which is directly subclassed off Object but which knows how to access and arrange (store) items which it will treat as data in a variety of formats (e.g. unary indexable collections, matrices, etc .) . This structuring makes it convenient for a computational model to request a variety of graphic representations of itself without having to organize itself first into a variety of formats. Thus, a computational model generating values into a matrix (z at xy), can be viewed and manipulated as a surface, a contour, or as any combination of 2d plots (zx or zy), scatter diagrams, bar charts,. etc . Fig. 1 shows a sampling of the current graphing utilities in their controlpanel views . A Model-View-Controller "spreadsheet" graphical interface has been fashioned for tracking the behavior of a group of computation objects whose methods require concurrent processing. Basically, a set of integrated views is opened on a "matrix" of models . Computation objects (the models in the cells) have access to the full repertoire of graphic visualization described above and can also display icons or flash text messages to indicate something about their status . In addition, the user can open another view, with a control panel on a cell object, so as to manipulate the view interactively . Fig . 2 shows a spreadsheet on a 2 X 2 matrix object in which four computational objects have selected surface plot display methods . The figure also illustrates



378

R.L Peskin et at / Smalltalk

how the matrix object (the model that invoked the spreadsheet) has opened up a control panel view on itself as well . In this illustration, the matrix object is a domain decomposition problem [151 . Each cell of the matrix has opened a view on one of the subdomains as its model . As the subdomain computations progress, they update their views, which represent their solution at the time for their region of the problem space. (To make this clear, we are showing the initial state of each cell as well) . When all the cells have completed their work, the "composite" result is retrieved and featured as a complete surface in the auxiliary graph . 2.4 Computational steering

Ideally the user doing prototyping wants to be able to make in situ changes in his model during computation . Such a capability is very difficult (if not impossible) under traditional computational procedures . There is more involved than just alteration of parameters ; there may be need to make significant changes to the model (i .e. equations themselves) . The NSF Visualization Report [10] has indicated the need for this capability . We have been able to implement such computational steering in Smalltalk. Typically the user can start a computation with a given model, allow it to proceed for a while, and then stop it, make model changes, and continue . Critical to the use of this steering is the Model-View-Controller capability together with dynamic (run-time) binding . Presently we depend on user access to the model equations as written in Smalltalk . Using the graphics classes described above, we have implemented examples of computational steering in Smalltalk, based on the so-called "logistic equation" and on a nonlinear oscillator . The models are subclassed off DataModel so that the visualization apparatus (including the control mechanisms) is simply inherited by the new computation model's view . The user adds specific computation and initialization methods which are automatically tied in with the visualization and control methods of the control panels which reference the subclass's own manipulation methods . To run a model so instrumented, the user indicates the length of time or number of iterations he wishes to test and allows it to proceed for that period or stops it spontaneously . In the current iteration, we are using the Smalltalk "notifier-debugger" paradigm to directly edit the Smalltalk method . Because of dynamic binding, the history (context) in which the original version of the method functioned, is accessible to the new version of the method as its context . Fig. 3 illustrates computational steering on the nonlinear oscillator . In the view on the left, we see the result of running the model using a computation method that includes the term `M'. Since we ran the model with the edit option, a prearranged halt has been triggered and a debugger editing window has popped up . Suppose we want to see the effect of replacing the term M with the operation cosine M . We edit `M' to `cos M' and tell the view to proceed . The resulting graphic view displays the complete computation in its full history, rescaled to the new total range, and clearly showing the impact of the change in computation method . In subsequent iterations we expect to edit the computational method by manipulation of its terms in mathematical notation directly . 2.5 Computational power

A prototyping system useful for real problems must address the need for computational power. Increasingly this means parallel computing . Thus, we must consider (a) how well



R .L. Peskin el al. / Smalltalk

379

osc a Change Mfatto nonga6Fatto :)hrtlahn>ac

eatAbyData sotxbyUser

------------

geOFCCto Icnangzb_ t

sotxh yoata .atxe yuser

ddItgrid .ddxdda

eos -

5.0 55 1s5

-3 55 6 .75

3 .76

dal

6 .5

9 .25

12 .5

18.25

24 .0

12 .0

and.

Oscillato Object Ma Tr >cOmpdOL%_, getMn.t ... tie mtector Index • x . I to : anlnt.ger do: do Ch. requested o h.n l• (A` ((M)rai.edTo : [dI V •2 6)) . L sNnrmal

`M-L-

getMtacta . dr. c tdr Ind .. • x . I n : anlnteger do: do the requested chunk •

retrieve

rabadyd : d)) . L I .NOrma Ifaba; [ computation e4 /L1 put : L.

c omputation a S .11 datap

enln, . apolnt

computation at : put : r . .If

up

ordandCoueot ion (3e6*606 37.017. 0..47 .

M Ind . . A

Fig. 3 . Computational steering in Smalltalk . The term M in the computation method is changed to M cosine and the computation is continued . The change is made interactively, recompiled in situ and the view (on the right) records the change dynamically.

Smalltalk can express problem parallelism, and (b) Smalltalk in the parallel computing environment . Smalltalk is very well architectured for concurrent computing . Viewed as a virtual machine, it is able to support interprocess communication in shared address space, and its process spawning can support blocked and non-blocked process creation . In particular, the concept of futures [11] where a process forks a new process, creates a "slot" for the return, and then proceeds, has been implemented in Smalltalk . With futures, any Smalltalk program can be easily made into a concurrent program. Of course, appropriate concurrency is still problem specific . Smalltalk code executes via a byte-code interpreter, which supports its dynamic binding . While this performs slower than machine code per se, there have been tremendous improvements in Smalltalk performance, and new hardware concepts offer even greater speed [12] . However, for scientific prototyping, means are needed to introduce run-time concurrency . Our approach has been to allocate parallel computer resources to the computationally intensive procedures . Using Smalltalk's access to underlying system calls and machine primitives [13], one can direct numerically intensive computation to remote (i.e. networked) resources, such as a parallel



3 80

R .L .

Peskin el a1 . / Smalltalk

Table 1 Transformation of 6400 xyz floating point numbers by 4x4 matrix . Systems

Smalltalk alone

Smalltalk with C Primitive

ArdentTitan Tektronix 4317

55810 milliseconds 81657 milliseconds

560 milliseconds 1000 milliseconds

computer . The semantics of futures is used to support this . Thus an object needing, for example, a matrix inversion, would request this of a powerful remote resource and continue other work while waiting for the return . We have implemented machine level enhancements to Smalltalk using two distinct models . In one case, we have implemented certain matrix multiplication operations as primitives, and these are then used to accelerate three-dimensional graphics operations . In one case, we are using an Ardent Titan (2 processor) system . By allowing the matrix operatoins to be done by the Titan's vector processors, we can effect significant speedup . In a similar experiment, we have implemented these same primitives using a Tekronix 4317 system, single processor MC 68020 ; significant speedup was also found . Table 1 shows the speedup results for these two cases . In both of these cases, code that would otherwise be performed by the Smalltalk interpreter is, instead, performed at the machine level with the results returned to Smalltalk . Another approach to performance improvement under Smalltalk is to assign the "futures" classes to parallel computer resources, either a separate co-processor, a separate machine, or separate processors tightly coupled to the Smalltalk interface facilities . In one experiment we are assigning certain class methods to be performed on a BBN GP1000 parallel computer . We have established a network socket interface between the Smalltalk workstation (Tektronix 4317) and the BBN . Again, computational requests that would be slow under Smalltalk's interpreter are sent to the BBN facilities, and the result returned to Smalltalk . In essence, Smalltalk is "managing" the computation tasks, but the repetitive work is done by the parallel computer . These approaches are but several of the possibilities to integrate Smalltalk and parallel computing [14] . While performance was a problem with earlier Smalltalk systems, and may have prevented the consideration of Smalltalk by the scientific community, modern Smalltalk with its machine level access capabilities will allow serious scientific and engineering prototyping and simulation.

3. Conclusions The need is present for modern software environments to allow rapid prototyping and experimentation in the scientific and engineering domains . While one can argue about which language and environment approach is best for this, it is more important to move forward to develop the needed capabilities. Smalltalk presently meets, or can be made to meet, many of the important requirements for an interactive scientific software system. Its natural coupling of computing and graphics is a critical necessity in any modern scientific system . Its dynamic binding allows true computational steering via interaction with intermediate graphical output . This allows interaction with the intermediate computation, not just via the post-processed



R .L. Peskin et al. / Smalltalk

381

graphics . Coupled with new automatic programming systems, Smalltalk has the possibility to become a true interactive numerical laboratory software environment. Smalltalk's capability to interface to the "outside world" will permit not only efficient computation via access to high speed machine capabilities, but also access to existent software written in other languages. In summary, Smalltalk offers a powerful environment for scientific and engineering prototyping. Its syntax is simple, yet complete . It is easily extended to include necessary scientific data types . Its tight coupling to graphics eliminates a major bottleneck characteristic of more traditional environments . Current efforts at improved performance, both intrinsic and via coupling to parallel computers are yielding the requisite run-time performance . It is a different concept for scientific computing, but perhaps it is time for a different concept .

References [1] A. Goldberg and D. Robson, Smalltalk-80 (Addison-Wesley, Reading, Mass ., 1983) . [2] L.J. Pinson and R .S . Wiener, An Introduction to Object-Oriented Programming and Smalltalk (Addison-Wesley, 1988) . [3] JR. Rice and R .F . Boisvert, Solving Elliptic Problems Using Ellpaek (Springer-Verlag, N .Y., 1984) . [4] MathScribe User's Manual, Tektronix Corp . (1988). [5] S .K. Abdali, G .W . Cherry and N . Soiffer, An object-oriented approach to algebra system design, Proceedings of Symsac, ACM (1986) . [6] M .F . Russo, R.L. Peskin and A .D . Kowalski, A Prolog based system for partial differential equation modeling, Simulation 49, 4 (Oct . 1987) . [7] A .D . Kowalski, R .L . Peskin and M.F. Russo, An expert system for modeling fluid and thermal problems in Proc. 2nd Inter. Conf. on Applications of Al in Engineering (D. Sriram and R. Adey, eds .) Boston (1987) . [8] R.L . Peskin and M .F. Russo, An object-oriented system environment for partial differential equation solution, 1988 ASME Inter_ Computers in Engineering Conf., San Francisco, (Aug . 1988). [9] A .D . Kowalski, MY. Russo and R .L . Peskin, Anatomy of AGNES : An automatic Generator of Numerical Equation Solutions, Conf on Expert Systems for Numerical Computing, IMACS, Purdue . U . (December. 1988) . [10] B . McCormick, T . DeFanti and M . Brown, Visualization in Scientific Computing, NSF Report on Grant ASC-8712231 (July, 1987) . [11] R . Halstead, Multilisp : A language for concurrent symbolic computation, ACM Trans. on Programming Languages and Systems, ACM (1985) . [12] D .M. Ungar, The Design and Evaluation of a High Performance Smalltalk Svstern (M .I.T . Press, 1987) . [13] Tektronix Smalltalk Reference Manual, Tektronix Corp . (Nov. 1987). [14] A . Yonezawa and M . Tokoro (eds .) Object-oriented Concurrent Programming (M .I .T . Press, 1987) . [15] J.R. Rice and Dan C. Marinescu, Analysis and modeling of Schwartz splitting algorithms for elliptic PDE's, Advances in Computer Methods for Partial Differential Equations, R. Vichnevetsky and Stepleman (eds .) (IMACS, 1987) . [16] D . Balaban, J . Garbarini, K. Olwell, W . Greiman and S. Shlaer, On the relational modeling of discrete PDE problems, Proc. Int . Sym . on AI Expert Systems and Languages in Modeling and Simulation, I MACS, Barcelona (North-Holland, 1987) .