Group default alloc id is not uniformly applied in the hierarchy

[gunney1]

The writing of this long issue is in progress. I'll remove this statement when I'm done.

There appears to be some oversight in allocating memory for the leaves in a sidre hierarchy. Each Group has a default allocator id, and we should propagate it down to be used by the hierarchy. However there are some inconsistencies.

• When deep-copying whole hierarchy, Scalar and array Views do use this id, but string Views do not. For scalars and arrays, we use Sidre buffers for the memory, but for strings, we have m_node allocate the memory. The fix would be to specify what allocator id m_node should use. However, there's a problem with this. See below.

• createViewScalar stores the value in m_node. This is inconsistent in two ways.

  1. It differs from the deep-copy way, which stores the value in a sidre Buffer.
  2. m_node uses the default Conduit allocator instead of the default allocator for the hierarchy. We should decide whether to store scalars in a Buffer or in m_node. If we decide on m_node, it has the same solution as above, and has the same problem. See below.

• What should sidre do when generating a hierarchy (all at once recursively or one view at a time) without an explidicit allocator in the function argument?

  1. Use the default allocator in the Group?
  2. Let Conduit use its default allocator?

• There are multiple ways to set a scalar, not using external memory. They use internal memory allocation directly with Buffer or indirectly with Conduit. Do they use the same allocator ids?

  1. template <typename ScalarType> View::setScalar(ScalarType value).
  2. View::setScalar(Node& value). (BTW, value should probably be const.)

These issues are being exposed because I am using Conduit's custom allocators to get data on GPUs.

Current minor problem having Conduit use Axom's allocator: Conduit can accommodate non-Conduit allocators. We register custom allocators with Conduit, get an id and set this id in the conduit::Node. However, this requires giving Conduit a callback function that uses Axom's memory allocators. (This step is skipped for scalar and array Views, where we don't use Conduit's memory allocation mechanism.) There is an issue with the Conduit interface supporting this feature. Conduit expects a C function or C++ lambda expression with no capture. Neither of these have a state that can be used to determine the correct allocator id to use.

I have discussed this with @cyrush and @agcapps, and I believe they will allow a callback of type std::function, which should support lambda expressions that capture the specified allocator id.

We don't have to wait for the Conduit fix. As a work-around, we have to add a few lines of code for each allocator id used. Of course, Axom has to be recompiled when this happens.