Distributed interactive engineering toolbox

Distributed Interactive Engineering Toolbox (DIET) is a hierarchical set of components used for the development of applications based on computational servers on the grid. It consists of a set of elements that can be used together to build applications using the GridRPC paradigm [Amar et al., 2006 ].

The DIET has a hierarchical architecture providing flexibility and can be adapted to various environments including heterogeneous network hierarchies.

In DIET, there are three main components: master agent (MA), local agent (LA), and server daemon (SeD). (1)Master agent is the entry point of DIET system. Clients submit requests for a specific computational service to the MA. The MA then forwards the request in the DIET hierarchy until the re-quest reaches the SeDs. LA aims at transmitting rere-quests and information between MAs and servers. (2)Local agent maintains the information about the list of requests and, for each of its subtrees, the number of servers that can solve a given problem. (3)Server daemon provides the interface to computa-tional servers and can offer any number of application specific computacomputa-tional

Grid computing overview 15 services. The information stored on a SeD is the list of the data available on a server, the list of problems that can be solved on it, and every information concerning its load (CPU capacity, available memory, etc.).

The management of the platform is handled by several tools like GoDIET for the automatic deployment of the different components, LogService for monitoring, and VizDIET for the visualization of the behavior of DIET’s internals. DIET provides a special feature for scheduling through its plug-in schedulers. The DIET user is provided with the possibility of definplug-ing requirements for scheduling of tasks by configuring the appropriate scheduler.

1.6.3.3 XtremWeb

XtremWeb is a global computing system which achieves the secure and fault tolerant peer to peer computing by remote procedures call (RPC) technology [Cappello et al., 2005 ]. XtremWeb allows clients to submit task requests to the system which will execute them on workers. In order to decouple clients from workers and to coordinate task executions on workers, the coordinator is added between client and worker nodes. The details of these three services are shown as follows:

• Coordinator: The coordinator in XtremWeb is composed of three ser-vices: the repository, the scheduler, and the result server. The coor-dinator accepts task requests coming from clients, assigns the tasks to the workers according to a scheduling policy, supervises task execution on workers, detects works crash, reschedules crashed tasks on any other available worker, and delivers task results to client upon request.

• Worker: The worker architecture includes four components: the task pool, the execution thread, the communication manager and the activity monitor. The activity monitor detects the host information (e.g., per-centage of CPU idle, mouse and keyboard activity) to control whether computations can be started on the hosting machine. The task pool is a queue structure of tasks, maintained by scheduling strategy. The com-munication manager ensures comcom-munications with other entities and achieves files downloading and results uploading. The execution thread extracts task from the task pool, starts computation, and waits for the task to complete.

• Client: The client in XtremWeb is implemented as a library plus a daemon process. The library provides an interface which can be used to achieve the interaction between the application and the coordinator.

The daemon process makes recovery points regularly which insure the machine recovery and jobs rescheduling on another machine.

XtremWeb aims to turn a large scale distributed system into a parallel com-puter with classical users, administration, and programming interface using fully decentralized mechanism to implement the system functionality.

16 Fundamentals of Grid Computing 1.6.4 Grid programming environments 1.6.4.1 Cactus code

Cactus is a framework for building a variety of computing applications in science and engineering, including astrophysics, relativity and chemical en-gineering [Goodale et al., 2003 ]. Cactus which started in 1997 is an open source problem solving environment designed for scientists and engineers. Its modular structure easily enables parallel computation across different archi-tectures and collaborative code development between different groups. Cactus originated in the academic research community, where it was developed and used over many years by a large international collaboration of physicists and computational scientists.

Cactus consists of a central core (or “flesh”) and application modules (or

“thorns”). A thorn is the basic working module within Cactus. All user-supplied code goes into thorns, which are independent of each other and pro-vide a range of computational capabilities, such as parallel I/O, data distri-bution, or checkpointing. The flesh is independent of all thorns and provides the main program, which parses the parameters and activates the appropriate thorns, passing control to thorns as required. The flesh connects to thorns through an extensible interface.

As a portable system, Cactus runs on many architectures. Applications, developed on standard workstations or laptops, can be seamlessly run on clusters or supercomputers. Cactus provides easy access to many cutting edge software technologies being developed in the academic research commu-nity, including the Globus Metacomputing Toolkit, HDF5 parallel file I/O, the PETSc scientific library, adaptive mesh refinement, web interfaces, and advanced visualization tools.

1.6.4.2 GrADS

The goal of the grid application development software (GrADS) project is to simplify distributed heterogeneous applications development and to make it easier for ordinary scientific users to develop, execute, and tune applications on the grid [Berman et al., 2001 ].

There are two sub-systems in a GrADS environment: GrADS program preparation system and GrADS execution environment.

• GrADS program preparation system: In order to simplify development of grid-enabled applications, the preparation system provides a method-ology in which most users will compose applications in a high-level, domain-specific language built upon pre-existing component libraries.

This approach hides grid-level details and lets the user express a com-putation in terms that make sense to an expert in the application do-main. Two components are implemented to support this methodology:

a domain-specific language called telescoping language, and a tool for load-time tailoring which is called the dynamic optimizer. The SaNS

Grid computing overview 17 libraries which automatically select and integrate the most effective li-brary components for a given problem, data set, and collection of re-sources are developed to improve the ability of computational scientists to solve challenging problems efficiently.

• GrADSoft execution environment: The GrADSoft execution environ-ment provides new mechanism to discover and communicate informa-tion about the environment to program components, to transfer program requirements to the environment and program components in ways of which admit to effective control, and to monitor and control adaptively an executing program.

The GrADS project has established an effort to pioneer technologies that will be needed for ordinary scientific users to develop applications for the grid. These technologies include a new program preparation framework and an execution environment that employs continuous monitoring to ensure that reasonable progress is being made toward completion of a computation.