BUDA job submission

BUDA science apps and variants

We call BUDA applications 'science apps'. Each science app has a name, like 'worker' or 'autodock'. A science app can have multiple 'variants' that can use different types of computer hardware. The name of a variant is 'cpu' if it uses a single CPU. Otherwise it's the name of a plan class. There might be variants for 1 CPU, for N CPUs, and for various GPU types.

User file sandbox

Managing science apps and variants.

In the menu bar of the BOINC project's web site, select Computing / Job Submission. Then click on BUDA This shows a list of existing science apps and their variants. You can

• add or delete a variant
• add or delete a science app
• submit jobs to a variant

Adding a variant

The form for adding a variant includes

• A plan class name (leave blank if CPU app)
• Select (from your file sandbox) a set of 'app files'. This includes:
  • a Dockerfile
  • a main prog to run in the container
  • other files if needed
• list of input files names
• list of output files names

Submitting jobs

The form for submitting a batch of jobs asks you to select (from the file sandbox) a zip file of job descriptions. This file has one dir per job:

jobname1/
    [cmdline]
    file1
    file2
    ...
jobname2/
...

The file names in each job directory must match the variant's list of input file names.

Monitoring a batch

When you submit a batch of jobs, you end up at a web page showing you the status of the batch. This shows you, among other things, how many of the jobs have completed. Reload it to update this information.

You can click on a job to see its status (and if it failed, the stderr output). You can view or download its input files.

On the batch path, you can click to download a zip file of the output files of all completed jobs.

When you're done with the batch, you can 'retire' it. This removes its intput and output files from the server.