1. Tier1 Grid from users point of view: urge of standards Dr James Cunha Werner Babar UK Grid Meeting

2. Users Requirements PhD students with 3 years scholarship. Researchers with fixed-term contract. Researchers with deadlines and competition. THEY NEED AN OPERATIONAL AND RELIABLE ENVIRONMENT TO DO THEIR WORK.

3. The service provide by RAL for Babar Grid UK Months to install LCG properly. Months to develop an initialisation script. Lack of adequate procedures  Poor service. USERS LOOKING FOR OTHER RESOURCES: SLAC, GRIDKA, ETC User’s waste of time. Idle resources.

4. Grid at Babar Elba meeting

10. TauUsers reprocessing: opportunity lost!

11. Jenny’s request Date: Mon, 4 Apr 2005 12:58:37 +0100 (BST) From: Jenny Williams To: James Werner Subject: TauUser for CM2 ok, it works. Requirements: for running with analysis-24: Beta V00-12-03 BetaMiniUser V00-03-00 BetaPid V00-04-10-05 …

12. Date: Mon, 4 Apr 2005 10:58:11 +0100 From: Steve Traylen To: jamwer Cc: babargrid-uk@lists.man.ac.uk, Chris Brew Subject: Re: [BABARGRID-UK] Jobs in Waiting forever... On Mon, Apr 04, 2005 at 10:11:30AM +0100 or thereabouts, jamwer wrote: > Dear colleagues, > Last week I submitted one dataset (26 jobs) to bohr0001.... and the jobs > were waiting for 4 days. I killed all of them and submitted again in my > farm bfb... and they still waiting. > Submission was fine: > > JOB SUBMIT OUTCOME > The job has been successfully submitted to the Network Server. > Use edg-job-status command to check job current status. Your job > identifier (edg_jobId) is: > > - https://lcgrb01.gridpp.rl.ac.uk:9000/hXbthIXfJCACQeOh-na3_w Chris, James I should add, it is only lcgrb01.gridpp.rl.ac.uk that appears to have this problem. There are not reports from other RBs of them going into this state. I'll keep you updated as I get news. Looking for other RBs that support babar there is also grid008g.cnaf.infn.it egee-rb-01.cnaf.infn.it It would be good to break there RB as well. CNAF has the expertise locally to fix this kind of thing. Steve Operational problems At RAL

13. RAL operational again Date: Fri, 6 May 2005 09:25:58 +0100 From: Steve Traylen To: Babar Grid UK Cc: James Werner Subject: lcgrb01 looks to be okay now. Hi James and others. lcgrb01.gridpp.rl.ac.uk the RB at RAL that was having problems now looks to be okay. It was okay before I went away two weeks ago and still appears to be. The fault looked to be a bad a interaction between globus and nscd. Please feel free to use lcgrb01 and as normal post questions to lcg-support@gridpp.rl.ac.uk

15. Initialisation script From : Sent : 17 February 2005 09:00:07 To : BaBarGrid-hn@slac.stanford.edu Subject : Re: VO-based environment settings Dear Artem, Your question is very important if we want to establish a worldwide grid. LCG grid software defines envvar VO_BABAR_SW_DIR to point the configuration directory, where initialisation scripts, tars etc are stored. At Manchester we defined the script $VO_BABAR_SW_DIR/babar-grid-setup-env.sh to initialise $BFROOT, $BFARCH,... and call all scripts from hepix (group_siteSpecs.conf.sh, group_aliases.sh, group_sys.conf.sh, and bashrc). If you do not have the release installed, them a tar should be untared following http://babar-hn.slac.stanford.edu:5090/HyperNewws/get/BabarGrid/322.html to provide the necessary infrastructure. We do not use this, because our babar software is installed at AFS. The next step is set 00_FD_BOOT to your last version of condition and configuration database. At this point, you will be able to run BetaMiniApp without any problem, in any computer in the world with follow this elementary standard. I am running Tau11 in parallel in 26 computers from different farms, which allow me analyse more tham 1 million events per hour. For more information, see http://www.hep.man.ac.uk/u/jamwer/ Best regards, James

16. From : Sent : 17 February 2005 09:41:40 To : BaBarGrid-hn@slac.stanford.edu Subject : RE: VO-based environment settings Hi, As someone who sits on both sides of this fence (site admin and grid application developer/user) James's solution is, I think, the only practical one and the one I've been pushing. …

17. Date: Mon, 9 May 2005 10:59:34 +0100 (BST) From: jamwer To: Hep-grid@lists.man.ac.uk, babargrid-uk@lists.man.ac.uk Subject: [BABARGRID-UK] Grid needs standards Would you please write a script for analysis-24, called. $VO_BABAR_SW_DIR/babar-grid-setup-env-analysis-24.sh which initialise all babar environment and 00_FD_BOOT. The commands users have to run after run your script will be: local=`pwd` cd /afs/rl.ac.uk/bfactory/dist/releases/analysis-24 srtpath analysis-24 $BFARCH cd $local ln -s $BFROOT/dist/releases/analysis-24 PARENT edg-rm --vo babar cp lfn:jamwer_bfb.tier2.hep.man.ac.uk_BetaMiniApp_16 file:///tmp/BetaMiniApp chmod 777 /tmp/BetaMiniApp /tmp/BetaMiniApp JobTau11-Run4-OnPeak-R14-1.tcl rm /tmp/BetaMiniApp I am trying to run using the same parameters I had in the batch system and it is not working.We need a standard way to initialise the environment, if we want to allow users in grid in any site. Let me know when you have the job done, or if you have a best way to do it. Best regards, James

18. Date: Tue, 10 May 2005 13:51:59 +0100 To: jamwer Cc: babargrid-uk@lists.man.ac.uk Subject: RE: [BABARGRID-UK] Grid needs standards Hi James, I've not dealt with this because I'm away at the HEPiX Workshop at the moment and this will need some dicussion before it's implemented. The script you suggest is very highly taylored to your specific needs and will have to very much more generalised before it can go into use. Also as you say in the subject line "Grid needs standards" but those standards need to be agreed and useful for many people. I suggest you report this as a suggestion to the main BaBarGrid list where we can discuss it and find a general solution which will work for more situations than just yours. …

19. Publishing site resources/releases > GlueHEPSup= Babar, Atlas,... <= different softwares > GlueOS= RH7.2, RH7.3 or SL3... <= Operating System > GlueAplic= BetaMiniApp, Moose,... <= Available Application > GlueReleases= 14.5.2, 14.5.2d, 16.0.1 etc <= Releases available > GlueCondDB= local, AMS, xrootd,... <= Cond & Config DB > GlueBackgroundDB= local, AMS, xroot,... <= Background DB > GlueBbk= local, xrootd,... <= Experimental Data We would be able to seach the configuration we want to run the software and optimise resources. I am able to know how many jobs are in queue, and what would be the best strategy. If a massive software (taking days) we can use data remotely through xrootd: them GlueBbk=xrootd would be used. If a program test use GlueBbk=local, and only a few sites would be able to run it. A consulta fornecera a lista com o nome dos CE com o release disponivel.