Results

A result describes an instance of a computation, either to be performed, in progress, or completed. Results are stored in the result table of the BOINC DB. The attributes of a result include:

• The name of the result (unique across all results in the project).
• The name of the associated workunit.
• The time when the completed result should be reported to a scheduling server. This is assigned by the project, and is used by clients to prioritize operations and to initiate scheduler RPCs. There is no guarantee that the result will actually be reported by this time.
• An XML document listing the names of its output files; see below.
• An XML document giving the sizes and checksums of its output files (filled in after the result is completed).
• The stderr output of the result.
• The host that computed the result.
• The times when the result was dispatched and received.
• The exit status of the application.
• The reported CPU time.
• Its state. Values include:
  • Inactive (not ready to dispatch)
  • Unsent (ready to dispatch, but not dispatched)
  • In progress (dispatched, not done)
  • Done successfully
  • Timed out
  • Done with error

Results are normally created using the create_work utility.

The XML document listing the output files has the form:

<file_info>...</file_info>
[ ... ]
<result>
    <name>foobar</name>
    <wu_name>blah</wu_name>
    <exit_status>blah</exit_status>
    <file_ref>...</file_ref>
    [ ... ]
</result>

• The <name> element is the result name.
• The <wu_name> element is the workunit name.
• Each <file_ref> element is an association to an output file, described by a corresponding <file_info> element.

The XML document describing the sizes and checksums of the output files is just a list of <file_info> elements, with the nbytes and md5_cksum fields present. The project back end must parse this field to find the locations and checksums of output files.

Several results may be associated with a single workunit. Results may be generated in either of two ways (selected as part of the application):

• Advance generation of results. One or more result records are stored in the database when the workunit is produced. The scheduling server dispatches each result to a single participant host. When all result records have been dispatched, participants hosts are "turned away".
• On-demand generation of results. The application specifies a "result template", which has place-holder tokens for the output filenames. The scheduling server, in response to a host request, generates a new result record and sends the result template. The host generates unique output filenames, and returns them along when it the computation is done.