[[PageOutline]] = Submitting jobs = To submit a job you must 1. Write XML 'template files' that describe the job's input and output files (typically the same template files can be used for many jobs). 1. "Stage" the job's input file(s) (see below). 1. Invoke a BOINC function or script that submits the job. Once this is done, BOINC takes over: it creates one or more instances of the job, distributes them to client hosts, collects the output files. It [ValidationIntro validates] and [AssimilateIntro processes] the results, and deletes the input and output files. Typically, steps 2) and 3) are done by a [WorkGeneration work generator] program that creates lots of jobs. == Input template files == An input template file has the form {{{ 0 [ ] [ ] [ ] [ ] [ ... ] [ ... ] [ ... ] [ ... ] [ ... other files ] 0 NAME [ ] [ ... other files ] [ -flags xyz ] [ x ] [ x ] [ x ] [ x ] [ x ] [ x ] [ x ] [ x ] [ x ] [ x ] }}} Elements and tags must be on separate lines as shown. The components are: '''''':: describes an [BoincFiles#Fileproperties input file]. '''''':: use 0, 1, ... '''''':: transfer the file in gzipped (compressed) format to reduce network usage. '''You must stage the file with the --gzip option (see below)'''. Only 7.0+ clients can handle compressed transfers; older clients will get the file in uncompressed form. '''''':: if present, the file remains on the client after job is finished. '''''':: if present, the file is not deleted from the server after job is completed. Use this if the file is used as input to more than one job. '''''':: if present, report file in each scheduler request (for sticky files) ''', , ''':: used only for "non-local" input files (see below) '''''':: describes [BoincFiles#Filereferences the way the file is referenced]. '''''':: 0, 1, etc. '''''':: the logical name of the file '''''':: if present, the file is copied into the job's slot directory '''''':: The command-line arguments to be passed to the main program. Note: if you're using the [WrapperApp BOINC wrapper], use in your job.xml file to pass command-line arguments from the wrapper to the wrapped application. '''''' etc.:: [JobIn Job attributes] such has how much disk space will be used. BOINC will supply reasonable defaults for these, but you should supply the correct values; otherwise, for example, BOINC might try to run the job on a host with insufficient disk space. Notes: * The input template is copied into a BLOB column of the workunit table and will substitute filenames, and have download urls, signatures and other elements inserted into your provided template. The total expanded BLOB cannot exceed 65,535 bytes. This is enough for about 200 input files, fewer if you use long file names are multiple download URLs. If this isn't enough, you can use [FileCompression BOINC file compression] to zip several files into a single file reference for download, and expanding them prior to running on the client machine. == Output template files == An output template file has the form {{{ 32768 result.sah [ 0|1 ] [ 0|1 ] [ 0|1 ] [ ] }}} Elements and tags must be on separate lines as shown. The elements include: '''''':: describes an output file. '''''':: the physical file name. Typically use , etc.; BOINC will replace this with a generated name based on the job name. '''''':: describes how an output file will be referenced by the application. '''''':: the "logical name" by which the application will reference the file. '''''':: if present, the file will be generated in the slot directory, and copied to the project directory after the job has finished. Use this for [WrapperApp legacy applications]. '''''':: always include this for output files. '''''':: maximum file size. If the actual size exceeds this, the file will not be uploaded, and the job will be marked as an error. '''''':: the URL of the file upload handler. You may include this explicitly, or use '''''' to use the URL in your project's config.xml file. '''''':: if 0 or absent, your application must create the file, otherwise the job will be marked as an error. '''''':: if true, don't include this file in the result validation process (relevant only if you are using the sample bitwise validator). '''''':: if present, the file will not be deleted on the server even after the job is finished. '''''':: if present, clients will report this job immediately after the output files are uploaded. Otherwise they may wait up to a day. (Implemented in 6.12.27+ clients only). Note: when a job is created, the name of its output template file is stored in the database. The file is read when instances of the job are created, which may happen days or weeks later. Thus, editing an output template file can affect existing jobs. If this is not desired, you must create a new output template file. You can safely remove an input template file after creating your last job with it. However, output template files must exist until any task that refers to it is completed (i.e. no more replicas will be created). In general, you should not attempt to use more then 50 files in your output template. This is because the provided template will have upload URLs, and file names expanded, and signatures added to it. The total size of the result must remain under 65,535 bytes to fit in the xml_doc_in and xml_doc_out BLOBs in the result table. Your actual limit on number of files will depend upon the length of your job names, and upload URLs. If your expanded output template is approaching the size limit, you can use [FileCompression BOINC file compression] to zip several files into a single file reference for upload, prior to completing each task on the client machine. Once you have run some jobs through your project, you can compare the size of the expanded xml with the 65,535 limit by running the following MySQL statement:[[BR]] {{{select max(length(xml_doc_in)), max(length(xml_doc_out)) from result;}}}[[BR]] Note that here "_in" and "_out" are both references to the output template. "_in" being when the task was created, and "_out" how it looked, with actual file sizes and checksums, at the time the task was returned. So don't confuse these column names with the "input" and "output" templates. == Staging input files == Input files may be "local" (resident on the project server) or "non-local". For local files, BOINC fills in the download URL, the file size, and the MD5. For non-local files, you must supply these yourself in the input template. You can supply multiple URLs if the file is on multiple data servers. === Staging local input files === Before submitting a job, you must '''stage''' its local input files using {{{ bin/stage_file [--gzip] [--copy] file }}} --gzip:: send the file in compressed form to 7.0+ clients. Note: you must also include the '''''' attribute for this file in the job's input template (see above). --copy:: copy the file from its current location to the BOINC download directory. The default is to move it. Note: '''stage_file''' was added to the BOINC trunk on 16 Oct 2012. If your server code is older than that, use {{{ cp test_files/12ja04aa `bin/dir_hier_path 12ja04aa` }}} == Submitting a job on the command line == #creatework-tool '''create_work''' is a command-line tool for submitting jobs. Run it from the project root directory. {{{ create_work [ arguments ] infile_1 ... infile_n }}} Mandatory arguments are: --appname name:: application name Optional arguments are: --wu_name name:: workunit name (default: appname_PID_TIME) --wu_template filename:: WU template filename relative to project root; usually in templates/. Default: templates/appname_in. --result_template filename:: result template filename, relative to project root; usually in templates/. Default: templates/appname_out. --batch n:: --priority n:: high values are assigned before low values; see --priority_order and --priority_order_create_time options on the [BackendPrograms#feeder feeder] The following [JobIn job parameters] may be passed in the input template, or as command-line arguments to create_work; the input template has precedence. If not specified, the given defaults will be used. --command_line "-flags foo":: --rsc_fpops_est x:: FLOPs estimate; default 3600e9 --rsc_fpops_bound x:: FPOPs bound; default 86400e9 --rsc_memory_bound x:: default 5e8 --rsc_disk_bound x:: default 1e9 --rsc_bandwidth_bound x:: 0 (no bound) --delay_bound x:: default 1 week --min_quorum x:: default 2 --target_nresults x:: default 2 --max_error_results x:: default 3 --max_total_results x:: default 10 --max_success_results x:: default 6 --opaque N:: --additional_xml 'x':: This can be used to supply, for example, 12.4. == Submitting jobs from a C++ program == #cpp-workgen BOINC's library provides a function for submitting jobs: {{{ int create_work( DB_WORKUNIT& wu, const char* wu_template, // contents, not path const char* result_template_filename, // relative to project root const char* result_template_filepath, // absolute or relative to current dir const char** infiles, // array of input file names int ninfiles SCHED_CONFIG&, const char* command_line = NULL, const char* additional_xml = NULL ); }}} The ''name'' and ''appid'' fields of the DB_WORKUNIT structure must always be initialized. Other job parameters may be passed either in the DB_WORKUNIT structure or in the input template file (the latter has priority). On a successful return, wu.id contains the database ID of the workunit.