About the scheduler

<?xml version="1.0" encoding="utf-8" ?>
<job maxFilesPerProcess="500" filesPerHour="100">
<command>root4star -q -b
rootMacros/numberOfEventsList.C\(\"$FILELIST\"\)
</command>
    <stdout 
URL="file:/star/u/carcassi/scheduler/out/$JOBID.out" />
    <input
URL="catalog:star.bnl.gov?production=P03ia,
trgsetupname=dAuMinbias,filetype=daq_reco_MuDst
,magscale=ReversedFullField" />
    <output fromScratch="*.root"
toURL="file:/star/u/carcassi/scheduler/out/" />
</job>

The user interface we developed is the most important piece of this project. Though never collected formally, this effort has been driven completely by use cases. It is a product of an ongoing process that continues release after release as our user base increases.

The user interface is composed of two parts: the job description and the job specification.

Job description: the user will write an XML describing his request. The description specifies the user requirements and not how the system will satisfy those requirement. This high level descriptions gives users a simpler system to use, and the developer more freedom to implement it in different ways.

Job specification: this defines the requirements needed by the scheduler to make its decisions. For example, the scheduler will decide how many jobs will be created to satisfy the request, and will assign the input files to the jobs. The job specification allows this passage of information from the scheduler to the user job.

Gathering use cases and define the user interface is a very difficult process (if not almost impossible) for people outside of the experiment. The job description and job specification provide a much easier and understandable set of requirement for computer scientist working on GRID tools.