STAR  Computing  GRID  Scheduler star-submit Command Line Options

What are Command Line Options ?

Command line options change the behavior of the star-submit command. To just submit your job with all the defaults one merely has to type:

star-submit request.xml

where request.xml holds the description of your jobs.

More details (for the experts):

The star-submit command is a /bin/csh script  that executes the scheduler's java jar. Java Jars are a collection of java classes. Some command line options are interpreted by the csh while others are interpreted inside java. For example using the "-r" (resubmit) option causes the csh script to call a different class for the Java Jar then the default one used for submitting the job. This scheme limits the scheduler to one executable command when different java classes may be being used. 

What Options are Available ?

Options can be broken down into two groups. The first group of  options used the submit a new jobs. These accept as there last argument the users xml file, which  hold the descript of there job. The second group of commands modify running jobs. This group accepts the [JOBID].session.xml as there last argument. Option for these two groups can not be mixed.

What are the Options  for Submitting New jobs ?

Notes: The logging levels from order of priority from lowest to highest are: debug --> info --> warn --> error --> fatal. 

The "default" way to submit a new job is: 

star-submit myjob.xml

This uses the default policy for the site. The policy is the algorithm that makes your jobs and  determines what batch system(s) and  queue(s) or pool(s) your jobs are placed into. There is a default policy for each site the scheduler runs at. However there may be other policies you can make use of, see the policies page on this site for a full list of available policies. To select a different policy to submit your job with, use the "-p [policyName]" option like in this example below:

star-submit -p bnl_condor_cas myJob.xml

The user should note that not all policies are always appropriate for all users. Some policies may hold queues that require special rights. For example there exist policies that are used for data reconstruction, that are intended to be used only by the reconstruction coordinator. Attempting to submit to queues where you do not have rights will result in your jobs being rejected  (not submitted at all)  or the job me be held idle in the queue indefinitely (until the job is killed). This my make it sound like using policies other then the default policy is a bad thing. However experimentation is encouraged because using different policies will give you access to nodes otherwise not available to your jobs, more nodes means more throughput of jobs faster.  At BNL there is for example across experiment policy which allows the use of other RHIC experiment nodes, but with sone limitations. Determining which policies are right for you can be determined by a combination of reading the documentation on the different  policies and experimentation (trial and error).

Additional Information for grid users:

The policy table also holds policy information about policies at other sites running the scheduler. The scheduler will forward and submit these jobs much in the same way as of the job where submitted locally. And all output described in your xml job description will be copied  back to your site just as it is done locally.

Note: Using policies on sites other then your own site requires that you have a valid grid certificate (or credentials) initialized for you account. 

What are the Options  for modifying jobs I have already submitted?

This syntax is used after submission for modifying already submitted jobs is below:

star-submit -[OPTION] [JobSelection] [SessionFile.xml]

All of the options are detailed in the file above. The session.xml will need to be passed to the scheduler in order to take advantage of these options. The session.xml file is generated by the scheduler (SUMS) in the same directory from which your job has been submitted. If you kill the scheduler before submitting the last job, the file will not be written. All of the other files needed for submitting the job can be deleted such as .list, .csh, .report, .condor, and .condorG, these will all be regenerated. For this reason, any changes made to any of these files will be over written when the file is submitted. The session.xml file is human readable but can be very long. The session.xml file holds all of the objects generated by the scheduler right after it has submitted all of your jobs. Simple changes can be made to the jobs by editing this file, however it is not encouraged or recommended. The session.xml files are also bound to the version of the scheduler you use. So it is important to use the same version of the scheduler that was used to generate the session.xml file in the first place when running any of these post submission commands.

The job selection range is also required. The range can be a comma delimitated list. An example of such a list is 1,5,7 this means only apply this option to jobs sched674C9FE5F9B298C9232688D49F5002DA_1 and sched674C9FE5F9B298C9232688D49F5002DA_5 and sched674C9FE5F9B298C9232688D49F5002DA_7. Alternatively a range of jobs can be used. For example 5-24 would apply to all jobs between 5 and 24. This includes job 5 and job 24. These options may not be mixed. For example 2-6,20,45 would NOT be valid. If you want  the option to apply to all jobs you have submitted the key word "all" can be used.

Is there a help option?

Yes, type star-submit -h

Levente Hajdu - page was last modified