grid

Pyglobus is setup and running on nori. Its been installed as a python package and located under /usr/lib/python2.2/site-packages/pyGlobus.
I have installed the pyGlobus package from nsf-middleware website.
I am running some tests to see it working. The gramClient and GridProxyInit are working as I was able to submit job and get back result to/from Medusa.

I contacted Stephen Pickles of the GRENADE project and this is what he had to say.
"Right now, we're working towards a release of GRENADE 1.0
which should happen late March or early April."
I am looking forward to seeing this release.
Their public web-site for the project at the moment is http://www.sve.man.ac.uk/Research/AtoZ/GRENADE

That is strange. I created an entry here yesterday and it has not showed up. Anyway it was about the GrEnaDE Project (Grid Enabled Desktop Environment) where they plan to interface with the entire grid world through KDE. Though they have not released any software, they seem to be working on a sleek idea. You can find their project page here http://mrccs.man.ac.uk/research/grenade/
I have been going through their sourceforge stuff and they are still in the phase of planning after a year. I could not see any designs also.

GridPort is a new version of HotPage. HotPage is a set of CGI modules, written in Perl, developed to show the available computing resources and its usage. The present GridPort does that as well as allow for job submission. The new GridPort 3 uses web-services infrastructure.
The software based on JetSpeed that Zach mentioned yesterday is GridSpeed, which is a grid portal hosting server, as they call it. GridSpeed seemingly is used to generate web interfaces for application grids, but they have not released any source or binarys yet. URL for GridSpeed project is http://grid.is.titech.ac.jp/gr

We need some test applications to testing the build and run steps of our Grid resourece. These are likely to be MPI apps.

They need to be identified and made availabe.

A problem was reported that builds of the uab-grid rpm were failing inconsistently. The problem causing the failure was SIGPIPE but it didn't happen consistently. Running the build "enough times" or under strace would often avoid the problem.

The problem was with the rpm spec file. It did not contain a BuildRoot definition in the header. It appears this is listed as an [optional arg|http://www.rpm.org/RPM-HOWTO/build.html#HEADER] in the [rpm docs|http://www.rpm.org/max-rpm/ch-rpm-anywhere.html] but one of the tools rpm-build uses, check-file, expects this variable to be defined in order to check that files listed in the %file section of the spec file contain all the files in the BuildRoot (or something similar). If BuildRoot is not set, check_files exits quickly. The caller (rpm-build?) of check_files doesn't pay attention to this exit and still tries to send data on check_file's STDIN. When check_files has exit'd you get a SIGPIPE (broken pipe). This shows up as a broken pipe in the rpm-build around the "Checking for unpacked files" part.