Function select_backend 

pub fn select_backend(work_items: usize) -> ComputeBackend

The backend-selection policy — one named function, so a reader can find the rule instead of hunting for scattered if n > 1024 tests.

The rule

Given work_items, the number of independent items a kernel will process:

1. If work_items >= GPU_MIN_WORK_ITEMS and the GPU is available, use ComputeBackend::Gpu.
2. Otherwise if work_items >= CPU_MULTI_MIN_WORK_ITEMS and the parallel feature is on, use ComputeBackend::CpuMulti.
3. Otherwise use ComputeBackend::Serial.

Arguments

• work_items — count of independent work items (cells, faces, roots, quadrature points). Dimensionless. Pass the honest count: passing a matrix’s row count when the kernel actually loops over its faces will pick the wrong backend.

Returns

A backend that is guaranteed available, so the caller may use it directly without a further ComputeBackend::resolve.

Why a caller might not use this

Benchmarks and parity gates need to run a named backend regardless of size — that is what ComputeBackend::resolve is for. This function is for production callers that just want the fastest correct option.

Example

use outram_foam_basic_lib::compute::{select_backend, ComputeBackend};

// A tiny problem always runs serially, whatever features are enabled.
assert_eq!(select_backend(16), ComputeBackend::Serial);

// Whatever it picks for a large problem is guaranteed to be runnable.
assert!(select_backend(1_000_000).is_available());