Compute Allocations & Application Execution ============================================== A LEXIS Platform Project can be associated with one or more specific compute allocations provided by participating HPC or Cloud sites. A compute allocation represents a defined amount of computing capacity on a given infrastructure. For an HPC system, this is typically expressed as CPU node-hours, GPU node-hours, core-hours, or another accounting unit used by the provider. For example:: LEXIS Platform Project: ClimateSimulation | +-- IT4I HPC allocation | 50,000 CPU node-hours | valid until 2027-03-31 | +-- Site B GPU allocation 10,000 GPU-hours valid until 2026-12-31 The allocation is therefore not an abstract computing resource. It represents a concrete entitlement to use a particular provider infrastructure under a defined accounting project, quota, and validity period. Project & Allocation Relationship ----------------------------------- Compute allocations are associated directly with a LEXIS Platform Project. The project defines the collaboration and authorisation context, while each allocation defines how much compute capacity that project can consume at a particular provider. Conceptually:: LEXIS Platform Project | +-- Compute Allocation A | provider: Site A | system: HPC Cluster A | accounting project: PRJ123 | capacity: 50,000 node-hours | +-- Compute Allocation B provider: Site B system: GPU Cluster B accounting project: GPU456 capacity: 10,000 GPU-hours A single LEXIS Platform Project can have allocations on multiple HPC or Cloud systems. This allows one project to execute workflows across several providers while keeping all allocations within the same project context. Conversely, access to an HPC system does not imply access to all allocations available on that system. A user can consume only allocations associated with a LEXIS Project for which the user has the required authorisation. An allocation typically contains or refers to: * infrastructure provider; * target HPC or Cloud system; * provider-side accounting project or account; * allocation type and accounting unit; * allocated and optionally consumed compute capacity; * validity period; * permitted queues, partitions, or hardware classes; * provider-specific restrictions. The provider remains authoritative for the actual accounting of consumed compute time. Allocation Resolution during Job Execution ------------------------------------------ Every computational job is executed in the context of a LEXIS Platform Project. Before a job is submitted, the platform determines which allocation associated with that project is applicable to the selected execution system. The execution path is conceptually:: User / Workflow | v LEXIS Platform Project | v Selected Project Allocation | v HEAppE / Execution Adapter | v Provider Accounting Project | v HPC Scheduler | v Compute Nodes For HPC execution through HEAppE, the selected allocation determines the provider-side project or accounting context under which the job is submitted. The local scheduler performs the final scheduling and accounting. Consumed CPU time, GPU time, node-hours, or other resources are charged against the provider allocation according to the site's accounting rules. The LEXIS Platform therefore coordinates the relationship between: * the LEXIS Platform Project requesting the computation; * the specific provider allocation available to that project; * the identity under which the job is submitted; * the provider-side accounting project; * the application being executed. The actual calculation of consumed compute time remains the responsibility of the infrastructure provider. Multiple Allocations -------------------- A LEXIS Platform Project can contain multiple compute allocations. These allocations may differ by: * provider; * HPC system; * CPU or GPU architecture; * allocation size; * accounting project; * validity period; * permitted workload type. For example:: LEXIS Project | +-- Site A / CPU partition / 100,000 node-hours | +-- Site A / GPU partition / 5,000 GPU-hours | +-- Site B / CPU cluster / 30,000 node-hours A workflow can execute different tasks using different allocations belonging to the same project. For example:: Input Dataset | v Preprocessing (Site A CPU allocation) | v Simulation (Site A GPU allocation) | v Postprocessing (Site B CPU allocation) | v Result Dataset This enables multi-site workflows while preserving explicit control over which project allocation is consumed by each computation. Applications & Allocations ---------------------------- An application defines the workload that can be executed, while an allocation defines the compute capacity available to the project. Typical application models include: * HPC command applications based on predefined HEAppE command templates; * containerised HPC applications; * custom job scripts where permitted by the provider; * container workloads executed on Kubernetes or Cloud infrastructure. Applications and allocations are intentionally separate concepts. An application can potentially execute using multiple allocations if the corresponding infrastructures provide a compatible execution environment. Likewise, a single allocation can be used to execute multiple applications. Conceptually:: Application + Project Allocation + Input Parameters / Data | v Job Execution A workflow task therefore specifies or resolves both the workload to execute and the project allocation that provides the required compute capacity. Allocation Lifetime & Availability ------------------------------------ Compute allocations are normally finite. An allocation can become unavailable because: * its validity period has expired; * its compute-time budget has been exhausted; * the provider has disabled the accounting project; * the relevant queue or partition is unavailable; * the allocation has been removed from the LEXIS Platform Project. Project membership alone is therefore not sufficient to guarantee that a job can be executed. For a computation to proceed, the user must be authorised for the LEXIS Platform Project and the project must have a valid allocation applicable to the selected execution infrastructure. The resulting model is:: User | | authorised for v LEXIS Platform Project | | associated with v Specific Compute Allocation | | consumed through v Application / Workflow Job | | accounted by v Infrastructure Provider