Changes between Initial Version and Version 1 of CompoundApps


Ignore:
Timestamp:
Apr 25, 2007, 8:53:49 AM (17 years ago)
Author:
Nicolas
Comment:

Converted by an automatic script

Legend:

Unmodified
Added
Removed
Modified
  • CompoundApps

    v1 v1  
     1= Compound applications =
     2
     3
     4== Compound applications ==
     5  A '''compound application''' consists of a '''main program''' and one or more '''worker programs'''. The main program executes the worker programs in sequence, and maintains a 'main state file' that records which worker programs have completed. The main program assigns to each worker program a subrange of the overall 'fraction done' range of 0..1. For example, if there are two worker programs with equal runtime, the first would have range 0 to 0.5 and the second would have range 0.5 to 1.   The BOINC API provides a number of functions, and in developing a compound application you must decide whether these functions are to be performed by the main or worker program. The functions are represented by flags in the BOINC_OPTIONS structure. Each flag must be set in either the main or worker programs, but not both.
     6
     7
     8{{{
     9struct BOINC_OPTIONS {
     10    int main_program;
     11    int check_heartbeat;
     12    int handle_trickle_ups;
     13    int handle_trickle_downs;
     14    int handle_process_control;
     15    int handle send_status_msgs;
     16    int direct_process_action;
     17};
     18
     19int boinc_init_options(BOINC_OPTIONS*);
     20}}}
     21
     22
     23 '''main_program'''::
     24        Set this in the main program.
     25 '''check_heartbeat'''::
     26        If set, the program monitors 'heartbeat' messages from the core client.     If the heartbeat stops, the result depends on the direct_process_action     flag (see below).
     27 '''handle_trickle_ups'''::
     28        If set, the program can send trickle-up messages.
     29 '''handle_trickle_downs'''::
     30        If set, the program can receive trickle-down messages.
     31 '''handle_process_control'''::
     32        If set, the program will handle 'suspend', 'resume', and 'quit'     messages from the core client.     The action depends on the direct_process_action flag.
     33 '''send_status_msgs'''::
     34        If set, the program will report its CPU time and fraction     done to the core client.  Set in worker programs.
     35 '''direct_process_action'''::
     36        If set, the program will respond to quit messages and heartbeat     failures by exiting, and will respond to suspend and resume     messages by suspending and resuming.     Otherwise, these events will result in changes to     the BOINC_STATUS structure,     which can be polled using boinc_get_status().
     37 '''all_threads_cpu_time'''::
     38        If set, the CPU of all threads (not just the worker thread)     will be counted.     For apps that do computation in more than one thread.
     39
     40
     41Typical main program logic is:
     42
     43
     44{{{
     45BOINC_OPTIONS options;
     46
     47options.main_program = true;
     48...
     49boinc_init_options(&options)
     50read main state file
     51for each remaining worker program:
     52    APP_INIT_DATA aid;
     53    boinc_get_init_data(aid);
     54    aid.fraction_done_start = x
     55    aid.fraction_done_end = y
     56    boinc_write_init_data_file(aid)
     57    run the app
     58    wait for the app to finish
     59        poll
     60    write main state file
     61    if last app:
     62        break
     63    boinc_parse_init_data_file()    // reads CPU time from app_init.xml file
     64boinc_finish()
     65}}}
     66 where x and y are the appropriate fraction done range limits.  Typical worker program logic is:
     67
     68
     69{{{
     70BOINC_OPTIONS options;
     71
     72options.main_program = false;
     73options.send_status_msgs = true;
     74...
     75boinc_init_options(&options);
     76...
     77do work, calling boinc_fraction_done() with values from 0 to 1,
     78and boinc_time_to_checkpoint(), occasionally
     79...
     80boinc_finish();        // this writes final CPU time to app_init.xml file
     81
     82}}}
     83  If the graphics is handled in a program that runs concurrently with the worker programs, it must also call boinc_init_options(), typically with all options false, then boinc_init_graphics(), and eventually boinc_finish().
     84
     85If the main program is responsible for reporting application status to the core client, it should periodically call
     86
     87
     88{{{
     89    boinc_report_app_status(
     90        double cpu_time,                // CPU time since start of WU
     91        double checkpoint_cpu_time,     // CPU time at last checkpoint
     92        double fraction_done
     93    );
     94}}}