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.
03a4750a3 Change Oscillator output field name to oscillating
a3462b41c Change Wavelet output field name to RTData
ea1a55359 Name tangle source fields appropriately
a68422d45 Add GenerateIds filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2595
This matches the output field name in VTK and ParaView for the
equivalent source. This change allows this source to be used as a drop-
in replacement for the VTK source (which could be very useful).
The `Tangle` source would create a point field generically named
`nodevar`. This name was not indicitive of the data or its source. Thus,
the output point field has been renamed `tangle`.
The `Tangle` source was also creating a cell field (named `cellvar`).
This field was really just a mirror of the cell indices (counting from 0
on up). This field has been removed from the input. If you want such a
field, you can now use the `GenerateIds` filter to add it to any data
set.
This filter adds a pair of fields to a `DataSet` which mirror the
indices of the points and cells, respectively. These fields are useful
for tracking the provenance of the elements of a `DataSet` as it gets
manipulated by the filters. It is also convenient for adding indices to
operations designed for fields and for testing purposes.
Previously, if you called `Get` on a `Variant` with a type that is not
in the list of types supported by the `Variant`, that would attempt to
look up the type at index `-1` and could spin the compiler into an
endless loop.
Instead, check for the case where you are attempting to get a type from
the `Variant` not listed in its templat arguments. In this case, instead
of producing a compiler error, produce a runtime error. Although this
increases the possibility that a bad compile path is being generated, it
simplifies creating templated code that produces cases we don't care
about.
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.
There was a case where a VTK-m exception was caught and then used in a
logging message. That is fine, but if VTK-m logging is turned off, that
code is removed and the exception variable goes unused.
There was a time when it was common to have logging turned off in VTK-m,
but now it is almost always on. There is one old-style dashboard that
has logging turned off and is giving a warning about this variable not
being used. It went unnoticed because the dashboard was down at the
time. This should fix the issue.
`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.
4239d13b3 Make triangulate implementation more general
1bd70d9c2 Enable triangulation on CellSetSingleType
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2572
5191909b5 Fix MeshQuality to work with CellSetSingleType
ecf36ed39 Fix compile errors in CellSetSingleType::CompleteAddingCells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2556
The triangulate and tetrahedra worklet implementations were for some
reason grabbing raw arrays out of `CellSetExplicit` and using those for
lookup tables. Rather than do that, simply use a
`WorkletVisitCellsWithPoints` automatically provide the values of these
cells. The advantage of this approach is that it simplifies the code and
also generalize it to cell sets that do not provide this explicit
representation. For example, the new implementation also works with
`CellSetExtrude`.
The code path for doing either tetrahedralization or triangulation on a
CellSetSingleType was not actually doing any work. Changed the worklet
implementation so that these work on CellSetExplicit with any template
parameters (which includes CellSetSingleType).
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
Previously, the `Allocate` method of `ArrayHandle` was _not_ declared as
`const`. Likewise, the methods that depended on `Allocate`, namely
`ReleaseResources` and `PrepareForOutput` were also not declared `const`.
The main consequence of this was that if an `ArrayHandle` were passed as a
constant reference argument to a method (e.g. `const ArrayHandle<T>& arg`),
then the array could not be reallocated.
This seems right at first blush. However, we have changed these methods to
be `const` so that you can in fact reallocate the `ArrayHandle`. This is
because the `ArrayHandle` is in principle a pointer to an array pointer.
Such a structure in C will allow you to change the pointer to the array,
and so in this context it makes sense for `ArrayHandle` to support that as
well.
Although this distinction will certainly be confusing to users, we think
this change is correct for a variety of reasons.
1. This change makes the behavior of `ArrayHandle` consistent with the
behavior of `UnknownArrayHandle`. The latter needed this behavior to
allow `ArrayHandle`s to be passed as output arguments to methods that
get automatically converted to `UnknownArrayHandle`.
2. Before this change, a `const ArrayHandle&` was still multible is many
way. In particular, it was possible to change the data in the array
even if the array could not be resized. You could still call things
like `WritePortal` and `PrepareForInOut`. The fact that you could
change it for some things and not others was confusing. The fact that
you could call `PrepareForInOut` but not `PrepareForOutput` was doubly
confusing.
3. Passing a value by constant reference should be the same, from the
calling code's perspective, as passing by value. Although the function
can change an argument passed by value, that change is not propogated
back to the calling code. However, in the case of `ArrayHandle`,
calling by value would allow the array to be reallocated from the
calling side whereas a constant reference would prevent that. This
change makes the two behaviors consistent.
4. The supposed assurance that the `ArrayHandle` would not be reallocated
was easy to break even accidentally. If the `ArrayHandle` was assigned
to another `ArrayHandle` (for example as a class' member or wrapped
inside of an `UnknownArrayHandle`), then the array was free to be
reallocated.
