Unfortunately, this introduces a backward-incompatible change with the
filters that use ImplicitFunctions. Before, they would get an
ImplicitFunctionHandle. This class is deprecated, and there is no easy
way to get back the actual type of implicit function stored in it.
CUDA architecture has a limited amount of memory available for
constants. The CUDA compiler uses this space to hold constants for some
optimizations. However, for large kernels, the number of constants
needed might be larger than the constant space available. For these
conditions, you have to disable this form of optimization with the `-
Xptxas --disable-optimizer-constants` flags.
Currently, the only file that seems to have this issue is the test for
the Lagrangian filter. Someone should take a closer look to see if this
filter in particular is making unnecessarily large worklet/kernel. (In
particular, why does the Lagrangian filter have a larger kernel than the
streamline and stream surface filters?)
If this occurance happens more often, we might need to add some ways to
configure it in the build.
It used to be the case where you needed to call `ResetTypes` on a
`VariantArrayHandle` before using `ArrayCopy` to limit the types it gets
compiled for. However, there is now a general form for
`UnknownArrayHandle`, so `ResetTypes` no longer does anything useful in
this case. Remove the use of that.
The circular dependency came from UnknownArrayHandle.h needing
VTKmDefaultTypes.h, which needed all the cell set types. Some of those
cell sets used ArrayCopy in templated functions. Changed those functions
to directly deep copy the ArrayHandle.
There was an error that caused deprecation warnings in VTK-m to be
suppressed, which meant that many uses of deprecated features went
unnoticed. This fixes those deprecation warnings.
The majority of the warnings were caused by the use of the deprecated
`Cast`, `CopyTo`, and `ResetTypes` methods of `UnknownArrayHandle` (or
`VariantArrayHandle`). Both `Cast` and `CopyTo` have been subsumed by
`AsArrayHandle` (to make the functionality more clear). `ResetTypes` now
requires a second template argument to define the storage types to try.
Also fixed some issues with `SerializableField` being deprecated.
This class is no longer necessary because `Field` can now be directly
serialized.
61522fde7 Add #includes and explicitly identify the field name.
1bad28a3e Logistic map as an example of how to use the ImageWriter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2385
The `VariantArrayHandle` will soon be deprecated for its replacement of
`UnknownArrayHandle`. Thus, `Field` and related classes should start
using the new `UnknownArrayHandle`.
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.
