BUDA apps

BUDA is BOINC's system for running jobs using Docker. BUDA is available on BOINC Central and other BOINC projects. In the following, we'll assume that you have an account with job submission permissions on BOINC Central, and that you're logged into your account on a browser.

BUDA applications are called 'science apps'. Each has a name, like 'worker' or 'autodock', and can have 'variants' that use different types of computer hardware. When you submit a job, you specify the science app but not the variant. When the BOINC scheduler sends the job to a volunteer host, it picks the variant that's best for that host.

A variant has two attributes:

• CPU type: Intel x64 or ARM64
• [Plan class](plan classes): this can represent various things: whether the variant uses a GPU (and if so, what type and using what library); whether the variants uses multiple CPU cores, and so on.

At first you'll typically use a variant for x64 and plan class cpu (single CPU).

Prepare application files

A variant consists of several files:

• A Dockerfile, which describes your app's software environment. For example:

# The base image, possibly including some pre-installed software
# This one includes Python
FROM python:3.13-slim

# commands to install other dependencies
RUN pip install --no-cache-dir requests
RUN apt update
RUN apt install libboost-all-dev

# you must include the following line
WORKDIR /app

# include the following if the app takes cmdline args
ENV ARGS=""

# command to run app's main program or script
CMD /bin/sh ./main.sh ${ARGS}

• Other app files, such as the executables.

For ARM variants you'll need an ARM version of your executable, and a Dockerfile that uses an ARM base image.

Command-line arguments are available in the container in the environment variable ARGS. You can access them from a C program using getenv(), or from a shell script as $ARGS.

Note: when the container runs, the app files and input files will be in the working directory. The Dockerfile should not use COPY to put them there.

Use filenames that encode the file's precise purpose. For example, a Dockerfile might be named dockerfile_appname_intel_cuda_3, where appname is your app name, cuda is a plan class for NVIDIA/CUDA GPUs, and 3 is a version number.

Upload files to your sandbox

The BUDA tools use the User file sandbox for uploading files to the BOINC server. To access it, go to Job submission / File sandbox in the menu bar.

Click Add files, and upload the above files.

Create a science app

On BOINC Central, go to Job submission / Manage batches and apps. Click Manage BUDA apps and variants. Click Add science app. Fill out the form and click OK.

The form is mostly self-explanatory except perhaps:

• Input file names: the names that will be given to input files in the Docker container. If your executable takes input file names on the command line, e.g. --infile foo, pass this command line to each job (see BUDA job submission). If your executable takes input from stdin, use as your main program a shell script that does e.g. prog.exe < foo.

Create a variant

You this point you should be on the science app page. If not, go to Job submission / Manage batches and apps. Click Manage BUDA apps and variants. Click App details for your app.

On the science app page. click Add variant. This leads to a form where you select:

• The processor type (Intel or ARM)
• A plan class name (leave it blank for 1-CPU variants)
• a Dockerfile (from your file sandbox).
• A set of 'app files'. This includes:
  • a main program to run in the container
    • other app files if needed

fill out the form, and click OK.

Submitting jobs

Once you've created a BUDA science app and variant, you can [submit jobs](BUDA job submissions) to it.