Changes between Version 51 and Version 52 of WrapperApp


Ignore:
Timestamp:
May 11, 2011, 9:35:37 PM (13 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WrapperApp

    v51 v52  
    8383 * The job file may be slightly different for different platforms (i.e. app_versions) due to directory requirements (exec_dir) and environment variables (setenv) required.  You will therefore want to make and track different versions for each app_version you are supporting.
    8484
    85 == Physical file management ==
    86 
    87 You can use the wrapper together with [PhysicalFileManagement physical file management],
    88 where you directly access files in your project directory.
    89 For example, you could create a job whose first task unpacks a zip file
    90 into the project directory,
    91 and whose subsequent tasks access these files.
    92 
    93 The support for this is:
    94 
    95  * If a worker program name begins with "$PROJECT_DIR", that substring is replaced with the project directory, and the name is treated as a physical name.
    96  * In task command lines, "$PROJECT_DIR" is replaced with the project directory.
    97 
    98 == Graphics ==
    99 
    100 You can include a [GraphicsApi graphics app] with a wrapper-based application.
    10185
    10286== Example ==
    10387
    104 Here's an example that shows how to use the wrapper.
     88Assume you have an executable program for a particular platform
     89(say "worker_windows_intelx6_0.exe" for Win32).
     90The program reads from '''infile''' and writes to '''outfile'''.
     91
    10592We assume that you have already [MakeProject created a project]
    106 with root directory PROJECT/,
    107 and that you have an executable program for a particular target platform
    108 (say "worker_windows_intelx6_0.exe" for Win32)
    109 
    110  * Download the wrapper for the target platform (see links above) to your server.
    111  * [AppVersion Create an application] named 'worker' and a corresponding directory
    112   'PROJECT/apps/worker'. In this directory,
    113   create a directory 'wrapper_windows_intelx86_22420.exe'.
    114   Put the files 'wrapper_windows_intelx86_22420.exe',
    115   and 'worker_windows_intelx86_0.exe' there.
    116    Rename the latter file to 'worker=worker_windows_intelx86_0.exe'
    117    (this gives it the logical name 'worker').
    118  * In the same directory, create a file 'job.xml=job_1.12.xml'
    119   (1.12 is a version number) containing
     93with root directory PROJECT/.
     94Now
     95 * Download the wrapper for Win32 (see links above) to your server
     96  .Assume the filename is '''wrapper_windows_intelx86_22420.exe'''.
     97 * [AppVersion Create an application] named 'worker'.
     98 * Create the directory hierarchy
     99{{{
     100apps/
     101   worker/
     102      1.0/
     103         windows_intelx86/
     104}}}
     105 * Put the files '''wrapper_windows_intelx86_22420.exe'''
     106  and '''worker_windows_intelx86_0.exe''' in the bottom directory.
     107 * In the same directory, create a file '''worker_job_1.0.xml'''
     108  (1.0 is a version number) containing
    120109{{{
    121110<job_desc>
    … …  
    128117</job_desc>
    129118}}}
    130  This file (which has logical name 'job.xml' and physical name 'job_1.12.xml') is read by 'wrapper'; it tells it the name of the worker program, what files to connect to its stdin/stdout, and a command line.
     119 * In the same directory, create a file '''version.xml''' containing
     120{{{
     121<version>
     122   <file>
     123      <physical_name>wrapper_windows_intelx86_22420.exe</physical_name>
     124      <main_program/>
     125   </file>
     126   <file>
     127      <physical_name>worker_windows_intelx86_0.exe</physical_name>
     128      <logical_name>worker</logical_name>
     129   </file>
     130   <file>
     131      <physical_name>worker_job_1.0.xml</physical_name>
     132      <logical_name>job.xml</logical_name>
     133   </file>
     134</version>
     135}}}
    131136 * In the 'PROJECT/templates' directory create a workunit template file called 'worker_wu':
    132137{{{
    133138<file_info>
    134139    <number>0</number>
    135 </file_info>
    136 <file_info>
    137     <number>1</number>
    138140</file_info>
    139141<workunit>
    140142    <file_ref>
    141143        <file_number>0</file_number>
    142         <open_name>in</open_name>
     144        <open_name>infile</open_name>
    143145        <copy_file/>
    144146    </file_ref>
    145     <file_ref>
    146         <file_number>1</file_number>
    147         <open_name>stdin</open_name>
    148     </file_ref>
    149     <rsc_fpops_bound>1000000000000</rsc_fpops_bound>
    150     <rsc_fpops_est>1000000000000</rsc_fpops_est>
     147    <rsc_fpops_bound>1e12</rsc_fpops_bound>
     148    <rsc_fpops_est>1e14</rsc_fpops_est>
    151149</workunit>
    152150}}}
    … …  
    155153<file_info>
    156154    <name><OUTFILE_0/></name>
    157     <generated_locally/>
    158     <upload_when_present/>
    159     <max_nbytes>5000000</max_nbytes>
    160     <url><UPLOAD_URL/></url>
    161 </file_info>
    162 <file_info>
    163     <name><OUTFILE_1/></name>
    164155    <generated_locally/>
    165156    <upload_when_present/>
    … …  
    170161    <file_ref>
    171162        <file_name><OUTFILE_0/></file_name>
    172         <open_name>out</open_name>
     163        <open_name>outfile</open_name>
    173164        <copy_file/>
    174     </file_ref>
    175     <file_ref>
    176         <file_name><OUTFILE_1/></file_name>
    177         <open_name>stdout</open_name>
    178165    </file_ref>
    179166</result>
    … …  
    192179input input2
    193180}}}
    194  to generate a workunit. The input files in the 'create_work' command must be in the same order as in the workunit template file (worker_wu). Otherwise the client will generate errors when processing the workunit.
    195 
    196 To understand how all this works: at the beginning of execution, the file layout is:
    197 
    198 ||'''Project directory'''||'''slot directory'''||
    199 ||input||in (copy of project/input)||
    200 ||job_1.12.xml||job.xml (link to project/job_1.12.xml)||
    201 ||input2||stdin (link to project/input2)||
    202 ||worker_nodelete_0||stdout (link to project/worker_nodelete_0)||
    203 ||worker_5.10_windows_intelx86.exe||worker (link to project/worker_5.10_windows_intelx86.exe)
    204 ||wrapper_5.10_windows_intelx86.exe||wrapper_5.10_windows_intelx86.exe (link to project/wrapper_5.10_windows_intelx86.exe) ||
    205 
    206 The wrapper program executes the worker, connecting its stdin to project/input2 and its stdout to project/worker_nodelete_0.
    207 
    208 The worker program opens 'in' for reading and 'out' for writing.
    209 
    210 When the worker program finishes, the wrapper sees this and exits.
    211 Then the BOINC core client copies slot/out to project/worker_nodelete_1.
     181to generate a workunit.
     182
     183== Physical file management ==
     184
     185You can use the wrapper together with [PhysicalFileManagement physical file management],
     186where you directly access files in your project directory.
     187For example, you could create a job whose first task unpacks a zip file
     188into the project directory,
     189and whose subsequent tasks access these files.
     190
     191The support for this is:
     192
     193 * If a worker program name begins with "$PROJECT_DIR", that substring is replaced with the project directory, and the name is treated as a physical name.
     194 * In task command lines, "$PROJECT_DIR" is replaced with the project directory.
     195
     196== Graphics ==
     197
     198You can include a [GraphicsApi graphics app] with a wrapper-based application.
    212199
    213200== !GenWrapper: A more general BOINC wrapper ==