BUDA implementation

On the server, there is a single BOINC app for BUDA; let's call it 'buda'. This has app versions for the various platforms (Win, Mac, Linux) Each app version contains the Docker wrapper built for that platform.

The set of BUDA science apps and variants is stored in a directory hierarchy of the form

project/buda_apps/
    <sci_app_name>/
        desc.json
        intel_cpu/
            variant.json
            ... files
        arm_cpu/
            variant.json
            ... files
        <plan_class>/
            ... files
        ...
    ...

The apps's desc.json file contains its input and output filenames, keywords, and so on.

Each science app variant is a collection of files:

User-supplied files:

• A Dockerfile
• a config file, job.toml
• A main program or script
• Other files

... and generated files:

• variant.json, has info about the variant.

This is similar to BOINC's hierarchy of apps and app versions, except:

• It's stored in a directory hierarchy, not in database tables
• Science app variants are not associated with platforms (since we're using Docker).
• It stores only the current version, not a sequence of versions (that's why we call them 'variants', not 'versions').

Validation and assimilation

Currently:

• BUDA uses the 'trivial validator': any successful instance is assumed to be correct. Replication-based validation could potentially be added, using the script-based framework; each science app could specify the names of validator and assimilator scripts.

• BUDA uses the 'batch collect paradigm' for output files (i.e. the batch_collect assimilator) to make it compatible with BOINC's web interfaces. This could potentially be extended to allow per-app assimilators.

Job-submission interfaces to BUDA

BOINC provides a web interface for managing BUDA apps and submitting batches of jobs to them. Other interfaces are possible; e.g. we could make a Python-based remote API that could be used to integrate BUDA into other batch systems.