Changes between Version 1 and Version 2 of WorkGeneration
- Timestamp:
- Apr 18, 2007, 2:06:03 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WorkGeneration
v1 v2 1 = Generating work = 2 1 3 As described earlier, a workunit represents the inputs to a computation. The steps in creating a workunit are: 2 4 … … 7 9 Once this is done, BOINC takes over: it creates one or more results for the workunit, distributes them to client hosts, collects the output files, finds a canonical result, assimilates the canonical result, and deletes files. 8 10 9 During the testing phase of a project, you can use the make_work daemon to replicate a given workunit as needed to maintain a constant supply of work. This is useful while testing and debugging the application. 10 Workunit and result template files 11 During the testing phase of a project, you can use the [http://boinc.berkeley.edu/busy_work.php make_work daemon] to replicate a given workunit as needed to maintain a constant supply of work. This is useful while testing and debugging the application. 12 13 == Workunit and result template files == 11 14 12 15 A workunit template file has the form … … 41 44 <file_info>, <file_ref>:: 42 45 43 Each pair describes an input file and the way it's referenced.46 Each pair describes an [http://boinc.berkeley.edu/files.php#file input file] and [http://boinc.berkeley.edu/files.php#file_ref the way it's referenced]. 44 47 45 48 <command_line>:: … … 49 52 <credit>:: 50 53 51 The amount of credit to be granted for successful completion of this workunit. Use this only if you know in advance how many FLOPs it will take. Your validator must use get_credit_from_wu() as its compute_granted_credit() function. 52 Other elements Work unit attributes 54 The amount of credit to be granted for successful completion of this workunit. Use this only if you know in advance how many FLOPs it will take. Your [http://boinc.berkeley.edu/validate_simple.php validator] must use get_credit_from_wu() as its compute_granted_credit() function. 55 56 Other elements:: 57 Work unit attributes 53 58 54 59 Workunit database records include a field, 'xml_doc', that is an XML-format description of the workunit's input files. This is derived from the workunit template as follows: … … 78 83 * <UPLOAD_URL/> is replaced with the upload URL. 79 84 80 Moving input files to the download directory 81 If you're using a flat download directory, just put input files in that directory. If you're using hierarchical upload/download directories, you must put each input file in the appropriate directory; the directory is determined by the file's name. To find this directory, call the C++ function85 == Moving input files to the download directory == 86 If you're using a flat download directory, just put input files in that directory. If you're using [http://boinc.berkeley.edu/hier_dir.php hierarchical upload/download directories], you must put each input file in the appropriate directory; the directory is determined by the file's name. To find this directory, call the C++ function 82 87 {{{ 83 88 dir_hier_path( … … 98 103 }}} 99 104 copies an input file from the test_workunits directory to the download directory hierarchy. 100 Creating workunit records 105 106 == Creating workunit records == 101 107 102 108 Workunits can be created using either a script (using the create_work program) or a program (using the create_work() function). The input files must already be in the download hierarchy. … … 133 139 infile_1 ... infile_m // input files 134 140 }}} 135 The program must be run in the project root directory. The workunit parameters are documented here. The -additional_xml argument can be used to supply, for example, <credit>12.4</credit>.141 The program must be run in the project root directory. The workunit parameters are documented [http://boinc.berkeley.edu/work.php here]. The -additional_xml argument can be used to supply, for example, <credit>12.4</credit>. 136 142 137 143 BOINC's library (backend_lib.C,h) provides the functions: … … 150 156 }}} 151 157 create_work() creates a workunit. The arguments are similar to those of the utility program; some of the information is passed in the DB_WORKUNIT structure, namely the following fields: 152 158 {{{ 153 159 name 154 160 appid 155 161 }}} 156 162 The following may be passed either in the DB_WORKUNIT structure or in the workunit template file: 157 163 {{{ 158 164 rsc_fpops_est 159 165 rsc_fpops_bound … … 167 173 max_total_results 168 174 max_success_results 169 170 Examples 171 Making one workunit 175 }}} 176 177 == Examples == 178 === Making one workunit === 172 179 173 180 Here's a program that generates one workunit (error-checking is omitted for clarity): … … 212 219 }}} 213 220 This program must be run in the project directory since it expects to find the config.xml file in the current directory. 214 Making lots of workunits 221 === Making lots of workunits === 215 222 216 223 If you're making lots of workunits (e.g. to do the various parts of a parallel computation) you'll want the workunits to differ either in their input files, their command-line arguments, or both.
