Improving Computer Algebra Systems by Using Grid Services Dana Petcu Abstract. Symbolic and algebraic computations are one of fastest growing areas of scientific computing. Ithas been previously proved that Computer Algebra Systems can benefit from the achievements in the field of distributed computing. More recently Grid computing has attract the attention of the system developers. After an overview of the state-of-the-art in Grid-enabled systems for symbolic and algebraic computations we present a case study involving Maple.
1. Introduction Continuous growth in the capabilities of computer hardware led to an increasing interest in symbolic calculations and resulted, among others things, in development of sophisticated Computer Algebra Systems (CASs). Symbolic computation is also becoming a basis for advanced applications in many areas of computer science, such as computer aided design or software development, VLSI design, geometric modeling and reasoning, robot programming etc. Lists of existing CASs can be found in [3, 22, 23] and their facilities were compared in [2, 28]. As CASs become capable of solving large problems, they follow the course of development that has already been taken by numerical software: from sequential computers to parallel machines to distributed computing and nowadays to the Grid. It is particularly the Grid that has high potential as a discovery accelerator. Currently, its widespread adoption is still impeded by a number of problems, one of which is difficulty of developing and implementing Grid-enabled applications. After a short review in Section 2 of the initiatives concerning Grid-enabled CAS, we present in Section 3 a case study involving a well-known CAS, Maple.
2. Grid-aware Computer Algebra Systems Many users utilize CASs as tools performing “small scale” mathematical calculations that would be tedious and error-prone when performed by hand. For them, those systems running on a single processor computer are quite satisfactory. However, there exists a class of users who employ CASs to solve large and very large problems. Here, the solution to the problem may involve, for instance, large scale symbolic computations requiring a significant amount of computational resources, or a combination of symbolic and numerical computations used in the context of multivariable simulation (the CAS environment becomes an “interface” to a set of computational kernels). Institute
e-Austria Timis¸oara, Romania and Computer Science Department, Western University of Timis¸oara, Romania, email:
[email protected]
While, typically, CAS systems are utilized in an interactive mode, to solve large problems they can be also used in a “batch” mode and programmed using languages that are very close to common mathematical notation. It is a well known fact that developing completely new parallel or distributed systems, although efficient, in most cases is rather difficult. An alternative approach is to add parallel or distributed facilities to an existing system. Several parallel and distributed CAS versions have been developed this way, but based on different requirements and targeted for competing parallel architectures. An overview of these versions is presented in [24]. The usual topics for parallel and distributed symbolic computations are: 1. multiprecision integer arithmetic – for example, factorisations, multiplication, exponentiation; 2. polynomial arithmetic – for example, greatest common divisor, differentiation, Gr¨obner basis; 3. solving linear and nonlinear equation systems. CASs increase their utility not only through adding new symbolic capabilities, but also by expanding their reach through adding new functionalities, such as visualization or numerical modules. While memory-bound algorithms are clearly the most important driving force for the development of parallel CASs, this change poses a need for addressing the parallelization of processor bound tasks. As examples of such tasks we can mention the rendering of images for an animation illustrating the evolution of a system or a multivariable simulation illustrating the solution space of an optimization problem. In these cases, all of the typical problems involved in parallelization of numerical computations appear also in the context of parallel or distributed CAS. In number theory there exist a number of successful Internet projects [14] aiming, among others, at finding large prime numbers, factoring large numbers, computing digits of π, finding collisions on known encryption algorithms etc. A CAS web-wrapper component that can be used by multiple systems was reported in [26]. Here, shared-memory parallelism was used to speed up Gr¨obner basis computations. Another online system for Gr¨obner basis computations, OGB [9], has been recently deployed. MapleNet [15] is a software platform to enhance mathematics and related courses over the web. The client uses only the Java virtual machine. To access web pages and the applets associated with them users will connect to the server. The server manages concurrent Maple instances launched to serve client requests for mathematical computations and display services, and facilitates additional services such as user authentication, logging information, and database access. Similarly, webMathematica [27] offers access to Mathematica applications through a web browser. A framework for description and provision of web-based mathematical services was recently designed within the Monet project [16]. Its aim was to demonstrate the applicability of the semantic web to the world of mathematical software. The key to such a framework is the ability to discover services dynamically based on published descriptions which express both their mathematical and non-mathematical attributes. A symbolic solver wrapper was designed to provide an environment that encapsulates CASs and expose their functionalities through symbolic services. Maple was chosen for the computing engine in the initial implementation, and Axiom was used to demonstrate the ability to incorporate different computational engines without major changes. 2
Currently there are several on-going Grid-oriented projects involving CASs. Open source package NetSolve [1] was one of the earliest Grid systems developed. It is a middleware between desktop systems equipped with simple APIs and the existing services supported by the Grid architecture. One of the goals of project is to create a system capable of integrating arbitrary computational resources. APIs are available for Matlab, Mathematica, and Octave. The version released in 2003 introduces GridSolve, a client-server-agent system that enables users to solve complex scientific problems remotely using distributed resources on the grid. At the present time, proxies for Globus and Condor-G are available. The Grid Enabled Numerical and Symbolic Services [7] project, Genss, was initiated in 2004 and follows the ideas formulated in the Monet [16] project. The latest one has designed a symbolic solver wrapper to provide an environment that encapsulates CASs and expose their functionalities through symbolic services. GENSS intends to combine Grid computing and mathematical Web services using a common open agent-based framework. Thus far research was focused in two areas: matchmaking techniques for advertisement and discovery of mathematical services, and design and implementation of an ontology for symbolic problems. HPC-Grid for Maple [13] is a distributed computing package using Maple that allows users to distribute computations across the nodes of a network of workstations, a supercomputer or across the CPUs of a multiprocessor machine. It offers an MPI-like message passing API as well as a set of high-level parallelization commands. HPC-Grid also integrates into existing job scheduling systems like PBS. gridMathematica [10] was constructed as a parallel computing solution for dedicated clusters facilitating parallel computing within Mathematica, requiring only TCP/IP connectivity. MathGridLink [25] is a software component designed to act as a middleware between Mathematica and the Grid. It allows both the development and deployment of Mathematica computational services on the Grid and the usage of existing Grid services from within Mathematica. Gemlca [12] is a recent solution to deploy a legacy code application as a Grid service without modifying the code. The Gemlca front-end, described in WSDL, offers Grid services to deploy, query, submit, check the status of, and get the results back from computational jobs. In order to access a legacy code program, the user executes the Grid service client that creates a code instance with the help of a code factory, and the system submits the job to the compute server through Globus. Other on-going project are mentioned in [5, 6, 8, 11, 18, 29]. An overview can be found in [21]. In order to illustrate in more detail issues involved in porting CASs to the grid we present a case studies based on ongoing research projects involving Maple.
3. Case study: Maple-to-grid A grid-aware CAS system must have at least one of the following facilities: Ability to accept services from the Grid: the CAS must be capable to augment its facilities with external modules, in particular it should be able to explore computational Grid facilities, to connect to a specific Grid service, to use it, and to translate its results for the CAS interface. This approach is taken into consideration by the Geodise, NetSolve/GridSolve. 3
Being a source of Grid or Web services: the CAS or some of its facilities must be reachable as grid or web services and allowed to be activated by remote users under appropriate security and licensing conditions; furthermore, deployment of the services must be done in an easy way from the inside of the CAS. This approach is taken into account by the Genss project. Ability to communicate and cooperate over the Grid: several kernels of CASs must be able cooperate within a Grid when solving problems; in order to have the same CAS on different computational nodes a Grid-version must be available; in the case of different CASs, appropriate interfaces between them must be developed and implemented or a common language for intercommunication must be adopted. In order to illustrate in more details the issues involved in porting CASs to the Grid we present one case study based on an ongoing research project involving Maple – Maple2g (Maple-to-Grid) that allows the connection between Maple and computational Grids based on the Globus Toolkit. Its design principles were described in [19]. The prototype consists of two parts – a CAS-dependent and a grid-dependent one: 1. m2g, the Maple library of functions allowing the Maple user to interact with the Grid/Cluster middleware, 2. MGProxy, the middleware, a package of Java CoG classes, acting as interface between m2g and the grid environment. Maple2g has three operating modes:
¯ user mode for accessing Grid-services; ¯ server mode for exposing Maple facilities as Grid services; ¯ parallel mode for supporting Maple kernels cooperating over the Grid. We discuss here the benefits of the first operating mode. The third mode was presented in [20]. Figure 1 indicates the technologies used in the process of grid-enabling Maple: Globus Toolkit, Java CoG, mpiJava [17] and MPICH-G2. The procedural steps to communicate within the Grid starting from the user’s Maple interface are the followings: 1. Activate MGProxy. User commands in Maple syntax, parsed within the m2g package, initiate the communication with the middleware which acts as an intermediary between Maple and the grids. This is performed via the commands for external code invocation. 2. Grid services invocation. The user invokes a local client of a Grid service by issuing commands in RSL syntax. 4
Figure 1. Technologies used in Grid-enabling Maple
3. Job submission. MGProxy activates a Java class that deals with the submission over the Grid. 4. Results retrieval. Results can be requested before or after the job completation. Table 1 presents the m2g functions allowing the access of Grid services within Maple. Table 1. M2g functions enabling Maple to use Grid services
Function Description m2g connect() Connection via Java COG to the Grid m2g getservice(c u l) Search for a local client of a Grid service named by the string c in the directory specified by the string u, and retrieve the results in the list l of RSL strings. Wildcards can be used in the string c. m2g jobsubmit(t s) Based on the client RSL string s, perform a job submission labeled t m2g jobstop(t) Stop the job labeled t m2g status(t) Queries the status of the submitted job labeled t m2g results(t) Retrieve the results of the submitted job labeled t m2g MGProxy start() Start the MGProxy m2g MGProxy end() Stop the MGProxy and the Grid connection
4. Examples In order to confirm the results obtained in the first series of experiments presented in [19] and [20] we considered three other scenarios. 4.1. A simple example This first example presents the steps performed to invoke a Grid service. We use a sample examples included in Globus Toolkit 4: Counter. It contains a CounterService and counter client. CounterService has two key operations. The first one, createCounter is used to create a new counter resource and return the end point reference of the resource in a file. The second one adds a value to the specified 5
counter resource. CounterService is deployed into the container during the installation process by default. The example provided in Appendix uses the client programs counter-create and counter-bin to try the CounterService. The clients arguments are described in RSL strings that are retrieved by m2g getservice in this example from files located in the home directory. Before launching any service request, the Grid connection must be established using m2g MGProxy start and m2g connect. The client credentials are retrieved from local files. The service resource (the counter) is created by the CounterService when the firstJob is submitted. The file access.epr will contain the end point reference of the Grid service instance. The job status is checked using m2g status. The secondJob and thirdJob are adding the value 3 to the counter. Their results are retrieved to the Maple environment. Finally the connection to the Grid environment is interrupted. 4.2. Faster arbitrary precision arithmetic by accessing grid services Maple works with large integers, which make it useful, among others, in applications involving encryption/decryption. Its multiplication algorithm is a fast one, but still there is a limit as to how large are the two numbers that can be multiplied and how fast this goal con be achieved. We consider the example of multiplication of two large integers consisting of 40 million decimal digits. The Maple code: > #Maple code: time to multiply 2 big integers > i:=27: a:=2ˆ(2ˆi)-1: > t:=time(): a*(a+3): print(time()-t): When Maple 9.5 is used, the multiplication (using the Sch¨onhage-Strassen algorithm) cannot be performed: an error occurred, caused by the recursive nature of the algorithm. Maple 7 uses the Karatsuba algorithm which is slower in the case of such big numbers (experimenting on a PC 1.4MHz with 512GHz with i 25, Maple 9.5 needs 9 seconds instead Maple 7 which needs 770 seconds); but it requests four times smaller memory, so the above computation will not stop and will run for several hours. A solution to overcome this limit of Maple is that of using an appropriate grid service which can complete the multiplications. For testing purpose we have selected the CLN package [4], a C++ library, which allows computations with integers with unlimited precision and which uses the Sch¨onhage-Strassen multiplication for integers larger than 12 thousands decimal digits. For the above example: #include using namespace cln; int main() { cl_I i=(cl_I)1 m2g_MGProxy_start(); Grid authorization checked > m2g_connect(); Grid connection established > m2g_getservice("counter*",".",‘serv‘); [‘&(executable=$(GLOBUS_LOCATION)/bin/counter_create) (arguments="http://194.102.62.30:8080/wsrf/CounterService >$1") (count=1)(directory=/home/dana) (stdout="$(HOME)/out.$(PROCESS)")(stderr="$(HOME)/err.$(PROCESS)") (* $1 is an output file for the EPR of the service*)‘, ‘&(executable=$(GLOBUS_LOCATION)/bin/counter_add) (arguments="-e >$1 $2") (count=1) (label="subjob0") (directory=/home/dana) (stdout="$(HOME)/out.$(PROCESS)")(stderr="$(HOME)/err.$(PROCESS)") (* $1 is an input file containing the EPR of the service*) (* $2 is the value to be added*)‘, ‘&(executable=counter) (count=1)(directory=/home/dana/) (stdout="$(HOME)/out")(stderr="$(HOME)/err")‘]; > client1:=StringTools[SubstituteAll](serv[1],‘$1‘,‘access.epr‘); client1=&(executable=$(GLOBUS_LOCATION)/bin/counter_create) (arguments="http://194.102.62.30:8080/wsrf/CounterService access.epr") (count=1)(directory=/home/dana) (stdout="$(HOME)/out.$(PROCESS)")(stderr="$(HOME)/err.$(PROCESS)") (* $1 is an output file for the EPR of the service*) > firstJob:=m2g_jobsubmit(1,client1); Job 1 submitted > m2g_status(1); ACTIVE > m2g_status(1); DONE > m2g_results(1); > client2:=StringTools[Substitute](serv[2],‘$1 $2‘,‘access.epr 3‘): > secondJob:=m2g_jobsubmit(2,client2); thirdJob(m2g_jobsubmit(3,client2); Job 2 submitted Job 3 submitted > m2g_results(2); 3 > m2g_results(3); 6 > m2g_MGProxy_end(); Grid connection closed
10
