Merge branch 'develop' into task/2021_03_fetch_conduit_ehandlers

CHANGELOG.md

@@ -10,11 +10,18 @@ and this project aspires to adhere to [Semantic Versioning](https://semver.org/s
 
 #### General
 - Added  `conduit::utils::info_handler()`, `conduit::utils::warning_handler()`, and `conduit::utils::error_handler()`  methods, which provide access to the currently registered info, warning, and error handlers.
+- Added DataType::index_t method. Creates a DataType instance that describes an `index_t`, which is an alias to either `int32`, or `int 64` controlled by the `CONDUIT_INDEX_32` compile time option.
+- Added several more methods to Python DataType interface
 
 #### Relay
 - Added Relay HDF5 support for reading and writing to an HDF5 dataset with offset.
 - Added `conduit::relay::io::hdf5::read_info` which allows you to obtain metadata from an HDF5 file.
 
+### Fixed
+
+#### General
+- Fixed missing implementation of DataType::is_index_t 
+
 
 ## [0.7.1] - Released 2021-02-11
 
@@ -466,7 +473,8 @@ and this project aspires to adhere to [Semantic Versioning](https://semver.org/s
 ### Added
 - Initial Open Source Release on GitHub
 
-[Unreleased]: https://github.com/llnl/conduit/compare/v0.7.0...HEAD
+[Unreleased]: https://github.com/llnl/conduit/compare/v0.7.1...HEAD
+[0.7.1]: https://github.com/llnl/conduit/compare/v0.7.0...v0.7.1
 [0.7.0]: https://github.com/llnl/conduit/compare/v0.6.0...v0.7.0
 [0.6.0]: https://github.com/llnl/conduit/compare/v0.5.1...v0.6.0
 [0.5.1]: https://github.com/llnl/conduit/compare/v0.5.0...v0.5.1

src/docs/sphinx/blueprint_mesh.rst

@@ -632,7 +632,7 @@ Species Sets
 Species Sets are a means of representing multi-dimensional per-material quantities, most commonly per-material substance fractions.
 
 Individual Species Sets are entries in the ``specsets`` section of the Blueprint hierarchy, and these entries are formatted in much the same way as ``fields`` entries that describe per-material, multi-dimensional fields.
-Just as with this class of ``fields`` entries, each ``specsets`` entry must specify the material set over which it is defined and enumerate its values within an **mcarray** that's organized in material-major and component-minor order.
+Just as with this class of ``fields`` entries, each ``specsets`` entry must specify the material set over which it is defined and enumerate its values within an **mcarray** that's organized first by materials (shallower level of nesting) and then by species components (deeper level of nesting).
 Additionally, like ``field`` entries, each ``specsets`` item must indicate a volumetric scaling type (e.g. volume-dependent, volume-independent).
 To put it in short, each entry in the ``specsets`` section of the Blueprint hierarchy must be an *Object* that follows this template:
 
@@ -641,15 +641,14 @@ To put it in short, each entry in the ``specsets`` section of the Blueprint hier
  * specsets/specset/matset_values: (mcarray)
 
 
-
 Nesting Sets
 ++++++++++++++++++++
 
 Nesting Sets are used to represent the nesting relationships between different domains in multi-domain mesh environments. Most commonly, this subset of the Blueprint specification is used for AMR (adaptive mesh refinement) meshes.
 
 Each entry in the Nesting Sets section contains an independent set of nesting relationships between domains in the described mesh.
 On an individual basis, a nesting set contains a source topology, an element association, and a list of nesting windows.
-The windows for a particular nesting set describe the topological nesting pattern for a paired set of domains, which includes the ID of the partnered domain, the type of the partnered domain (parent or child), and the self-relative origin and dimensions of the nesting relationship.
+The windows for a particular nesting set describe the topological nesting pattern for a paired set of domains, which includes the ID of the partnered domain, the type of the partnered domain (parent or child), the per-dimension zone ratios of this domain relative to the partnered domain, and the self-relative dimensions and origin (provided in terms of local domain coordinates) of the nesting relationship.
 The Blueprint schema for each entry in the ``nestsets`` section matches the following template:
 
    * nestsets/nestset/association: "vertex" | "element"
@@ -660,6 +659,32 @@ The Blueprint schema for each entry in the ``nestsets`` section matches the foll
    * nestsets/nestset/windows/window/origin/{i, j, k}
    * nestsets/nestset/windows/window/dims/{i, j, k}
 
+.. note::
+   Many structured AMR codes use global coordinate identifiers when specifying
+   each window's ``origin``. Such coordinates must be transformed to domain-local
+   coordinates to be Blueprint-compliant. Given the global structured origin of
+   a window's associated topology ``topo_origin`` (which isn't in the Blueprint,
+   but is likely stored somewhere in the client code), the global origin can be
+   transformed into a local origin like so:
+
+   .. code:: cpp
+
+       // 'window_origin': starts out as a global index, but is transformed into
+       // a domain-local index through this procedure
+       conduit::Node &window_origin = // path to nestset/windows/window/origin
+       conduit::Node &topo_origin = // loaded from client code; {i, j, k} structure
+
+       conduit::NodeIterator origin_it = window_origin.children();
+       while(origin_it.has_next())
+       {
+           conduit::Node &window_dim = origin_it.next();
+           conduit::Node &topo_dim = topo_origin[origin_it.name()];
+
+           conduit::int64 new_dim_val = window_dim.to_int64() - topo_dim.to_int64();
+           conduit::Node &new_dim(conduit::DataType::int64(1), &new_dim_val, true);
+           new_dim.to_data_type(window_dim.dtype().id(), window_dim);
+       }
+
 Each domain that contains a Nesting Sets section must also update its State section to include the domain's global nesting level.
 This additional requirement adds the follow constraint to the ``state`` section: