ArrayGetValues for ArrayHandleCast needs to be handled specially as an
`UnknownArrayHandle::IsBaseComponentType` check inside the implementation
gives unexpected results for ArrayHandleCast.
With this fix, the values are first copied from the source array type and
then casted to the appropriate type before returning.
Under some circumstances, `IsType` can return false for a type that
exactly matches the type used to create the `UnknownArrayHandle`.
This is because types like `ArrayHandleCast` get converted to
the array they contain. Thus, `IsType` will return false when it
is expected to be true. In most cases, you should use
`CanConvert`. The `IsType` documentation now points you there.
ParaView ends up triggering this in its test suite and the "failure"
mention ends up triggering the "failed test" condition in its test
harness. Reword to read more like a warning than an error.
For some reason, GCC is dropping the templated function instances use
for the `UnknownArrayHandle` constructor. Apparently, something in the
compiler or the linker is being over aggressive about removing unused
symbols and is actually dropping symbols that are being used. Maybe it
is because the functions are not directly called but their pointers are
used.
To get around this problem, mark these templated functions in
UnknownArrayHandle.h with the `used` attribute to force the compiler/
linker to keep them. There should be no consequence to that as these
function templates are only instantiated if they are used.
When building the reverse connections (visit points with cells) for
`CellSetSingleType`, the fast path for building these was not built due
to a templating error.
Some of the unit tests for serial and kokkos are disable for hipcc to
properly compile.
VTKM_MATH_ASSERT and VTKM_TEST_ASSERT fail to compile with HIP in
execution environment so they are disabled with building with HIP.
Kokkos::finalize is causing error so it is temporarily disabled.
`vtkm::cont::UnknownArrayHandle` now provides a set of method that
allows you to copy data from one `UnknownArrayHandle` to another. The
first method, `DeepCopyFrom`, takes a source `UnknownArrayHandle` and
deep copies the data to the called one. If the `UnknownArrayHandle`
already points to a real `ArrayHandle`, the data is copied into that
`ArrayHandle`. If the `UnknownArrayHandle` does not point to an existing
`ArrayHandle`, then a new `ArrayHandleBasic` with the same value type as
the source is created and copied into.
The second method, `CopyShallowIfPossibleFrom` behaves similarly to
`DeepCopyFrom` except that it will perform a shallow copy if possible.
That is, if the target `UnknownArrayHandle` points to an `ArrayHandle`
of the same type as the source `UnknownArrayHandle`, then a shallow copy
occurs and the underlying `ArrayHandle` will point to the source. If the
types differ, then a deep copy is performed. If the target
`UnknownArrayHandle` does not point to an `ArrayHandle`, then the
behavior is the same as the `=` operator.
One of the intentions of these new methods is to allow you to copy
arrays without using a device compiler (e.g. `nvcc`). Calling
`ArrayCopy` requires you to include the `ArrayCopy.h` header file, and
that in turn requires device adapter algorithms. These methods insulate
you from these.
Previously, the check for visit points with cells for `CellSetExtrude`
only looked at the count of incident cells. This expands the check to
make sure that it actually returns the expected cells.
Scheduling topology map workets for `CellSetExtrude` always worked, but
the there were indexing problems when a `Scatter` or a `Mask` was used.
This has been corrected, and now `Scatter`s and `Mask`s are supported on
topology maps on `CellSetExtrude`.
The superclass method `CellSetExplicit::GetCellShape()` is marked
deprecated because it is a slow way to access the cell shape. However,
this deprecation is causing a warning with MSVC when implementing the
subclass `CellSetSingleType`'s override of that method (which is not
slow). Suppress this warning.
Because `CellSetExplicit` is a templated class, the implementation of
most of its features is part of the header files. One of the things that
was included was the code to build the reverse connectivity links. That
is, it figured out which cells were incident on each point using the
standard connections of which points comprise which cells.
Of course, building these links is non-trivial, and it used multiple
DPPs to engage the device. It meant that header had to include the
device adapter algorithms and therefore required a device compiler. We
want to minimize this where possible.
To get around this issue, a non-templated function was added to find the
reverse connections of a `CellSetExplicit`. It does this by passing in
`UnknownArrayHandle`s for the input arrays. (The output visit-points-
with-cells arrays are standard across all template instances.) The
implementation first iterates over all `CellSetExplicit` versions in
`VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types.
In the unlikely event that none of these arrays work, it copies the data
to `ArrayHandle<vtkm::Id>` and uses those.
Make it more clear that ScanExtended increases the array size by
1, what ranges the exclusive and inclusive scan cover, and the
features of the first and last entries.
`ConvertNumComponentsToOffsets` has been changed to provide a pre-
compiled version for common arrays. This helps with the dual goals of
compiling less device code and allowing data set builders to not have to
use the device compiler. For cases where you need to compile
`ConvertNumComponentsToOffsets` for a different kind of array, you can
use the internal `ConvertNumComponentsToOffsetsTemplate`.
For no particularly good reason, there were two functions that converted
and array of counts to an array of offsets: `ConvertNumComponentsToOffsets`
and `ConvertNumIndicesToOffsets`. These functions were identical, except
one was defined in `ArrayHandleGroupVecVariable.h` and the other was
defined in `CellSetExplicit.h`.
These two functions have been consolidated into one (which is now called
`ConvertNumComponentsToOffsets`). The consolidated function has also been
put in its own header file: `ConvertNumComponentsToOffsets.h`.
Normally, backward compatibility would be established using deprecated
features. However, one of the things being worked on is the removal of
device-specific code (e.g. `vtkm::cont::Algorithm`) from core classes like
`CellSetExplicit` so that less code needs to use the device compiler
(especially downstream code).
Part of this change removed unnecessary includes of `Algorithm.h` in
`ArrayHandleGroupVecVariable.h` and `CellSetExplicit.h`. This header had to
be added to some classes that were not including it themselves.
5191909b5 Fix MeshQuality to work with CellSetSingleType
ecf36ed39 Fix compile errors in CellSetSingleType::CompleteAddingCells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2556
a2a8dcdfd Allow a `const ArrayHandle` to be reallocated
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2570
