With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
Rather than try to collect all `LastCell` types inside of a single
header and make an uber type, have each cell locator define its own cell
locator type and use that.
There appears to be a bug in CUDA 9.2 where if you have a class that
contains a struct that itself has to have padding in the middle for
alignment purposes and you then put that class in a union with other
classes, it seems like that padding can cause problems with other
objects in the union.
`PointLocator`s have changed from being virtual objects to being trivial
objects. Part of this change means that when a worklet gets the
execution object for a point locator, it gets the actual object (or a
reference to it) instead of a pointer to an object. This means that the
new code uses the `.` operator to access the locator's features instead
of the `->` operator.
To support code still using the deprecated functionality, added a
specific `->` operator to the locator execution object to make it behave
as if it were a pointer. However, this operator is marked deprecated to
warn the user that they should modify their code to use the `.` instead.
Deprecated the `CellLocator` class and made all methods of the
other `CellLocator` classes non-virtual. General locators can
still use the `CellLocatorGeneral` class, but this class now
only works with a predefined set of locators. (The functionality
to provide a function to select a locator has been removed.)
With recent changes to `ArrayHandle`, the type for the associated array
portal is now the same across all devices. This means that almost all
exec objects no longer need to be specialized on the device types. Thus,
clean up the locator exec objects to no longer need to be templated on
device.
The newer version of `ArrayHandle` no longer supports different types of
portals for different devices. Thus, the `ReadPortalType` and
`WritePortalType` are sufficient for all types of portals across all
devices.
This significantly simplifies supporting execution objects on devices,
and thus this change also includes many changes to various execution
objects to remove their dependence on the device adapter tag.
