If you are using the classes in `FunctorsGeneral.h`, you specify both
the result type and the type of the operands. Presumably you are already
comfortable with any type conversions. So let them keep.
The basic type operators in `Types.h` (i.e. `vtkm::Add`,
`vtkm::Subtract`, `vtkm::Multiply` and `vtkm::Divide`) required the same
type for both arguments. This caused problems when used with `Reduce`
and the initial value type did not match exactly.
Use some tricks from `BinaryOperators.h` to be flexible about using
different types.
80c1f0a97 Be more conservative about is_trivial support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !2427
I have run into strange problems with reference types sneaking into
templates. Reference types can cause weird errors when passing things
across hosts and devices, and it's best not to let them sneak into an
object like Varient where they become more difficult to check for.
`std::is_trivial` is part of the C++14 specification. However, we have
encountered multiple compilers that purport to implement C++14 but do
not implement `std::is_trivial` and the like checks correctly.
To avoid such issues, only use `std::is_trivial` on compilers that we
have tested to support it.
e4a46f339 Removed two TODO comments after verifying parameters
3ef95ded2 Port bug fix from distributed to augmented contour tree filter
70f7337f6 Fix hang in distributed contour tree
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2424
662998f19 Remove make_ImplicitFunctionFunctor functions
27cc99acb Add documentation for Multiplexer and General implicit functions
6a445ebcf Do not return a reference from ImplicitFunction::PrepareForExecution
b0fcab5d7 Do not capture references to execution objects
096e7457c Fix CUDA issues
8c6623736 Suppress deprecation warnings in deprecated class
a6725b3ac Remove use of deprecated ImplicitFunctions with virtual methods
180d11e7f Add ImplicitFunctionGeneral
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2413
They were meant to replace `make_ImplicitFunction*Handle` classes, but
they don't really provide any interesting functionality and are not
backward compatible in any case. So just get rid of one more thing we
don't need to support.
It is possible for a transport to return a reference to an object.
At some point, however, the object has to be potentially copied
to a different memory space to be used in the execution environment.
This was getting fouled up because the reference type was being
captured. Instead, remove any references from the object.
The GCC 7 compiler on summit was failing to compile all of the
code. The problematic parts involved using lambda functions.
I think the problem is that the compiler has a bug where it
has a problem resolving the type of variables captured by
reference. The problem seems similar to this bug reported
to Kokkos:
https://github.com/kokkos/kokkos-kernels/issues/349
Solved the problem by removing the lambdas with either a
named method or just inline code.
I suspect the problem arose (without anyone's knowledge) with
MR !2331, which moved VTK-m to C++14. This GCC error seems to
happen with C++14 but not C++11. (The features of lambdas changed
between these two versions of C++.)
b9326c208 force update the images
b4877cf73 fix conversion warning
cac09110d fix rendering depths and divide by zero
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2419
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.
There is still a test for the deprecated functionality (for now). The
deprecated test only happens if deprecated virtuals are still compiled,
and warnings are suppressed for this part of the code.
The `ImplicitFunction` classes are now trivial classes that can be
passed among host and devices. Because of this, we now need to know the
type of the `ImplicitFunction` in order to use it.
The old functionality still exists (when virtual methods are still being
compiled), but will give deprecation warnings. It is also not possible
to get a pointer from `ImplicitFunctionHandle` and cast it back to the
original data type (because the type changed). This is a weird testing
feature that makes little sense in practice.
Also unsupported in the deprecated classes is the ability to change
the object and have those changes reflected in the handle. This is
unfortunate, but it would have been difficult to implement this
feature that is going away and only appears to be used in some of
the tests.
7a14ea0ef Use Float64 instead of FloatDefault in TreeCompiler
96424c833 Fix bad ordering of args for CountLinkComponentsIn2DSlice in IsNecessary
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2414
ebb265ce0 Add missing VTKM_EXEC_CONT declarations to functor
10ea36bb9 Pick one approach of using array handle decorator for contour tree
585f0ccb1 Two versions for replacing array transform with array decorator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2412
1822792b8 Support deprecated behavior of point locator pointers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nickolas Davis <nadavi@sandia.gov>
Merge-request: !2411
`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.
04f020ae6 Update Field to use new ArrayRangeCompute features
2a41428fe Add implementation of ArrayRangeCompute for UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2409
This is a fancy array that takes an array of offsets and converts it to
an array of the number of components for each packed entry.
This replaces the use of `ArrayHandleDecorator` in `CellSetExplicit`.
The two implementation should do the same thing, but the new
`ArrayHandleOffsetsToNumComponents` should be less complex for
compilers.
Reduces the amount of code that has to be generated. Also improves the
number of arrays supported and has better support for deprecated
versions of `GetRange`.
