Version 4 (modified by davea, 10 years ago) (diff)


Result assimilation

Projects must create one assimilator program per application. This is done by linking the program sched/assimilator.C with an application-specific function of the form

int assimilate_handler(
    WORKUNIT& wu, vector<RESULT>& results, RESULT& canonical_result

This is called when either

  • The workunit has a nonzero error mask (indicating, for example, too many error results). In this case the handler might write a message to a log or send an email to the application developer.
  • The workunit has a canonical result. In this case wu.canonical_resultid will be nonzero, canonical_result will contain the canonical result. Your handler might, for example, parse the canonical result's output file and write its contents to a separate database.

In both cases the 'results' vector will be populated with all the workunit's results (including unsuccessful and unsent ones). All files (both input and output) will generally be on disk.

It's possible that both conditions might hold.

The return values of assimilate_handler() are:

  • 0: the workunit will be marked as assimilated.
  • DEFER_ASSIMILATION: the workunit will not be marked as assimilated, and will be processed again when the next instance finishes. This is useful for appliations where you want to see all the completed results.
  • Other nonzero values: the assimilator will log an error message and exit. Typically the function should return nonzero for any error condition. This way the system administrator can fix the problem before any completed or erroneous workunits are mis-handled by BOINC.

You can use BOINC's back-end utility functions to get file pathnames and open files.