The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an
`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array.
Of these, the `Counts` array is redundant because the counts are trivially
computed by subtracting adjacent entries in the offsets array. This pattern
shows up a lot in VTK-m, and most places we have moved to removing the
counts and just using the offsets.
This change removes the `Count` array from the `Keys` object. Where the
count is needed internally, adjacent offsets are subtracted. The deprecated
`GetCounts` method is implemented by copying values into a new array.
This feature was introduced but is never used anywhere. It is up to the
worklet subclass to determine what to do with the boundaries with the
`BoundaryState` object.
In the future we may have a neighborhood worklet of compile-fixed sized
for better memory access efficiency. If that is the case, we can
reintroduce this idea. We can decide on the right implementation if that
design ever comes to pass.
Most of the CI builds are release, and the timeout set for them makes
sense. But for those debug builds, some of the longer-running tests
often exceed the provided timeout. To rightsize the timeouts, make them
longer for debug builds.
23fbedf54 Order the VTK scalar types to favor used types
053237e90 Favor base types used by VTK-m when making new basic array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3171
23fbedf54 Order the VTK scalar types to favor used types
053237e90 Favor base types used by VTK-m when making new basic array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3171
Reorder the `VTKScalarTypes` to put the repeated types at the bottom.
This will avoid using types like `long` that are essentially the same as
other types (e.g. `long long`) but will still be considered different.
This causes problems when checking against some VTK types (such as
`vtkIdType`).
When calling `NewInstanceBasic` on an `UnknownArrayHandle`, all C base
types will be tried. In some cases, multiple type will match the same
array. When this happens, favor types used by VTK-m (e.g. `long long`
over `long`).
The flying edges version of the contouring filter converted the isovalues
provided into the same type as the field. This is fine for a floating point
field, but for an integer field the isovalue was truncated to the nearest
integer.
This is problematic because it is common to provide a fractional isovalue
(usually N + 0.5) for integer fields to avoid degenerate cases of the
contour intersecting vertices. It also means the behavior changes between
an integer type that is directly supported (like a `signed char`) or an
integer type that is not directly supported and converted to a floating
point field (like potentially a `char`).
This change updates the worklets to allow the isovalue to have a different
type than the field and to always use a floating point type for the
isovalue.
2de1a462a support more volume types via array element conversion + ensure scalar data
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3167
4676d07f0 Fix error under CUDA with private class declarations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3165
nvcc doesn't like the couple of places that we have Impl classes hiding behind a
private declaration. So for VTKM_CUDA only, ifdef the private declaration out