Athena Access to the SE
You can list files on the SE using either rfdir or dpns-ls:
rfdir /dpm/ph.bham.ac.uk/home/atlas/atlasmcdisk/mc08/
dpns-ls -l /dpm/ph.bham.ac.uk/home/atlas/atlasmcdisk/mc08/
Athena ultimately requires a list of files, so perhaps a script to take a DQ2 dataset name, find it's location on the SE and then output filelist.py would suffice?
Setup (User)
RFIO relies on the library libshift.so, but Castor and DPM required two different versions, Castor being the default. To fix this, in the run directory:
ln -s /home/lcgui/SL4/prod/lcg/lib/libdpm.so libshift.so.2.1
export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
This allows for (the very slow) access to the SE using RFIO.
!!! The LD_LIBRARY_PATH
variable must be re-exported after every compile!!!. Users will also require a valid grid certificate.
Finding Files
The
sancho.sh script may be used to locate files on the SE via their DQ2 label. It can be used to output a filelist in two formats - with and without Athena decorations.
Example 1:
source sancho.sh mc08.105502.AcerMC_tchan.recon.AOD.e352_s462_r541 #Prints a list of files suitable with one file per line (suitable for ganga)
Example 2:
source sancho.sh -a mc08.105502.AcerMC_tchan.recon.AOD.e352_s462_r541 #Prints a list of files with Athena decorations ("ServiceMgr...." etc)
Testing
Volume of Data Transferred
The RFIO buffer was set very low values and 250 ttbar events were read. When reading an AOD, athena appears to read 3 header blocks before starting to process the data. The table below shows the amount of data read for various buffer sizes.
It remains to be seen if the size of these headers is dataset dependent. Probably true.
Athena goes on to request more data when event processing starts, the volume being dependent on the the number (and presumably type and size) of the StoreGate collections requested. For a skeleton algorithm (no StoreGate access), the 64 byte buffer requests approximately 20 kB per event. Each additional StoreGate collection requested appears to add (
very roughly!) 16 kB per event to the total data requested. It's easy to imagine each event requiring at least 100 kB of data.
It remains to be seen if athena requests data event by event or if it fills a buffer, processes all the complete events and then requests the buffer be refilled. I'd probably go with the later.
Variable RFIO Buffer Size
The time taken to iterate over 1000 ttbar events from the sample
mc08.105200.T1_McAtNlo_Jimmy.recon.AOD.e357_s462_r541/
for various RFIO buffer sizes is shown below. The test was completed on a desktop machine. The plot shows that whilst the absolute time is dependent on the number of persistent StoreGate collections retrieved, the overall trend for smaller buffers being better unless you can afford to read the entire file.
From a single user point of view, 4 kB buffers are the best solution. Will this put too much of a drain on the SE though? Presumeably this means that once the user has consumed 4kB, it will immediately request more data. I wonder if this scales as the number of clients increases?
--
ChristopherCurtis - 29 May 2009
- sancho.sh: sanch.sh - tool for finding files on the SE and printing filelists