GitLab

2e918c58 Move ColorTable mapping to its own header
38bdfec4 Move ColorTable::Sample methods to vtkm_cont
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2262

We would really like to be able to include `vtkm::cont::ColorTable` in
such a way that you don't have to compile device code (unless you are
actually compiling functions for the device). Thus, the `Map` functions
of `ColorTable` were in a special `ColorTable.hxx` that contains the
"implementation" for `ColorTable`.

That is confusing to many users. It is more clear to simply have `.h`
headers that do a specific thing. To achieve these two goals, the `Map`
functionality of `ColorTable` is separated out into its own header file.
So you don't need to be using a device compiler just to use `ColorTable`
(including `ColorTable.h`), but you do need to use a device compiler if
mapping values to colors (including `ColorTableMap.h`).

There is little value to declare them `inline`. Instead, just have them
compiled once in the `vtkm_cont` library.

6a3ba429 Fix warning about unused function
c6a4f9b7 Fix warning about return value
9465d261 Adjust TransferFunction worklet to get color table as ExecObj argument
11996f13 Remove virtual methods from ColorTable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2261

Previously, the `TransferFunction` worklet required you to call
`PrepareForExecution` on the `ColorTable` and give that to the
constructor. Bad things can happen if the `ColorTable` used in the
constructor does not match the device the worklet actually gets invoked
on. Change this to make the `ColorTable` a worklet argument of type
`ExecObj`. The dispatcher will automatically call
`ColorTable::PrepareForInput` and guarantee that the devices match.

Virtual methods are being deprecated, so remove their use from the
ColorTable classes. Instead of using a virtual method to look up a value
in the ColorTable, we essentially use a switch statement. This change
also simplified the code quite a bit.

The execution object used to use pointers to handle the virtual objects.
That is no longer necessary, so a simple `vtkm::exec::ColorTable` is
returned for execution objects. (Note that this `ColorTable` contains
pointers that are specific for the particular device.) This is a non-
backward compabible change. However, the only place (outside of the
`ColorTable` implementation itself) was a single worklet for converting
scalars to colors (`vtkm::worklet::colorconversion::TransferFunction`).
This is unlikely to affect anyone.

I also "fixed" some names in enum structs. There has been some
inconsistencies in VTK-m on whether items in an enum struct are
capitolized or camel case. We seem to moving toward camel case, so
deprecate some old names.

482266b4 Particle: explicitly make the copy ctor and assignment op
1037aa75 AssignerPartitionedDataSet: mark dtor as override
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2259

9b62c9ee Enable storing variable-sized Vecs in UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2260

They are disabled because we have a custom destructor.

One of the features of `UnknownArrayHandle` is that it allows you to
query how many `Vec` components each value has without resolve the type
of the array. The functionality to implement this failed if you tried to
store an `ArrayHandle` that stored `Vec`-like objects with `Vec` sizes
that varied from value to value (i.e. an `ArrayHandleGroupVecVariable`).

Storing such an array in `UnknownArrayHandle` might not be the best
idea, but it should probably work. This change allows you to store such
an array. If you try to query the number of components, you will get 0.

e706880d Fix unnecessary deprecation warnings in visual studio
f7cc0310 Fix deprecated warnings
b27e4c7e Ignore files for deprecated virtual classes for SourceInInstall test
284774cf Turn on "no virtual" option on some CI builds
cd08fd49 Add changelog for removing virtual methods
63ef84ed Optionally remove all use of ArrayHandleVirtual
e11f612a Deprecate ArrayHandleVirtual
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2256

78c7909c Enable automatic transformation of Unknown/UncertainArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2258

843307bc fix floating point casting warning in worklet test
18263a37 update float casting to not have warnings on iris
89cf93a6 fix OpenMP PRAGMA warnings for auto-associated looping variable types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2245

When using a deprecated `ArrayHandle`, you should get the warning when
you declare it, not when it's used in a templated class or method.

Supress the deprecated class warnings for the implementation of
deprecated features.

If `VTKm_NO_DEPRECATED_VIRTUAL` is on, then these classes are not
installed. Thus, add exceptions for these files to avoid test failures.

We could get fancier by only checking if `VTKm_NO_DEPRECATED_VIRTUAL` is
off, but that seems heavy-handed to make a regression test for something
that will go away.

These exceptions should be removed once the files are removed.

Make sure that the `VTKm_NO_DEPRECATED_VIRTUAL` CMake option is building
correctly by adding it to some of the CI builds.

The changelog is not quite accurate because it is claiming that all
virtual methods are removed when that is not quite the case.
Hopefully soon the changelog text will be accurate.

As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.

1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.

To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.

Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.

Virtual methods in the execution environment are going away the next
major release of VTK-m, so deprecate their use in preparation for that.

38630171 Test UnknownArrayHandle behavior on special arrays
872da1f8 Suppress unnecessary deprecation warnings on VS
bb443bbc Replace the implementation of VariantArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2255

fb919e04 vtkm::Vec: added unrolled arithmetic operators overload
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2252

Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>

`UnknownArrayHandle` has special behavior when putting in or getting out
an `ArrayHandleMultiplexer` or an `ArrayHandleCast`. When putting in
either of these, `UnknownArrayHandle` gets the actual array stored in
the multiplexer and cast so that you can later retrieve the base array.
Likewise, when you get the array out with `AsArrayHandle`, you can give
it an `ArrayHandleCast` or `ArrayHandleMultiplexer`, and you will get
the base array placed inside of it.

The Visual Studio compiler has an annoying habit where if you use a
templated class or method with a deprecated class as a template
parameter, you will get a deprecation warning where that class is used
in the templated thing. Thus, if you want to suppress the warning, you
have to supress every instance of the template, not just where the
template is declared.

This is annoying behavior that is thankfully not replicated in other
compilers.

The implementation of `VariantArrayHandle` has been changed to be a
relatively trivial subclass of `UnknownArrayHandle`.

The advantage of this change is twofold. First, it removes
`VariantArrayHandle`'s dependence on `ArrayHandleVirtual`, which gets us
much closer to deprecating that class. Second, it ensures that
`UnknownArrayHandle` is a reasonable replacement for
`VariantArrayHandle`, so we can move forward with replacing that.

66a4a23e Fix issue of getting pointer from std::vector of size 0
3f8da6e7 Fix some debugging code that should not have been there
52cecefb Fix crash when loading poly data with no cells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2254

C++11 introduced the `std::vector::data()` method. In addition to being
more syntatically pleasing, it should correctly handle the condition
when the `std::vector` is size 0 and therefore has no real pointer.
(Expressions like `&v[0]` are undefined when the `vector` is empty.)

5250c28f Swap call pattern of ArrayHandle::DeepCopy
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Allison Vacanti <alliepiper16@gmail.com>
Merge-request: !2253

The new method `ArrayHandle::DeepCopy` had the pattern such that the
data in the `this` array was pushed to the provided destination array.
However, this is the opposite pattern used in the equivalent method in
VTK, which takes the data from the provided array and copies it to
`this` array.

So, swap the pattern to match that of VTK. Also, make the method name
more descriptive by renaming it to `DeepCopyFrom`. Hopefully, users will
read that to mean given the `ArrayHandle`, you copy data from the other
provided `ArrayHandle`.

aa6eb01d ComputeMoments: use FilterField instead of FilterCell
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2251