How to Create a Work Unit in BOINC - Project Report | CSCI 3350, Study Guides, Projects, Research of Software Engineering

Download How to Create a Work Unit in BOINC - Project Report | CSCI 3350 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! How to Create a Workunit in BOINC This document assumes the following:  You have properly installed & configured a BOINC server.  The server is running and you have access to it.  You have properly configured a project.  You have properly configured and added an application to the project.  You have properly configured both a workunit template and a result template. If - by some small miracle - all of the above are true, you are ready to start testing your BOINC project. To do this you will need something to test with. This is where the workunit steps in. In all probability your completed-and-fully-functional project will have a work generator that will create workunits as needed. For now, however, we will need to create workunits manually using the create_work utility provided by BOINC. How to Use create_work The create_work utility is a small & unassuming binary that resides in the projectname/bin directory. Its function is to add a row to the workunit table in the project database. Some of the information it add will be provided by the project – and some of it you will provide via arguments passed to create_work. Here's a description of create_work usage: Syntax: create_work -appname name -wu_name name -wu_template filename - result_template filename [arguments] [filename(s)] Required arguments: -appname name - specifies the name of the application that will complete the workunit. -wu_name name - specifies a name for the workunit. -wu_template filename - specifies the name of the workunit template file to use. filename must include the entire path relative to the project root (usually templates/filename). -result_template filename - specifies the name of the workunit template file to use. filename must include the entire path relative to the project root (usually templates/filename). Optional [arguments]: With the exception of -batch & -priority, the following list of arguments overlap some of the XML elements found in the workunit template. As the workunit template typically provides these, no description is given here. You may supply these arguments to create_work, specify them in the workunit template, or do neither – in which case the project defaults will be used. (n.b. allowing the default values to be used is a perfectly reasonable & recommended thing to do.) -batch n -priority n -command_line "-flags foo" -rsc_fpops_est n -rsc_fpops_bound n -rsc_memory_bound n -rsc_disk_bound n -delay_bound n -min_quorum n -target_nresults n -max_error_results n -max_total_results n -max_success_results n -additional_xml 'x' Optional [filename(s)]: While specifying input files is technically optional, you will probably need input files to do any useful work. Otherwise you project will be a bit trivial, no? Okay, so we acknowledge the need to tell our application what input files to use. This is done by listing the filenames in question at the end of the create_work command. This is done in the order they are referenced in the <file_info> section of the workunit template file ( <number>0..., <number>1..., etc.) Only the filename is required – no paths needed. Why no pathnames? Because ...