I've submitted an install request for 14.2.20, should take a few hours...
Peter
2008/11/25 Brew, CAJ (Chris) <[log in to unmask]>:
> Hi,
>
> Two things.
>
> 1) In direct relpy to this message doesn't it work if you use:
>
> SURL: srm://srm.dcache.ac.uk/pnfs/path/to/file
>
> TURL: gsidcap://srm.dcache.ac.uk/pnfs/path/to/file
>
> It does here but that may be a function of our setup.
>
> 2) I haven't seen any evidence of any jobs at RALPP. digging a bit
> deeper I think it may be because the jobs are requesting a software
> version haven't got installed.
>
> At least from reading
> http://gangarobot.cern.ch/st/test_31/jobs/200_UKI-SOUTHGRID-RALPP_MCDISK
> .py
>
> I see:
>
> software = ['VO-atlas-offline-14.2.20-i686-slc4-gcc34-opt'] ,
>
> but that isn't one of the VOTags published on:
>
> http://goc.grid.sinica.edu.tw/gstat/UKI-SOUTHGRID-RALPP/
>
> which seems to stop at 14.2.10.
>
> Yours,
> Chris.
>
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes
>> [mailto:[log in to unmask]] On Behalf Of Greig A. Cowan
>> Sent: 25 November 2008 17:00
>> To: [log in to unmask]
>> Subject: Re: Analysis challenge in the UK tomorrow
>>
>> Hi John,
>>
>> Gordon, JC (John) wrote, On 25/11/08 16:22:
>> > Greig, do you have a suggestion as to how ATLAS might use
>> your method in
>> > a way that a job could run at any site?
>> >
>>
>> I would consider just forgetting about SRM altogether for analysis
>> activity. The SE namespace has been structured in such a way that the
>> TURL can be inferred from the SURL anyway.
>>
>> SURL: srm://srm.headnode.ac.uk/dpm/path/to/file
>>
>> TURL: rfio://dpm/path/to/file
>>
>> Within the ATLAS Athena framework it should be possible to
>> just specify
>> the TURLs in EventSelector rather than the SURLs. Athena
>> should then be
>> clever enough to go away and load the appropriate protocol plugin to
>> open the file on the SE. This is what I do within the LHCb Gaudi
>> framework (Gaudi and Athena are essentially the same).
>>
>> To get this to work at DPM sites you need to ensure that DPM_HOST and
>> DPNS_HOST are set appropriately in the environment on the WN.
>>
>> I'll need to have a think about what can be done for dCache
>> sites. The
>> same thing basically worked for me at Edinburgh, where we have:
>>
>> SURL: srm://srm.dcache.ac.uk/pnfs/path/to/file
>>
>> TURL: gsidcap://poolnode1.dcache.ac.uk/pnfs/path/to/file
>>
>> but this requires that a priori you know that poolnode
>> hostname when you
>> construct the TURL that you pass to the user application. I
>> don't think
>> it's possible to set a list of available poolnodes as an environment
>> variable on the WN.
>>
>> Cheers,
>> Greig
>>
>> > John
>> >
>> >
>> >> -----Original Message-----
>> >> From: Testbed Support for GridPP member institutes [mailto:TB-
>> >> [log in to unmask]] On Behalf Of Greig A. Cowan
>> >> Sent: 25 November 2008 16:19
>> >> To: [log in to unmask]
>> >> Subject: Re: Analysis challenge in the UK tomorrow
>> >>
>> >>
>> >> At Edinburgh I just set things up so that I use
>> rfio:/dpm/path/to/file
>> >> to access data which bypasses any SRM communication. This is really
>> >> only
>> >> possible because I know how things are setup in here.
>> >>
>> >> Performing the SRM communications and extra GSI steps will also
>> >>
>> > explain
>> >
>> >> why the DPM head node is really busy.
>> >>
>> > C005336.
>> >
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
> --
> Scanned by iCritical.
>
|