Maria Lin and David W. Walker. School of Computer Science, ..... especially Yu Chen and Jason Jones of the University of. Wales, Swansea who developed the ...
1
A Portlet Interface for Computational Electromagnetics on the Grid Maria Lin and David W. Walker School of Computer Science, Cardiff University 5 The Parade, Roath, Cardiff CF24 3AA, United Kingdom Abstract - Grid-enabled portals are becoming increasingly popular for scientific collaboration. Specifically, a portal can be viewed as a Grid-based problem-solving environment (PSE) that allows scientists to access distributed resources, and to monitor and execute distributed Grid applications from a Web browser. This paper describes the Grid-enabled GECEM portal, which serves as a web gateway to computational grids to access remote data files and remote grid services. The portal allows trusted users seamless access to computational resources and grid services, providing a userfriendly computing environment that takes advantages of the underlying Globus Toolkit middleware. The portal is built on GridSphere, which provides support for Grid-based computing. We have developed portlets to retrieve data, invoke grid services, and monitor job submission. We will demonstrate the use of GSI security, the resource registry, and credential management to support secure job submission. We also demonstrate the use of grid services to support migration of executables to remote sites. In this paper, we will present our experiences of developing our portal using GridSphere. We will present both ongoing work and planned future work for the project. The portal has been applied to electromagnetics; however, it can also be applied to other application domains. Keywords— Computational Electromagnetics, Portlets, Grid Services. I. I NTRODUCTION
In this paper we present the design and implementation of the Grid-Enabled Computational Electromagnetics (GECEM) portal. This work significantly extends that previously presented [WAL 03] by moving from a script-based approach using Globus Toolkit 2.0 to the development of a portal that interacts with Open Grid Service Architecture (OGSA) services using Globus Toolkit 3.2 1 . Computational electromagnetics (CEM) is of increasing importance to the civil and defence sectors. It is central to important problems such as predicting the electromagnetic compatibility between complex electronic systems, and the response of systems to lightning strikes and electromagnetic pulses. These issues are of key concern in possible future platforms such as the More Electric Aircraft (MEA) and the All Electric Ship (AES). Large-scale CEM simulations are computationally intensive, and can involve access to resources that are intrinsically distributed. For example, in the case of an ”extended enterprise” in which multiple partners from industry and academia are cooperating to design and build a complex system that requires CEM simulations, the geometry of a 1
http://www.globus.org/ogsa/
component may be created at one location, a mesh conforming to this geometry may be generated at a second location, and a CEM simulation based on the mesh may be performed at a third location. Finally, the output from the simulation may be analysed and visualised at one or more other locations. Grid-enabled computational portals have become a widelyused way of seamlessly accessing distributed heterogeneous resources and of supporting collaboration between project partners. A portal is accessed through a web browser and provides users with a customised view of resources specific to their problem domain. Portals have recently emerged as the de facto standard for web application delivery. A portal may be built using a variety of web technologies, however, a particularly powerful approach that has gained wide popularity constructs portals from pluggable user-interface components known as portlets. From a user’s viewpoint, a portlet is a window in a portal that provides a specific service. A portlet is written in Java and conforms to a portlet API. Conformance with the JSR-168 portlet specification 2 ensures that a portlet will run in any portal that is JSR-168 compliant. A portlet runs in a portlet container that provides a runtime environment and lifecycle management – in our work we use the GridSphere 3 portal framework which serves as a portlet container, and itself runs within a Tomcat container 4 . A portlet handles user requests and generates dynamic content in the form of markup fragments that can be aggregated with other fragments to form a portal page. The new approach presented in this paper involves a number of changes to the earlier work presented in [WAL 03]. 1) We choose to use a portlet approach. 2) We migrate the shell scripts from GT2 to a Java-based method using the API provided by GridPortlets. 3) We build on the GridSphere portal framework. 4) We make use of the portlet service models of GridPortlets to use the Grid resources and to submit jobs. We use the OGSA service-oriented architecture. 5) We create GECEM portlets for getting input geometry files, meshes and solvers. The underlying idea is to use a service-oriented architecture based on emerging standards such as the Open Grid Services Architecture (OGSA). The advantage of using OGSA 2 3 4
http://www.jcp.org/en/jsr/detail?id=168 http://www.gridsphere.org/ http://jakarta.apache.org/tomcat/
is that it allows us to provide users with access to GECEMspecific services without creating individual accounts as required by GT2. Thus, the difficulty with the inflexibility of creating individual user accounts in GT2 is reduced as mentioned in [WAL 03]. This paper is organised as follows. Section II describes the typical mode of use and overall design of the GECEM portal. In Section III a brief overview of Grid security is given, together with a discussion of how a MyProxy credential repository is used in the portal. Section IV goes on to describe in more detail how portlets are used in the GECEM portal. This is followed by Section V in which related work is discussed. Some shortcomings in the current portal design are considered in Section VI. Finally, some conclusions are presented in Section VII. II. D ESIGN OF THE GECEM P ORTAL
The GECEM portal has been designed to support the generation of surface and volume computational meshes using a meshing services at the University of Wales, Swansea, the solution of a CEM problem on the volume mesh with a CEM solver service on a high-end computer at the Singapore Institute of High Performance Computing or at Cardiff University, and the collaborative visualisation of the results by participants at multiple geographically dispersed locations [WAL 03]. The input to the to this type of problem is a file specifying the model geometry which is produced at BAE Systems in Filton, Bristol. The GECEM portal is readily generalised to use services and storage at arbitrary locations by virtualising them through web service technologies. A typical mode of use is shown in Fig. 1. UNIVERSITY OF WALES, SWANSEA
BAE SYSTEMS
Generate meshes
Geometry data
Create geometry
Volume Mesh Output
CEM simulation
CARDIFF UNIVERSITY Output
Output
SINGAPORE INSTITUTE OF HIGH PERFORMANCE COMPUTING
Fig. 1. A typical mode of use of the GECEM grid, with a geometrical model produced at BAE Systems, computational meshes generated at Swansea, and the CEM simulation performed in Singapore. The output is then collaboratively analysed and visualised at all threes ites and at Cardiff University.
The motivation of the GECEM project comes from the fact that resources are intrinsically distributed. In such a situation, the partners in the extended enterprise may be prepared to share data (the geometry, the mesh, the simulation output), but often not the proprietary software systems and the hardware that generate the data (the mesh generator and CEM solver code). Thus, it is not feasible to place all
the data, computer, and human resources in one geographical location. The Grid, therefore, is an excellent candidate for providing the infrastructure needed to support extended enterprises. It should be noted that “extended enterprise” has essentially the same meaning as “virtual organisation” [FOS 02]. The GECEM portal is designed to support a pipeline style of workflow in which the nodes correspond to the surface mesh, volume mesh and CEM solver services. The surface and volume mesh services take as their main input a file specifying the geometry of the problem to be simulated. Geometry files are assumed to be generated outside of the portal, and are stored in a geometry archive that can be browsed and managed within the portal. The surface and volume mesh services output surface and volume meshes, respectively, and these are stored in their own archives. Finally, the CEM solver service takes mesh files as input and generates the solution, which is stored in the solution archive. The GECEM portal allows a user to set up a job as a sequence of one or more services, with specified input and output files. Where multiple equivalent services are available for a particular task, perhaps employing different algorithms or numerical methods, the user can select from these. Having decided which services to use, the input file(s) for a job are selected from the appropriate archive. In the full three-stage workflow an input geometry file is selected from the geometry archive as input for the surface mesh service. The output from this is passed to the volume mesh service, which in turn passes its output to the CEM solver service. The output from this latter service is stored in the solution archive. By default all intermediate outputs from the surface and volume mesh services are archived, so a job could, for example, consist of just the CEM solver service, with the input being selected from the volume mesh archive. A three-stage GECEM workflow is shown in Fig. 2, in which the dashed arrows into the archives show how data sets can be archived. The dashed arrows leading from the archives shows how one- and twostage workflows can be set up using archived input data sets. High quality CEM solver codes often represent significant investments of time and money, and may give a business a competitive edge that would be lost if their codes were assessible to others. Thus, the owner of such a CEM solver code may not want to install it permanently on multiple computers outside of their organisation. The implementation of the CEM solver service takes these considerations into account by securely migrating the code to a selected target machine, together with any necessary input data sets. The code then executes, its output is sent to the solution archive, and the code on the target machine is then deleted, along with any related data sets. Of course, this approach is not entirely secure, but is reduces the risk of an organisation’s valuable software being accessed by unauthorised parties.
Geometry data
Geometry archive
Surface mesh service
Surface mesh archive
Volume mesh service
Volume mesh archive
CEM solver service
Solution archive
Solution data
Fig. 2. A three-stage GECEM workflow
Another important aspect of the GECEM portal is its support for collaborative visualisation and analysis. Multiple distributed users can collaboratively visualise and navigate data sets in the portal’s archives. Two modes of collaborative visualisation are supported: one in which all participants see the same view of the data set as a designated “leader”, and the other in which the participants navigate the data set independently. Participants can interact in realtime during a visualisation session through an audio chat tool. III. S ECURITY
The services accessed through the GECEM portal are based on the Globus Toolkit 3.2 (GT3.2). Thus, the portal makes use of the Globus Security Infrastructure (GSI) for the authentication of users, services, and resources 5 . GSI also provides for ”single sign-on” to Grid resources and the delegation of credentials. Single sign-on refers to the ability of a user to perform a single action of authentication (such as entering a password) to access the distributed resources that he or she is authorized to use. Delegation is a mechanism whereby a user or service can delegate a subset of their access rights to another service.
be sure the message really is from them and has not been tampered with en route. A user’s credentials could be used to authenticate them to services and resources and establish secure communication channels between them. However, this would create a significant security risk since private keys would need to be sent over the network and stored on remote computers. To reduce this risk use is made of proxy certificates which can be issued either by a user, service or resource, or by another proxy. A proxy certificate has a unique identity, is valid for a limited time period only, and contains a new private/public key pair. It is digitally signed by the issuer. This key pair can be used to establish secure communication with the issuer. To validate a proxy certificate the certificate of the issuer must first be validated, which itself may be a proxy certificate. Thus, validation proceeds in a chain all the way back to the entity certificate signed by the CA. A proxy certificate may also contain restrictions on its use, and hence can be used for delegation as well as authentication. B. MyProxy Credential Repository Managing private key and certificate files can be a burden for users, and for inexperienced users may result in errors that compromise security. To alleviate these problems it is simple and convenient to make use of a credential repository that stores a user’s credential files and creates a proxy credential wherever and whenever one is needed. The GECEM portal uses the MyProxy online credential repository managed by the Grid Operations Support Centre of the UK e-Science programme 6 . The GECEM portal makes use of the MyProxy Upload Tool, developed in the CCLRC DataPortal project, to upload a user’s proxy crendentials to the MyProxy repository. The user can choose how long they wish their credentials to be kept in the repository and how long any proxies generated are valid. The user also needs to choose a username and MyProxy pass phrase, which can subsequently be used to log into the portal, effectively giving single sign-on access to the GECEM resources. IV. U SING P ORTLETS IN THE GECEM P ORTAL
A. Grid Credentials A user’s security credentials consist of their certificate and private key. A certificate is used to authenticate an entity, such as a user, service or resource, and contains the entity’s name and public key (amongst other things). The certificate is digitally signed by a Certificate Authority (CA). If you trust the CA and you have the correct public key of the CA, then you can be sure that the public key in the certificate belongs to the named entity. Possession of an entity’s public key allows you to send them encrypted messages (which only they can decrypt with their private key), and to validate messages digitally signed by the entity so you can
The GECEM portal is a problem-solving environment (PSE) composed of a collection of portlets and services. The portal provides the main interface through which services are accessed. The portal supports the composition of applications from service-based components, the execution and monitoring of such applications on remote resources, and collaborative visualisation, exploration, and analysis of the application results. In addition, the portal also provides an interface to meshing services and supports the collaborative visualisation of meshes. The GECEM portal is built using the GridSphere portal framework [NOV 03] and GridPortlets, which were both
5
6
http://www.globus.org/security/
http://www.grid-support.ac.uk
developed by the GridLab team. The advantage of coupling GridSphere and GridPortlets is that they fully support OGSI Globus Toolkit 3.x. In addition, GridSphere and OGSA can be hosted under the same container to allow a portal to host grid services. A user accesses the GECEM portal from a web browser through a secure HTTP connection, and is initially presented with a welcome message, help information about using the portal, the MyProxy Upload Tool, and a login portlet. After logging in using their MyProxy username and pass phrase the user is then presented with two tabbed panes for accessing GridPortlet portlets, and GECEM portlets. When the user logs onto the portal a proxy certificate is downloaded from the MyProxy repository and is stored id the GridPortlets credential manager, which can also be used to download a new proxy certificate once the current one expires. The GECEM portlets lead a user through the steps necessary to set up a GECEM job, initiate its execution, monitor its progress, and examine the output. First the user is presented with a form to select the machine to be used for the surface mesh service, and chooses a surface mesh service from a list of those available on the selected machine The user next selects the geometry file for input to the surface mesh service from a list of such files available on the selected machine. The chosen surface mesh service is then invoked with the selected input. The volume mesh service is handled in a similar way, although the main input file is simply the output of the surface mesh service. The forms that are used to select data files and resources, and initiate execution are, in fact, a set of portlets. The portlet design for GECEM has three main components: resource discovery, file selection, and job submission. These three components are implemented by three main portlets. • The resource portlet allows a user to select a machine in the GECEM grid. The list of machines are hand-edited beforehand in an XML file which is similar to the one in the Grid Resource Registry provided by the GridPortlets web application. This file defines the available services and the machine names responsible for these services.
The data portlet then displays the geometry data files, input files for mesh generation, and input solver files available on the selected machine, and allows the user to select from these to specify a complete job. •
• The job submission portlet will commit the resources and the files selected to access the meshing services and the CEM solver service. The job submission portlet provides a button to invoke a script which will access the Globus Reliable File Transfer (RFT) Service and Job Submission Service provided by GridSphere. The RFT Service transfers files from one location to another using the gsiftp protocol. Both the mesh generation and CEM simulation codes are submitted using the Job Submission Service.
Figure 3 presents the three-tier portal architecture in which
a MyProxy repository is used to supply a proxy that is then managed by the GridPortlet credential manager. The GECEM portlets are then used to select the resources and files needed to execute a job using the backend services. Tier 1
Tier 2
User
MyProxy Repository
Tier 3 Services and resources Surface Mesh Service Volume Mesh Service CEM Solver Service
GECEM portal Archives
Web browser
Fig. 3. Architecture of the GECEM portal.
To run a scenario, the user first selects the resources from the resource portlet, then selects the data files, the meshes,and the solvers from the data selection portlet. The Job Submission Portlet is then used to run the mesher and solver codes. Although the portlets for selecting the input files and services for generating the surface mesh and volume mesh are similar, the portlets for setting up and running the CEM solver service are rather different because the machine that hosts the latter service is not necessarily the one that execution the CEM simulation code. As discussed in Section II, the CEM solver service migrates the simulation code to a remote target machine, where it executes, and sends back its output to the service. The simulation code and related data sets on the target machine are deleted after execution. Thus, in preparing to invoke the CEM solver service we must also select the target machine onto which to execute the simulation code. The progress of the volume mesh and CEM solver services can be monitored through additional portlets that access service data elements exposed by the services. V. R ELATED W ORK
A grid-based problem solving environment is useful for collaborative simulation. As pointed out in the context of the Geodise toolkit [ERE 05], a problem solving environment to assist scientists doing computational electromagnetics has several advantages. Although both GECEM and the Geodise toolkit provide similar functionality for mesh generation and code analysis, the Geodise toolkit has implemented this functionality through Matlab commands, rather than through some other user interface. In Geodise, meshing is performed through a mesh generation tool, while analysis is done through an analysis tool, rather than through grid services. The rationale of using a web portal as an interface is that the web has been an interface for many years. By using a web-based portal, a user can access the portal anywhere and can have an easy-to-use user interface to access these
resources without the need to aware that the resources are distributed. A number of scientific portals have been developed using GridSphere as the portal container. For example, The Virtual Observatory Portal (VO-Portal) [BEE 05] and the PGRADE Portal [KAC 03]. The VO-Portal provides an interface for job submission and job monitoring, so that scientists can execute an application through a web browser. However, the portal does not integrate any grid application services. Our approach is more customised to the user requirements of our industrial partner. However, it should be straightforward to migrate the same approach to other applications. The P-GRADE portal supports workflow and job migration. In addition, it provides a high-level graphical environment to generate PVM, MPI or GAT code according to the actual execution platform. It also supports interactive execution of parallel programs. It would be interesting to investigate if P-GRADE and GECEM can be integrated together. The GEMLCA project [DEL 04] addresses the issue of exposing legacy codes as Grid services, and provides a way of exposing and executing legacy applications through an OGSI Grid Service. As pointed out in [KAC 04b], a wrapping approach has the disadvantage of requiring access to source code and may require modification of the original legacy source code. In addition, the wrapping process is not entirely automatic, so considerable user effort may be required if the process needs to be applied to many legacy codes. In [KAC 04a], [KAC 04b], GEMLCA has taken a further step to create a general solution to deploy existing legacy code applications as Grid services without modifying the source code by creating a front-end Grid service layer. To access a legacy code program, the user executes the GEMLCA Grid service client that creates a legacy code instance with the help of the legacy code factory. The GEMLCA software has been integrated with a P-GRADE portal, which allows the user to construct and execute workflows from legacy codes deployed as OGSA Grid services.
At the time of writing, the archiving of intermediate data sets has not yet been fully implemented, and users must still move files around manually,or using the GridPortlets Reliable File Transfer Service. The aim is for users to be able to place their data sets into archives for different types of data (geometry files, surface and volume mesh files, and simulation output files) and assign to each read and write permissions similar to those found on Unix systems. We are currently updating the service discovery mechanism used in the GECEM portal to make use of the UDDI service registry 7 . Our aim is to completely virtualise both storage and services, and provide discovery mechanisms for archived
input files and services. At present the user must first select a machine and can then discover the data sets and services available there. Our intention is to make it possible to discover data sets and services anywhere on the GECEM grid without needing the specify any particular machine. Another area currently under development is the portal’s support for collaborative analysis and visualisation. Software tools and services developed in the Resource Aware Visualisation (RAVE) project are being used to provide a framework for collaboration [GRI 05]. The RAVE project is developing a collaborative visualization environment that scales from immersive platforms, such as CAVEs and ImmersaDesks, to non-immersive PCs and workstations, and even to PDAs or any other network-enabled display. Because of the diverse capabilities of the display platforms the environment is “resource-aware” in the sense that the platform where the rendering is done and the graphical representation sent to a display client is determined by factors such as the capabilities of the client and the network bandwidth. Support for multiple concurrent users is also an important aim, and this is currently being added to the GECEM portal. Once this work is completed, multiple users will be able to prepare and end GECEM jobs independently of each other, and they will be able to monitor the progress of their jobs. It is not necessary for users to remain logged into the GECEM portal while their jobs are running – they can log out and return later to check on progress. When multiple machines offer equivalent services it is helpful to be able to decide which to use based on how much spare compute capacity each machine has. Thus, another useful addition to the GECEM portal would be portlets that monitor performance metrics, such as current load and memory available, peak speed, and number of users, in order for users to be able to schedule their jobs on under-utilised machines. Ultimately, it might be desirable for such scheduling decisions to be made automatically, although there are no current plans to do this in the GECEM portal. There are also future plans to migrate the GECEM portal from using OGSA services and underlying infrastructure to use the Web Services Resource Framework (WSRF) 8 . Instead of using service data elements to monitor the progress of a computation, WS-Notification may be used. One important observation that has come out of our work on the GECEM portal is a degree of inflexibility in the composition of web services. The portal approach seems best suited to situations in which the workflow follows a pre-determined pattern – in the case of the GECEM portal a linear pipeline. The portal approach appears less wellsuited to situations in which arbitrary web services need to be composed together to create applications on-the-fly. Custom-build frameworks such as Triana [TAY 05] and Taverna [OIN 04] are better for these sorts of tasks. The
7
8
VI. D ISCUSSION AND F UTURE W ORK
http://www.uddi.org/
http://www.globus.org/wsrf/
GECEM project is investigating how the arbitrary composition of services can be supported through portlets. VII. S UMMARY AND C ONCLUSIONS
We have presented the GECEM portal based on a combination of GridSphere, GridPortlets and our own GECEM Portlet applications. Specifically, we have described how single sign-on and proxy delegation works through the interaction of the GridSphere login portlet, the MyProxy repository, and the GridPortlets credential management portlet. We have also described the GECEM portlets used to select input data sets and services for GECEM jobs. A number of areas for future work have been discussed, including archiving and the use of UDDI for service discovery. We are going to use a UDDI registry to publish and discover the meshers and the solvers [CHE 04]. Within the GECEM portal framework we aim to support collaborative visualisation, exploration, and analysis of the CEM simulation results through the use of RAVE technology. In future development, we hope to migrate the portal to use “pure” web services, and to this end we are tracking the development of WSRF and related web service standards. ACKNOWLEDGEMENTS
The authors would like to acknowledge many helpful discussions with their collaborators on the GECEM project, especially Yu Chen and Jason Jones of the University of Wales, Swansea who developed the surface mesh, volume mesh, and CEM solver services. It is also a pleasure to acknowledge the help of Ian Grimstead of the RAVE project, and Jon Giddy of the Welsh e-Science Centre REFERENCES [BEE 05] B EESON B., M ELNIKOFF S., V ENUGOPAL S., BARNES D. G., A Portal for Grid-enabled Physics, B UYYA R., C ODDINGTON P., M ONTAGUE P., S AFAVI -NAINI R., S HEP PARD N., W ENDELBORN A., Eds., Proceedings of the 2005 Australasian Workshop on Grid Computing and e-Research (AusGrid 2005), p. 13-20, January 2005. [CHE 04] C HEN Y., J ONES J. W., L IN M., WALKER D. W., A Web Service Architecture for GECEM, Proc. UK e-Science All Hands Meeting 2004, August 2004. [DEL 04] D ELAITRE T., G OYENECHE A., K ACSUK P., K ISS T., T ERSTYANSZKY G. Z., W INTER S. C., GEMLCA: Grid Execution Management for Legacy Code Architecture Design, Proceedings of the 30th EUROMICRO Conference, Rennes, France, p. 477–483, August 2004. [ERE 05] E RES M. H., P OUND G. E., J IAO Z., WASON J. L., X U F., K EANE A. J., C OX S. J., Implementation and utilisation of a Grid-enabled problem solving environment in Matlab, Future Generation Computer Systems (In press), 2005. [FOS 02] F OSTER I., K ESSELMAN C., N ICK J. M., T UECKE S., The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, Rapport, Globus, February 2002. [GRI 05] G RIMSTEAD I. J., AVIS N. J., WALKER D. W., Visualization Across the Pond: How a Wireless PDA can Collaborate with Million-Polygon Datasets via 9,000km of Cable, Proceedings of the Tenth International Conference on 3D Web Technology (Web2005), March 2005.
[KAC 03] K ACSUK P., D OZSA G., L OVAS R., P ODHORSZKI N., BALATON Z., G OMBAS G., P-GRADE: A Grid Programming Environment), Journal of Grid Computing, vol. 1, p. 171–197, 2003. [KAC 04a] K ACSUK P., K ISS T., G OYENECHE A., D ELAITRE T., FARKAS Z., B OCZKO T., A High-Level Grid Application Environment to Grid-Enabled Legacy Code, ERCIM News, vol. 59, October 2004. [KAC 04b] K ACSUK P., K ISS T., G OYENECHE A., D ELAITRE T., FARKAS Z., B OCZKO T., High-Level Grid Application Environment to Use Legacy Codes as OGSA Grid Services, Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing, Pittsburgh, USA, November 2004. [NOV 03] N OVOTNY J., RUSSELL M., W EHRENS O., GridSphere: A Portal Framework For Building Collaborations, Proceedings of the First International Workshop on Middleware for Grid Computing, June 2003. [OIN 04] O INN T., A DDIS M., F ERRIS J., M ARVIN D., S EN GER M., G REENWOOD M., C ARVER T., G LOVER K., P OCOCK M. R., W IPAT A., L I P., Taverna: A tool for the composition and enactment of bioinformatics workflows, Bioinformatics Journal, vol. 20, n17, p. 3045-3054, 2004. [TAY 05] TAYLOR I., WANG I., S HIELDS M., M AJITHIA S., Distributed computing with Triana on the Grid, Concurrency and Computation:Practice and Experience, vol. 17, n1–18, To be published Wiley Publishing, 2005. [WAL 03] WALKER D. W., G IDDY J. P., W EATHERILL N. P., J ONES J. W., G OULD A., ROWSE D., T URNER M., GECEM: Grid-Enabled Computational Electromagnetics, Proceedings of the UK e-Science All Hands Meeting 2003, p. 436–443, September 2003.
