CapeTools Grid Computing Tools

General Description

These functions are used to save an object graph to memory, XML string or XML file in order to ease GRID programming.

What is GRID programming?

A server processing database requests from multiple clients is a common example of a distributed system. Using a single server machine in such a scenario often results in unwanted delays to its clients due to the processing load on the server. A supercomputer or any other multiprocessor computer can solve this problem, but these computers are not freely available and are often too expensive.
The power of a supercomputer can be simulated by applying Grid technology to the under-utilized resources of available computers.

Grid computing is an emerging computing model that provides the ability to perform higher throughput computing by taking advantage of many networked computers to model a virtual computer architecture that is able to distribute process execution across a parallel infrastructure. Grids use the resources of many separate computers connected by a network (usually the Internet) to solve large-scale computation problems. Grids provide the ability to perform computations on large data sets, by breaking them down into many smaller ones, or provide the ability to perform many more computations at once than would be possible on a single computer, by modeling a parallel division of labour between processes.

Grid computing offers a model for solving massive computational problems by making use of the unused resources (CPU cycles and/or disk storage) of large numbers of disparate computers, often desktop computers, treated as a virtual cluster embedded in a distributed telecommunications infrastructure. Grid computing's focus on the ability to support computation across administrative domains sets it apart from traditional computer clusters or traditional distributed computing.

Grids offer a way to solve Grand Challenge problems like protein folding, financial modelling, earthquake simulation, and climate/weather modelling. Grids offer a way of using the information technology resources optimally inside an organization. They also provide a means for offering information technology as a utility bureau for commercial and non-commercial clients, with those clients paying only for what they use, as with electricity or water.

Grid computing has the design goal of solving problems too big for any single supercomputer, whilst retaining the flexibility to work on multiple smaller problems. Thus Grid computing provides a multi-user environment. Its secondary aims are better exploitation of available computing power and catering for the intermittent demands of large computational exercises.

This approach implies the use of secure authorization techniques to allow remote users to control computing resources.

Grid computing involves sharing heterogeneous resources (based on different platforms, hardware/software architectures, and computer languages), located in different places belonging to different administrative domains over a network using open standards. In short, it involves virtualizing computing resources.

Grid computing is often confused with cluster computing. The key difference is that a cluster is a single set of nodes sitting in one location, while a Grid is composed of many clusters and other kinds of resources (e.g. networks, storage facilities).

Thus a grid is a type of parallel and distributed system that enables the sharing, selection, and aggregation of geographically distributed "autonomous" resources dynamically at runtime depending on their availability, capability, performance, cost, and users' quality-of-service requirements.
Thus, at the most basic level, a grid can be viewed as an aggregation of multiple machines (each with one or more CPUs) abstracted to behave as one "virtual" machine with multiple CPUs.

Various commercial and open source software toolkits are available to build such a Grid environment. Among them, the Globus Toolkit has been widely used in research all over the world for longer than a decade, while Alchemi is the latest addition to Grid software.
Alchemi and the Globus Toolkit are two open source software toolkits implementing a Grid environment. Alchemi runs on the Windows operating system in the .NET Framework while the Globus Toolkit has its origins in Linux. The complete Globus Toolkit is only available in Linux, but recent versions include some of its functionality also for Windows. The Globus Toolkit supports Java, C++, and Perl (among others) for the development of services. But the Windows .NET framework is not supported for Globus. Alchemi provides an API for DotNet and C++, and operates in the Windows .NET framework.

Most financial API toolkits provide functions which are fire and forget functions.
You pass the parameters, execute the function and the results are returned. Any state or objects created during the calculation of this function are cleaned up on exiting.
This is perfect for GRID computing.

The problem that our library face is that we use objects. As a result, many functions can be composed from objects with complicated inputs. A kind of LEGO approach to pricing. Because of this, you may have an object which has been created from 30 other objects.
In order to ease GRID computing via our library, the functions within this category of functions enable you to serialise an object graph to memory, file or XML string.

An object graph is simply all the parameters and objects needed to re-create the object. Any object that may have served as inputs to this object when it was created is part of the object graph.
For instance, the example for the XCcySwapPortfolio() function requires the construction of over 20 objects. You could code this logic within a GRID computing class, or you can save the object graph to a XML file or XML string and instead write code that simpy de-serialises the object graph. Further function calls would then interrogate any of the 20 re-created objects.

In a non-GRID environment, an excellent use for this also, would be to create objects (ie - yieldcurve), save this object to memory, and then further manipulate the orginal object (ie - change rates). Later, you can apply (re-create) the object graph saved earlier into memory, and you will have a new instances of all the objects saved (a new instance of all the objects needed to re-create the yieldcurve all with new key-names).
These new objects are basically a copy of the data taken at the time of serialisation. In fact this can be regarded as taking a static snapshot. A snapsht that can be saved to disk and re-read days, weeks later, used within the Excel or API functions, passed to associates etc... It also represents a way of saving data outside of Excel and inserting the object data into a database.

These functions, however, were coded in order to make GRID programming easier. Every object that is created from an object generating function (a function that returns a key-string) can be saved to memory (not really useful for GRID computing), XML file or a XML string.
The file is simply an XML file stored on disk and thus if using a Java or DotNET GRID framework, these languages provide objects to read in XML files.

Because of the complex nature of this library, you could proto-type your objects within Excel, seralise the objects to file, or XML, then within a GRID programming model, distribute the XML or file (via the GRID framework) to the client nodes where they would reload the objects. Your own individual GRID code would then act upon these objects.
In the case of constructing a XCcySwapPortfolio() object one would not need to write code to construct the initial 20 objects. If the portfolio is large, you could price the portfolio remotely. while your application works on another task until the results are returned.

Another great example of this would be to create a Monte-Carlo object and then using the GRID framework to instruct each node (machine) to simulate 100 paths and price a certain structure.

We like the Alchemi.NET Grid Computing Framework because it provides, in our minds, a programming model not so difference from OOP.
Probably also because we prefer .NET!!

Alchemi .NET Grid Computing Framework - http://www.alchemi.net
GLOBUS - http://www.globus.org