This is the main terminology used in RADICAL-Pilot (RP)’s documentation and application programming interface.


Workloads are sets of tasks. RP assumes no priority among the tasks of a workload, i.e., workloads are different from workflows. RP makes no assumption about when tasks of a workload are provided. RP schedules, places and launches the tasks that are available at the moment in which resources are available. For RP, it makes no difference if new tasks arrive while other tasks are executing.


Tasks are self-contained portions of an application which RP can execute independently of each other. Those tasks are usually application executables (such as Gromacs or NAMD) whose execution is further parameterized by command line arguments, input files, environment settings, etc. But those tasks can also be individual function calls or small snippets of Python code. In that case, the execution is parameterized by function arguments, Python execution context, etc.

It is important to note that RP considers tasks independent, i.e., they don’t execute with a shared memory space.

For more details, see the API documentation


As an abstraction, a pilot is a placeholder for resources on a given platform and is capable of executing tasks of a workload on those resources. As a system, pilot is a type of middleware software that implements the pilot abstraction.

RP is a pilot system, capable of: (1) acquiring resources by submitting jobs to HPC platforms; (2) managing those resources on the user’s (or application’s) behalf; and (3) executing sets and sequences of Tasks on those resources.

Usually, applications written with RP: (1) define one or more pilots; (2) define the HPC platform where each pilot should be submitted; (3) the type and amount of resources that each pilot should acquire on that resource; and (3) the time for which each pilot’s resources should be available (i.e., walltime). Once each pilot is defined, the application can schedule Tasks for execution on it.