Skip to content

ADIOS v2.8.0 Production Release
Compare
Choose a tag to compare
@chuckatkins chuckatkins released this 29 Mar 11:54
· 66 commits to release_28 since this release
v2.8.0
8121b20
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Summary

This is a major production release with a variety of new features and bug fixes.

Changes to the API

  • adios2::Mode::ReadRandomAccess mode is introduced for reading files with access to all steps. BeginStep/EndStep calls are NOT allowed. SetStepSelection() can be used to access specific steps in the file.
  • adios2::Mode::Read mode now requires using BeginStep/EndStep loop to access steps serially one by one. Variable inquiry fails outside BeginStep/EndStep sections. You need to modify your Open() statement to use the random-access mode if your code is accessing all steps in an existing file. Technically, this is only true for the new BP5 files, you can still read BP3/BP4/HDF5 files with your existing code but keep in mind that your code is not going to work when moving to BP5.
  • adios2::ADIOS::EnterComputationBlock(), adios2::ADIOS::ExitComputationBlock() are hints to ADIOS that a process is in a computing (i.e. non-communicating) phase. BP5 asynchronous I/O operations can schedule writing during such phases to avoid interfering with the application’s own communication.
  • GPU-aware I/O supports passing device-memory data pointers to the Put/Get functions, and ADIOS2 will automatically download/upload data from/to the device during I/O. Alternatively, an extra member function of the Variable class, SetMemorySpace(const adios2::MemorySpace mem) can explicitly tell ADIOS2 whether the pointer points to device memory or host memory.

Notable new features

BP5

BP5 is a new data format and there is a new engine, BP5, that writes and reads in this format. See https://adios2.readthedocs.io/en/latest/engines/engines.html for runtime options. There are four main advantages using this over the previous engine BP4.

  • Lower memory consumption. Deferred Puts use user buffer for I/O wherever possible thus saving on a memory copy. Aggregation uses a fixed-size shared-memory segment on each compute node instead of using MPI to send data from one process to another. Memory consumption can save 50% of extra memory usage compared to BP4 in some cases.
  • Faster metadata management improves write/read performance where hundreds or more variables are added to the output.
  • Improved functionality around appending many output steps into the same file. Better performance than writing new files each step. Restart can append to an existing series by truncating unwanted steps. Readers can filter out unwanted steps to only see and process a limited set of steps. Just like as in BP4, existing steps cannot be corrupted by appending new steps. Existing steps can be read by another application while new steps are written and the reader can wait for incoming steps, i.e., in situ processing through files works identically to using staging engines.
  • Asynchronous writing is an option with BP5, which can further improve performance in applications. This is a simple runtime option to turn it on/off, there is no need to tinker with I/O calls in the source code. This asynchronous I/O implementation does NOT need a multithreaded MPI library.

GPU Support

  • IO: ADIOS can now write and read data to and from CUDA device memory by passing a valid device pointer to the appropriate Put and Get API calls. Current support is limited to CUDA on NVIDIA GPUs but future releases will support both AMD and Intel GPUs.
  • Compression: The ZFP floating point compression operator has additional configurations options and now supports compression and decompression operations on NVIDIA GPUs for variable data on either host or device memory.

Further details on GPU-Aware I/O can be found in the ADIOS user guide

Plugin architecture for Engines and Operators

Engines and Operators can now be developed outside of ADIOS and loaded at runtime. For engine plugins, the engine should inherit from the PluginEngineInterface class. The engine library should also contain EngineCreate() and EngineDestroy() symbols that ADIOS will be able to use to create and destroy your engine. Similarly, Operator plugins should inherit from the PluginOperatorInterface class and the library should contain OperatorCreate() and OperatorDestroy() symbols. To help ADIOS find user plugin libraries, the ADIOS2_PLUGIN_PATH environment variable can be set. Further details on writing and using plugins can be found in the ADIOS user guide.

Compression operators backward-compatibility feature

From version 2.8.0 onward Operators manage their own metadata and their future versions will provide information on the (compression) libraries used in older datasets in case they cannot decompress the data with the current compression library it is built with. Users then may be able to rebuild the future ADIOS version with an older, compatible compression library that can read back their data. The downside of the redesign of Operators is that datasets written with lossy compression cannot be read back with ADIOS 2.8.0 and newer versions, so you need to build and use 2.7.1 for that.

Full Changelog: v2.7.1...v2.8.0

Assets 2