The both the underlying `UnknownArrayHandle` and `ArrayHandleVirtual`
handle `ArrayHandleCast` specially. This caused problems when passing an
`ArrayHandleCast` to `VariantArrayHandle::AsVirtual`. Solve the problem
by stripping out the cast storage tags and letting these classes handle
it internally.
It's annoying to have to fix a problem in a method of a deprecated class
that returns another class that is deprecated for a different reason. No
one should really be running this.
`UnknownArrayHandle` treats a `ArrayHandleCast` and
`ArrayHandleMultiplexer` special. When you put one of these arrays in an
`UnknownArrayHandle`, it takes the original array out and stores it. If
you try to take an array of that type out, it will again do the proper
conversion.
The only problem is that if you use `IsType`, the result can be
unexpected. This is what happened with `CastAndCall`, which was using
`IsType` internally. Changed that to `CanConvert` to properly get the
array handle out.
`VaraintArrayHandle` has been replaced by `UnknownArrayHandle` and
`UncertainArrayHandle`. Officially make it deprecated and point users to
the new implementations.
Using this internal class is a bit tricky because it requires a pointer
to a C array that is expected to contain portals. Both the C array and
the portals must be defined for the expected device. This is already
handled by the associated Storage. Assuming all of this holds, make sure
the `ArrayPortalRecombineVec` is trivially copyable. This is a
requirement for passing objects to the execution environment.
`vtkm::cont::Error` inherits from `std::exception`. As such, it has a
special `what` string that reports an error message in a standard way.
This is particularly useful when a `vtkm::cont::Error` exception remains
uncaught because the system will print the `what` string before
crashing.
Unfortunately, the `what` string was only being set in the `Error`
constructor that took a message. That is a problem for subclasses like
`ErrorCuda` that used the default constructor and then used
`SetMessage`. The `what` string did not get set in this case.
Change the behavior to capture the stack trace in the default
constructor and update the `what` string if a subclass uses
`SetMessage`.
563e23aac Fix unintended cast in TBB Reduce's return value
a7100c845 Do not assume CUDA reduce operator is unary
f3a6931f6 Fix casting issues in TBB functors
cc5b9a016 Add casts to FunctorsGeneral.h
d9c988b20 Allow for different types in basic type operators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2431
The `Reduce` algorithm is sometimes used to convert an input type to a
different output type. For example, you can compute the min and max at
the same time by making the output of the binary functor a pair of the
input type. However, for this to work with the CUDA algorithm, you have
to be able to also convert the input type to the output type. This was
previously done by treating the binary operator as also a unary
operator. That's fine for custom operators, but if you are using
something like `thrust::plus`, it has no unary operation. (Why would
it?)
So, detect whether the operator has a unary operation. If it does, use
it to cast from the input portal to the output type. If it does not,
just use `static_cast`. Thus, the operator only has to have the unary
operation if `static_cast` does not work.
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.
`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.
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
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++.)
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.
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.
