[gin-ops] FW: Status

[Cindy Zheng]

Dear all,
Here is an update on the status of running TDDFT 
On LCG clusters. It turns out to be more challenging 
than we thought. We'll definitely learn more from 
this as a result. Yoshio has a solution to this, 
and TDDFT team and LCG team will continue work on
this after GGF17. See Yoshio's email below for more 
details.    ...Cindy

-----Original Message-----
From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp] 
Sent: Friday, April 28, 2006 4:50 PM
To: m.aggarwal at imperial.ac.uk
Cc: o.van-der-aa at imperial.ac.uk; zhengc at sdsc.edu; Erwin.Laure at cern.ch;
yusuke.tanimura at aist.go.jp; yoshio.tanaka at aist.go.jp
Subject: Re: Status



Hi Aggarwal,

Thanks for the info.
We will learn more details about protocols and status flow of the LCG
middleware.
I guess it's not easy to run TDDFT on EGEE since by default, Ninf-G
uses native GRAM protocol.

# Ninf-G is a programming middleware based on Grid RPC (Remote
# Procedure Call).  Ninf-G provides C and Java API for Grid
# applications based on client/server model.
# Ninf-G is implemented using Globus C and Java APIs and Ninf-G client
# invokes server functions via the Globus GRAM, i.e. Ninf-G client
# uses GRAM protocols for remote process invocation.

Fortunately, Ninf-G version 4 is capable of interact with various Grid
middleware by implementing invoke server, which is an interface
between Ninf-G client and the server-side middleware.
For example, Ninf-G4 provides invoke server for GT2, GT4, UNICORE, and
NAREGI Super Scheculer.  I think it is possible to run TDDFT on EGEE
if we develop invoke server for edg-gatekeeper.

But Unfortunately, we have started the vaction (golden) week :-)
So, it may take few weeks to resume this work.

Thanks,

--
Yoshio Tanaka (yoshio.tanaka at aist.go.jp)
http://ninf.apgrid.org/
http://www.apgridpma.org/


From: "Mona Aggarwal" <m.aggarwal at imperial.ac.uk>
Subject: RE: Status
Date: Fri, 28 Apr 2006 18:11:42 +0100
Message-ID: <004b01c66ae6$d74eb600$39d3c69b at hep.ph.ic.ac.uk>

m.aggarwal> > -----Original Message-----
m.aggarwal> > From: Yoshio Tanaka [mailto:yoshio.tanaka at aist.go.jp] 
m.aggarwal> > Sent: 28 April 2006 17:38
m.aggarwal> > To: m.aggarwal at imperial.ac.uk
m.aggarwal> > Cc: o.van-der-aa at imperial.ac.uk; zhengc at sdsc.edu; 
m.aggarwal> > Erwin.Laure at cern.ch; yusuke.tanimura at aist.go.jp; 
m.aggarwal> > yoshio.tanaka at aist.go.jp
m.aggarwal> > Subject: Re: Status
m.aggarwal> > 
m.aggarwal> > 
m.aggarwal> > 
m.aggarwal> > Hi Aggarwal,
m.aggarwal> > 
m.aggarwal> > I have two questions:
m.aggarwal> > 
m.aggarwal> > 1. What's the difference between globus gatekeeper and edg

m.aggarwal> > gatekeeper? 
m.aggarwal> It is the same thing with some modifications.
m.aggarwal> 
m.aggarwal> The authorization decision is based upon the users' proxy
m.aggarwal> certificate and the job specification in RSL (JDL) format.
The certificate
m.aggarwal> and RSL are passed to (plug-in) authorization modules, which
grant or
m.aggarwal> deny the access after checking the user in gridmap file on
the CE. 
m.aggarwal> 
m.aggarwal> 
m.aggarwal> 2. How proxy cert is delegated to users's job?
m.aggarwal> 
m.aggarwal> Once the VO have been granted a certificate to be used for
job submission. 
m.aggarwal> Tools on a user-interface (UI) machine then allow the user
to generate, 
m.aggarwal> from this certificate, a delegated proxy. This is sent along
with the job, 
m.aggarwal> enabling the job to perform Grid operations on behalf of the
user. 
m.aggarwal> 
m.aggarwal> For more information:
m.aggarwal> https://edms.cern.ch/file/498081/1.0/UserScenario2.pdf
m.aggarwal> 
m.aggarwal> Regards,
m.aggarwal> 
m.aggarwal> Mona 
m.aggarwal> 
m.aggarwal> ====================================
m.aggarwal> Mona Aggarwal
m.aggarwal> Tel. (+44) 20 759 47809
m.aggarwal> Imperial College London
m.aggarwal> High Energy Physics Department
m.aggarwal> Prince Consort Road, London, SW7 2BW 
m.aggarwal> ====================================
m.aggarwal> 
m.aggarwal>