Commit 515caa8b authored by Atkins, Charles Vernon's avatar Atkins, Charles Vernon
Browse files

docs: Fix typos

parent 20a5afe2
......@@ -9,7 +9,7 @@ The goal is to provide specific advice and good practices about the use of ADIOS
2. Use ``MPI_COMM_SELF`` to run MPI compiled versions of ADIOS 2 in "serial" mode
3. Use a runtime configuration file in the ``ADIOS`` constructor or ``adios2_init`` when targetting multiple engines
3. Use a runtime configuration file in the ``ADIOS`` constructor or ``adios2_init`` when targeting multiple engines
4. Check object validity when developing (similar to ``fstream``):
......@@ -45,7 +45,7 @@ The goal is to provide specific advice and good practices about the use of ADIOS
7. Define your data structure: set of variables and attributes before developing. Data hierarchies/models can be built on top of ADIOS 2.
8. Read the documentation for :ref:`Supported Engines` before targetting development for a particular engine
8. Read the documentation for :ref:`Supported Engines` before targeting development for a particular engine
9. MPI development: treat ``ADIOS`` constructor/destructor (``adios2_init``/``adios2_finalize``) and Engine ``Open`` and ``Close`` always as collective functions. For the most part, ADIOS 2 API functionality is local, but other Engine functions might follow other rules, :ref:`Supported Engines`.
......
......@@ -22,7 +22,7 @@ ADIOS2 components classes
-------------------------
ADIOS2 C++ bindings objects are mapped 1-to-1 to the ADIOS components described in the :ref:`Components Overview` section.
Only the ``adios2::ADIOS`` object is "owned" by the developer's program using adios2, all other components are light-weigth objects that point internally to a component that lives inside the ``adios2::ADIOS`` "factory" object.
Only the ``adios2::ADIOS`` object is "owned" by the developer's program using adios2, all other components are light-weight objects that point internally to a component that lives inside the ``adios2::ADIOS`` "factory" object.
.. code-block:: c++
......
......@@ -455,7 +455,7 @@ ADIOS2 Fortran bindings handlers are mapped 1-to-1 to the ADIOS components descr
! io that spawns an engine based on its configuration
type(adios2_io), intent(in) :: io
! unique engine identifier within io, file name for default bpfile engine
! unique engine identifier within io, file name for default BPFile engine
character*(*), intent(in) :: name
! Optional MPI communicator, only in MPI library
......
......@@ -18,7 +18,7 @@ See each language section in this chapter for a write/read example.
.. note::
The simpified APIs are based on language native file IO interface. Hence ``write`` and ``read`` calls are always synchronized and variables data memory is ready to use immediatley after these calls.
The simplified APIs are based on language native file IO interface. Hence ``write`` and ``read`` calls are always synchronized and variables data memory is ready to use immediately after these calls.
Currently ADIOS2 support bindings for the following languages and their minimum standards:
......
......@@ -29,7 +29,7 @@ C++11 Write example
adios2::fstream oStream("cfd.bp", adios2::fstream::out, MPI_COMM_WORLD);
// NSteps from aplication
// NSteps from application
for (std::size_t step = 0; step < NSteps; ++step)
{
if(rank == 0 && step == 0) // global variable
......
......@@ -23,7 +23,7 @@ This component is created by passing:
.. note::
Unexpected system failures and runtime errors are always checked by throwing ``std::runtime_error``.
Keep in mind that Segmentation Faults are NOT runtime exceptions. We try to keep user interactions as friendly as possible, please report any bugs on github: https://github.com/ornladios/ADIOS2/issues
Keep in mind that Segmentation Faults are NOT runtime exceptions. We try to keep user interactions as friendly as possible, please report any bugs on GitHub: https://github.com/ornladios/ADIOS2/issues
``adios2::ADIOS`` objects can be created in MPI and non-MPI (serial) mode.
......
......@@ -71,7 +71,7 @@ The most common signature is the one that passes a ``Variable<T>`` object for th
void Put(Variable<T> variable, const T* data, const adios2::Mode = adios2::Mode::Deferred);
Optionally, adios2 Engines can provide direct access to its buffer memory using an overload that returns a piece of memory to a variable block, basically a zero-copy. Variable<T>::Span is based on a subset of the upcoming `C++20 std::span <https://en.cppreference.com/w/cpp/container/span>`_, which is non-owning and typed contiguous memory piece (it helps to review what std::span is, formely known as array_view). Spans act as a 1D memory container meant to be filled out by the application. It is safely used as any other STL sequence container, with iterators ``begin()`` and ``end()``, ``operator[]`` and ``at()``, while also providing ``data()`` and ``size()`` functions to manipulate the internal pointer.
Optionally, adios2 Engines can provide direct access to its buffer memory using an overload that returns a piece of memory to a variable block, basically a zero-copy. Variable<T>::Span is based on a subset of the upcoming `C++20 std::span <https://en.cppreference.com/w/cpp/container/span>`_, which is non-owning and typed contiguous memory piece (it helps to review what std::span is, formerly known as array_view). Spans act as a 1D memory container meant to be filled out by the application. It is safely used as any other STL sequence container, with iterators ``begin()`` and ``end()``, ``operator[]`` and ``at()``, while also providing ``data()`` and ``size()`` functions to manipulate the internal pointer.
Variable<T>::Span is helpful in situations in which temporaries are needed to create contiguous pieces of memory from non-contiguous pieces (``e.g.`` tables, arrays without ghost-cells), or just to save memory as the returned Variable<T>::Span can be used for computation, thus avoiding an extra copy from user memory into the adios buffer.
Variable<T>::Span combines a hybrid Sync and Deferred mode, in which the initial value and memory allocations are Sync, while data population and metadata collection are done at EndStep/PerformPuts/Close. Memory contracts are explained later in this chapter followed by examples.
......@@ -537,7 +537,7 @@ Engine Polymorphism has a two-fold goal:
1. Each Engine implements an orthogonal IO scenario targeting a use case (e.g. Files, WAN, InSitu MPI, etc) using a simple, unified API.
2. Allow developers to build their own custom system solution based on their particular requirements in the own playground space. Resusable toolkit objects are available inside ADIOS2 for common tasks: bp buffering, transport management, transports, etc.
2. Allow developers to build their own custom system solution based on their particular requirements in the own playground space. Reusable toolkit objects are available inside ADIOS2 for common tasks: bp buffering, transport management, transports, etc.
A class that extends Engine must be thought of as a solution to a range of IO applications. Each engine must provide a list of supported parameters, set in the IO object creating this engine using ``IO::SetParameters, IO::SetParameter``, and supported transports (and their parameters) in ``IO::AddTransport``. Each Engine's particular options are documented in :ref:`Supported Engines`.
......
......@@ -66,5 +66,5 @@ The following figure depicts the components hierarchy from the application's poi
* **Engine**: Engines define the actual system executing the heavy IO tasks at Open, BeginStep, Put, Get, EndStep and Close. Due to polymorphism, new IO system solutions can be developed quickly reusing internal components and reusing the same API. If IO.SetEngine is not called, the default engine is the binary-pack bp file reader and writer: **BPFile**.
* **Operator**: (under development) this component defines possible operations to be applied on adios2 self-describing data. This higher level abstraction is needed to provide support for: Callback functions, Transforms, Analytics funcions, Data Models functionality, etc. Any required task will be executed within the Engine. One or many operators can be associated with any of the adios2 objects or a group of them.
* **Operator**: (under development) this component defines possible operations to be applied on adios2 self-describing data. This higher level abstraction is needed to provide support for: Callback functions, Transforms, Analytics functions, Data Models functionality, etc. Any required task will be executed within the Engine. One or many operators can be associated with any of the adios2 objects or a group of them.
......@@ -50,7 +50,7 @@ Use the :ref:`C bindings`. C++11 is a brand new language standard and many new (
Why are C and Fortran APIs missing functionality?
-------------------------------------------------
Because language instrinsics are NOT THE SAME. For example, C++ and Python support key/value pair structures natively, *e.g.* ``std::map`` and dictionaries, respectively.
Because language intrinsics are NOT THE SAME. For example, C++ and Python support key/value pair structures natively, *e.g.* ``std::map`` and dictionaries, respectively.
Fortran and C only support arrays natively.
Use the right language (tool) for the right task.
......
**ADIOS2** is the latest implementation of the `Adaptable Input Output System <https://csmd.ornl.gov/software/adios2>`_.
This brand new architecture continues the performance legacy of ADIOS1, and extends its capabilities to address the extreme challenges of scientific data IO.
The `ADIOS2 repo is hosted at github <https://github.com/ornladios/ADIOS2>`_.
The `ADIOS2 repo is hosted at GitHub <https://github.com/ornladios/ADIOS2>`_.
The ADIOS2 infrastructure is developed as a multi-institutional collaboration
between
......@@ -16,7 +16,7 @@ The key aspects ADIOS2 are
#. **Modular architecture:** ADIOS2 takes advantage of the major features
of C++11. The architecture utilizes a balanced combination of runtime
polymorphism and template metaprogramming to expose intuitive abstractions for a broad range of IO applications.
polymorphism and template meta-programming to expose intuitive abstractions for a broad range of IO applications.
#. **Community:** By maintaining coding standards, collaborative
......@@ -24,7 +24,7 @@ The key aspects ADIOS2 are
#. **Sustainability:** Continuous integration and unit testing ensure that ADIOS2 evolves responsibly.
Bug reports are triaged and fixed in a timely manner and can be reported on `Github <https://github.com/ornladios/ADIOS2/issues>`_.
Bug reports are triaged and fixed in a timely manner and can be reported on `GitHub <https://github.com/ornladios/ADIOS2/issues>`_.
#. **Language Support:** In addition to the native C++, bindings for Python, C, Fortran and Matlab are provided.
......@@ -44,7 +44,7 @@ What ADIOS2 is and isn't
- **MPI-based**: out-of-box MPI-based, non-MPI is optional at build time.
- **Group-based**: ADIOS2 favors a deferred/prefetch/grouped variables transport mode by default. Sync mode, one variable at a time, is the special case.
- **Group-based**: ADIOS2 favors a deferred/pre-fetch/grouped variables transport mode by default. Sync mode, one variable at a time, is the special case.
- **Step-based**: to resemble actual production of data in "steps" of variable groups, for either streaming or random-access (file) media
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment