The `ArrayCopy` method has been changed to be precompiled. It handles
most standard array types. But there are some special `ArrayHandle`
types that are not correctly handled, and these go to a slow fallback.
Find places in the code that use that fallback and fix them.
There are also some instances of replacing an `ArrayHandleCounting` with
an `ArrayHandleIndex`. This change is probably not strictly necessary to
make the `ArrayCopy` faster, but when it can be used `ArrayHandleIndex`
is generally better.
We have made several improvements to adding data into an `ArrayHandle`.
## Moving data from an `std::vector`
For numerous reasons, it is convenient to define data in a `std::vector`
and then wrap that into an `ArrayHandle`. It is often the case that an
`std::vector` is filled and then becomes unused once it is converted to an
`ArrayHandle`. In this case, what we really want is to pass the data off to
the `ArrayHandle` so that the `ArrayHandle` is now managing the data and
not the `std::vector`.
C++11 has a mechanism to do this: move semantics. You can now pass
variables to functions as an "rvalue" (right-hand value). When something is
passed as an rvalue, it can pull state out of that variable and move it
somewhere else. `std::vector` implements this movement so that an rvalue
can be moved to another `std::vector` without actually copying the data.
`make_ArrayHandle` now also takes advantage of this feature to move rvalue
`std::vector`s.
There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove`
that takes an rvalue. There is also a special overload of
`make_ArrayHandle` itself that handles an rvalue `vector`. (However, using
the explicit move version is better if you want to make sure the data is
actually moved.)
## Make `ArrayHandle` from initalizer list
A common use case for using `std::vector` (particularly in our unit tests)
is to quickly add an initalizer list into an `ArrayHandle`. Now you can
by simply passing an initializer list to `make_ArrayHandle`.
## Deprecated `make_ArrayHandle` with default shallow copy
For historical reasons, passing an `std::vector` or a pointer to
`make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`).
Although more efficient, this mode is inherintly unsafe, and making it the
default is asking for trouble.
To combat this, calling `make_ArrayHandle` without a copy flag is
deprecated. In this way, if you wish to do the faster but more unsafe
creation of an `ArrayHandle` you should explicitly express that.
This requried quite a few changes through the VTK-m source (particularly in
the tests).
## Similar changes to `Field`
`vtkm::cont::Field` has a `make_Field` helper function that is similar to
`make_ArrayHandle`. It also features the ability to create fields from
`std::vector`s and C arrays. It also likewise had the same unsafe behavior
by default of not copying from the source of the arrays.
That behavior has similarly been depreciated. You now have to specify a
copy flag.
The ability to construct a `Field` from an initializer list of values has
also been added.
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
Rather than force all dispatchers to be templated on a device adapter,
instead use a TryExecute internally within the invoke to select a device
adapter.
Because this removes the need to declare a device when invoking a
worklet, this commit also removes the need to declare a device in
several other areas of the code.
Found via `codespell` and `grep`
more typos
includes source typo change and a typo that needs further review
follow-up typos
Follow-up typos
Revert a commit
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
These asserts are consolidated into the unified Assert.h. Also made some
minor edits to add asserts where appropriate and a little bit of
reconfiguring as found.
A previous change used the Copy method of DeviceAdapterAlgorithm to
perform the actual copy in the CopyInto method. This works fine, except
that it uses the default device adapter, and the default device adapter
may need to copy the data to the device just to copy it to another
array. Instead, use the serial device adapter, which is guaranteed to
only perform one copy of the data.
This makes is slightly easier to use as you do not actually have to
construct the DataSetBuilder object but just call its static method.
The DataSetBuilderExplicitIterative methods are not static because they
use state of the builder object to create the data.
1. Additional ASSERT calls to validate arguments in: DataSetBuilderRegular
2. Fix some untested compile errors in DataSetBuilderRectilinear
3. Added a new unit test, cont/testing/UnitTestDataSetBuilderRectilinear.cxx
4. Provided additional tests for UnitTestDataSetBuilderRegular.cxx.
The new tests in (4) were also included in (3), and provide a much more robust way of validating datasets created. It has nested for loops to do an all-all test on various ways to specify the X,Y, and Z coordinates. It computes the bounds on the coordinate system and make sure they are correct.
Note: The GetBounds() call for Rectilinear is not working, and is an item for future discussion. It is disabled for now.
