github ornladios/ADIOS2 v2.13.0-rc1
on GitHub

pre-release4 hours ago

What's new in v2.13.0

BP4/BP5 readers no longer wait on files left open by a killed writer

A BP4 or BP5 writer marks its file as being written until it closes it. A writer that
is killed (for example at the end of a batch job's time limit) leaves that mark
behind, and readers used to wait forever in BeginStep() for steps that would
never come. BP4 and BP5 readers now ignore the mark by default (new parameter
IgnoreActiveFlag, default true): they read the steps that are present and
then get EndOfStream. BP5's OpenTimeoutSecs now also defaults to 0 in
Read mode (as BP4's already did), so opening a file that does not exist
fails right away instead of waiting for up to an hour.

This changes how a file that is still being written can be followed. Use the
FileStream engine, which sets IgnoreActiveFlag=false and waits up to an
hour for the file to appear, or set IgnoreActiveFlag=false (and an
OpenTimeoutSecs) on a BP4 or BP5 reader. adios_reorganize keeps following
files that are being written; it now warns when such a file stops producing
steps, and --ignore-active-flag makes it process the steps that are present.

Native DAOS engine

The DAOS engine now keeps all bulk data in DAOS objects, reading and writing
through the DAOS array API rather than through POSIX files on a dfuse mount.
Earlier releases shipped only a prototype that placed metadata in DAOS and wrote
data as files. Each writer rank writes its own DAOS array, with no cross-rank
aggregation, and issues asynchronous writes as its buffer fills, so transfers
overlap the remaining Put calls of the step. Per-rank, per-step metadata is
stored in DAOS as well; only the small rank-0 index and format files remain in
the dataset directory. On reads, a selection that does not match the writer's
decomposition fetches only the bytes it needs, batched into a few large DAOS
requests. Select it with io.SetEngine("daos"), and set DAOS_POOL and
DAOS_CONT on every rank. See the DAOS engine documentation for build
requirements, parameters and current limitations.

Campaign HDF5 reads over HTTPS and S3

The Campaign Reader can now read HDF5 dataset values from HTTPS and S3
objects without downloading the complete object. A read-only HDF5 virtual file
driver maps HDF5 byte requests to ADIOS2 transports, while the HDF5 metadata
surrogate embedded in the campaign remains the primary file for discovery and
small values. Individual HDF5 objects and HDF5 members in indexed TAR objects
are supported, including multistep and hyperslab selections.

Leaner default build for packagers

Several rarely used, unmaintained engines are now off by default:
DataMan, MHS, SSC, and DataSpaces, along with the DDN IME
transport. SSC gains a dedicated ADIOS2_USE_SSC option (previously it
was always built alongside MPI); the others switch from AUTO to OFF.
ZeroMQ, required only by the DataMan engine, is likewise off by default,
so a default build no longer probes for or links it. Any of these can still be
enabled explicitly (for example -DADIOS2_USE_MHS=ON). See the new "Notes for
Packagers" section of the README for the recommended feature tiers.

Thread-Safe Get with GetContext

A new GetContext API extends the Selection-based Get() to support
concurrent read pipelines on a single engine. Each caller allocates its own
GetContext via Engine::NewGetContext() and uses it as the first
argument to Get() and PerformGets(); per-context queues mean two
threads can drive independent Get batches against the same open engine
without racing. 

auto ctx = engine.NewGetContext();
if (ctx) {
    engine.Get(*ctx, var, data, adios2::Selection::BoundingBox(start, count));
    engine.PerformGets(*ctx);
}

NewGetContext() returns nullptr when the engine does not support
concurrent contexts; callers feature-probe with the null check. Currently
only the BP5 reader supports them, and only when opened in
Mode::ReadRandomAccess with a reentrant file transport (POSIX). See the
Selection chapter for full details.

Collective reader engine selection

When a reader does not set an engine explicitly, the engine type is
auto-detected from the filesystem. That probing now happens on rank 0 and is
broadcast, instead of every rank issuing its own stat() calls. If nothing
exists at the given location, IO::Open now fails collectively with a clear
error (and a hint to call SetEngine for a stream that has not been created
yet) rather than selecting BP3 and hanging the non-root MPI ranks.

SST Mercury Data Plane

A new Mercury data plane for SST uses the Mercury/margo RPC framework
to carry data, supporting multiple network backends through a single
implementation: cxi:// for HPE-Cray Slingshot (Frontier, Perlmutter),
ofi+tcp / ofi+verbs for libfabric-based fabrics, bmi+tcp, and
na+sm for shared memory. The backend is selected at runtime via the
MercuryProtocol engine parameter, with an SST_MERCURY_PROTOCOL
environment-variable fallback. On Slingshot, the required OFI auth key is
supplied automatically from SLINGSHOT_VNIS. See the SST engine
documentation for details.

Reader-defined derived variables

A read IO can now define a derived expression over a file's variables that were
never marked derived at write time: IO::DefineReaderDerivedVariable(name, expression), then InquireVariable/Get after Open. The reader computes
it from the file data. BP5 only; inputs must be same-shaped global arrays.
C++, C, Fortran, Python.

Derived expressions: attribute and scalar inputs

Derived expressions can now use single-value (scalar) variables and numeric
attributes alongside array inputs. A scalar variable broadcasts its per-step
value across the array inputs (pressure * dt). @name references the
single-element numeric attribute name; its current value is read at each
evaluation, so modifiable attributes take effect step by step. A binding with
a numeric right-hand side defines a named constant (c = 2.99792458e8).
Variable names containing special characters are referenced through binding
lines (x = sim/data.Ux) or inline backticks (`sim/Ux` + 1), and
/ in a formula always means division.

JIT fusion for derived expressions

Element-wise derived expressions over float or double arrays (+, -,
*, /, negate, sqrt, including ^2 by strength reduction) can be
JIT-compiled into a single fused vector loop via the bundled dill library's
new 128-bit vector API, typically 3-4x faster than the interpreter and within
a few percent of natively compiled code. Results are bit-identical to the
interpreter. Opt-in for now via the DerivedFuse environment variable;
expressions the fuser cannot handle fall back to the interpreter, as do
builds without dill >= 4.0.

Missing min/max reported as N/A

Variables stored without statistics (StatsLevel=0) now report an unset
range (Min() > Max()) instead of a misleading 0/0; bpls prints
N/A.

Pull requests included

New Contributors

Full Changelog: v2.12.0...v2.13.0-rc1

Check out latest releases or
releases around ornladios/ADIOS2 v2.13.0-rc1

Don't miss a new ADIOS2 release

NewReleases is sending notifications on new releases.

Get notifications