The current version of the farmout script will attempt to copy the files to dCache; if it fails then the root files will be copied back to the scratch directory where the job was submitted from instead of AFS. Also, all the log, error and output files are stored in scratch space, reducing the load of AFS.

To use it, you must copy BOTH farmout and cmsRun.sh to the /scratch directory of the machine you'll submit the jobs from and in particular to a subdirectory with the same name as your username. For example:

mkdir /scratch/lazaridis
cp ~lazaridis/bin/scratch/* /scratch/lazaridis

This step is importand because the cmsRun.sh executable is expected to be found at this place.

To submit, you'll need to have environment correctly set up for the CMSSW version you'll use (should be the same one defined in the farmout script) and a valid grid-proxy ticket.

You can create the second by doing:

% source /cms/cmsprod/setup.sh
% grid-proxy-init

To submit the jobs the usual syntax is used:

farmout <cfi_file> <total events> <events per job> <Job#ToStartFrom>

The cfi file should exist in the IOMC/GeneratorInterface/data area of the CMSSW version which will be used.

The <Job#ToStartFrom> parameter will be used in the filename generation. This way if you've already generated datafiles say from 0-100 you could continue from 101.

When the jobs finish, the script will attempt to copy the root files to dCache; if it fails then the root files will be copied to the scratch directory instead of AFS. All the rest of the output files will remain in the scratch space. If the job fails miserably, meaning cmsRun exits with a status different from 0, then the rootfile will be erased and not return to either dCache or the scratch space. This behavior can be changed by commenting out the respective line in the cmsRun.sh file.

Last update: Jan. 24, 2007, Christos Lazaridis