There was a use of a deprecated method buried in a support class of
`WorkletCellNeighborhood`. This fixes that deprecation and also adds a
missing test for `WorkletCellNeighborhood` to prevent such things in the
future.
We've been having problems with PerformanceTestBenchContour. In the last
few iteration, the runtime goes way up. We cannot find any reason for
this in the source code. There don't appear to be any particular
problems with memory or tables. The best we can figure is an issue with
the device hardware in the container.
The easy solution should be to break the benchmark into smaller peices
to avoid the problem.
VTK-m development is in a mode where backward compatibility should be
maintained between minor versions of the software. (You may get deprecation
warnings, but things should still work.) To match this behavior, the
generated CMake package now supports finding versions with the same major
release and the same or newer minor release. For example, if an external
program does this
``` cmake
find_package(VTKm 2.1 REQUIRED)
```
then CMake will link to 2.1 (of course) as well as newer minor releases
(e.g., 2.2, 2.3, etc.). It will not, however, match older versions (e.g.,
2.0, 1.9), nor will it match any version after the next major release
(e.g., 3.0).
There was an issue where if VTK-m was compiled with CUDA support but then
run on a computer where no CUDA device was available, an inappropriate
exception was thrown (instead of just disabling the device). The
initialization code should now properly check for the existance of a CUDA
device.
The `ExtractGeometry` filter was outputing datasets containing
`CellSetPermutation` as the representation for the cells. Although this is
technically correct and a very fast implementation, it is essentially
useless. The problem is that any downstream processing will have to know
that the data has a `CellSetPermutation`. None do (because the permutation
can be on any other cell set type, which creates an explosion of possible
cell types).
Like was done with `Threshold` a while ago, this problem is fixed by deep
copying the result into a `CellSetExplicit`. This behavior is consistent
with VTK.
The Intel compiler by default turns on an optimization that assumes that
all floating point values are finite. This breaks any ligitimate uses of
non-finite values including checking values with functions like `isnan`
and `isinf`. Turn off this feature for the intel compiler.
There are some overloads for atomic adds of floating point numbers for
older versions of cuda that do not include them directly. These were
misnamed and thus not properly overloading the generic implementation.
This caused compile errors with older versions of cuda.
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.
Threshold was producing wrong results with options `SetAllInRange(false)` and
`SetComponentToTestToAll` because the logic of running
`worklet::Threshold::RunIncremental` on individual components of the input
field and combining the results is incorrect for this case.
With this fix, component modes 'Any' and 'All' are handled by applying
the threshold criteria to each component of each value of the field,
combining the results, and running the threshold worklet on the result
array.
