OK, I must admit I am a newbie in Grid computing, so please correct me in the comment if I make some mistakes.

GRAM stands for Grid Resource Allocation Manager, acts as the representative between the JMS and end users using the popular webservice interface. The invoked application and arguments are wrapped in the XML format, the request also contains the destination url, most likely in GridFTP server. The user may need to fetch the result once receives the reply from the server manually.

To ease this process, GRAM also supports some language bindings: C, Java, Python etc.

is held on Washington DC, just in our neighbourhood. It is fascinating for us to take the tutorials, hand-on sessions and learn something new in the hight performance computing field.

The very first tutorial, The Grid “Ecosystem” is Grid computing 101, the speaker, Lee Liming, introduced the concepts of Grid Computer, then gave a very detailed overview of the globus tookkit.

Security

Since grid is distributed geographically, security is No.1 concern for grid administration and management. We spent about 15 minutes discussing the certification of authority(CA), MyProxy( a delegation of CA service).

Scheduling

The core functionality is still handled by traditional job management system(JMS), but with grid-aware feature. Addtionally, Globus Resource Allocation Manager(GRAM) acts as the front-end for JMS to handle the authentification.

Programming

MPICH-G2 is ready. Not quite sure other GAS/PGAS libraries or languages.

Data communication

Unlike the normal FTP service, Grid suffers from that the traditional remote copy tools can not take the full advantage of high-speed connection. GridFTP is introduced to utilize multiple data channels to fast the file transfer, more aggressive approach is to explore the striped data distribution by using Striped GridFTP.

He also demonstrated a success story, NSF’s TeraGrid for the case study.

Question:
Grid is characterized by the non-uniform memory access(NUMA) in my mind. The communication overhead between the clusters is very expensive, and unreliable. How could we distribute the workload to adapt the topology of the grid? Suppose the following scenario:

The job can be modulized as i, j, k; there are huge intra-module communication and little inter-module communication. The grid consist at least three clusters, A, B, C. We expect to schedule each module to one cluster to elminate the unnecssary communication overhead. Does Globus is smart enough to discover the communication pattern, or should the developers need to explicitly configure the batch manually?

It is quite surprising to find the legendary handspring is still in use in GridWorld 2006. The staff scans the bar code on the badge with this gadget, and authenticate whether the visitor is eligible to access the specific session. Here is a picture of it in action:

The Dojo 2D API has evolved in the refactoring stage, Eugene completed the 1st stage yesterday. It is time to find, report and fix the bugs:

There are three browsers involed in the testing( from left to right):
Firefox 1.5.0.5 on Linux, Opera 9.00 on Linux, MSIE 6.0 w/SP2 on Windows XP(VMWare)

Fill color lost in Opera
Opera managed to draw the basic shapes, manipulate the layout and skew, but fails to render the color:

But this is not always the case, for example:

UPDATE: Fixed on r5321.

Pattern rendering in Opera and MSIE
Opera is the only mainstream browser that supports pattern fill. The following screenshot demostrates how Opera(right) and MSIE(left) render the tiled images:

The dimension of the image is 96×96, while in pattern the size is specified with width=120, height=96. MSIE strench the image, while Opera prefers to increase the padding.