The `GetNumberOfComponents` and `GetNumberOfComponentsFlat` methods in
`UnknownArrayHandle` have been updated to correctly report the number of
components in special `ArrayHandle`s where the `Vec` sizes of the values
are not selected until runtime.
Previously, these methods always reported 0 because the value type could
not report the size of the `Vec`. The lookup has been modified to query the
`ArrayHandle`'s `Storage` for the number of components where supported.
Note that this only works on `Storage` that provides a method to get the
runtime `Vec` size. If that is not provided, as will be the case if the
number of components can vary from one value to the next, it will still
report 0.
This feature is implemented by looking for a method named
`GetNumberOfComponents` is the `Storage` class for the `ArrayHandle`. If
this method is found, it is used to query the size at runtime.
Previously, `VectorMagnitude` only worked with `Vec`s of size 2, 3, or
4. It now works with `Vec`s of any size. It also avoids a memory copy of
non-float types (although it does add a little arithmetic in the
computation).
CUDA 12 adds a `cub::Swap` function that creates ambiguity with `vtkm::Swap`.
This happens when a function from the `cub` namespace is called with an object
of a class defined in the `vtkm` namespace as an argument. If that function
has an unqualified call to `Swap`, it results in ADL being used, causing the
templated functions `cub::Swap` and `vtkm::Swap` to conflict.
Previously, the probe filter only worked on certain `Vec` sizes and
converted many types to floating point.
This change uses the extract component feature to pull data from any
array at its natural component type.
The bad part of this change is that it has to call the worklet
separately for each component in the field. That adds overhead and
probably lowers the cache efficiency. It was implemented this way
because the cell interpolation function does not work with the
recombined vecs returned from extract array.
The `Fetch::Load` for an input array of a topology map for an XGC array
(that uses `ConnectivityExtrude`) was failing to compile because it
creates a return `Vec` and then fills it. That does not work if the
input array has values that cannot be default constructed. This is the
case for `ArrayHandleRecombineVec`, which creates values that lazily
pull data out of portals.
Change the code to careful construct the return `Vec` such that it does
not require the default constructor of the components.
The previous version of the `PointAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `PointAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
The previous version of the `CellAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `CellAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
Use the `MapFieldPermutation` function when mapping point coordinates
for points that are removed. (This function was already being used for
the rest of the fields.) Also remove some unneeded code in the
`CleanGrid` worklets.
719d347fd Update contour filter's field map to work on any field type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2973
447b8e711 Fill input to test of array extract from stride array
726bb0910 Fix floating point exception in Kokkos sort
89245c3df Remove NUMA regions option
4912d1d04 Update --kokkos-threads to --kokkos-num-threads
9f77e1118 Do not test if Kokkos device id does not match
fa30d6774 Update the minimum Kokkos required to 3.7
3a96e9429 ci: update Kokkos docker images
674572419 Use Kokkos 3.7.1 in the CI builds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2967
Use the extract component functionality to get data from any type of
array. This prevents converting fields to `vtkm::DefaultFloat` and
supports any size `Vec` in the component.
THe current version of sort in Kokkos does not check whether the array
is of size 0, and that messes up its bin calculation. If the size of the
array is less than 2, skip the sort since the order cannot change.
This configuration option was only added because Kokkos has such a flag.
But this flag is now deprecated in Kokkos and has no effect, so remove
it from VTK-m.
There was a regression test to check for an exception if the requested
Kokkos device id did not match the `KOKKOS_DEVICE_ID` environment
variable. New versions of Kokkos do not throw an exception (they just
pick one over the other), so remove this check.
The previous implementation of the map field in the clip filters
(`ClipWithField` and `ClipWithImplicitFunction`) checked for common field
types and interpolated those. If the field value type did not match, it
would either convert the field to floats (which is at odds with what VTK
does) or fail outright if the `Vec` length is not supported.
The map field function for clip has been changed to support all possible
types. It does this by using the extract component functionality to get
data from any type of array.
When you use an `ArrayHandle` as an output array in a worklet (for example,
as a `FieldOut`), the fetch operation does not read values from the array
during the `Load`. Instead, it just constructs a new object. This makes
sense as an output array is expected to have garbage in it anyway.
This is a problem for some special arrays that contain `Vec`-like objects
that are sized dynamically. For example, if you use an
`ArrayHandleGroupVecVariable`, each entry is a dynamically sized `Vec`. The
array is referenced by creating a special version of `Vec` that holds a
reference to the array portal and an index. Components are retrieved and
set by accessing the memory in the array portal. This allows us to have a
dynamically sized `Vec` in the execution environment without having to
allocate within the worklet.
The problem comes when we want to use one of these arrays with `Vec`-like
objects for an output. The typical fetch fails because you cannot construct
one of these `Vec`-like objects without an array portal to bind it to. In
these cases, we need the fetch to create the `Vec`-like object by reading
it from the array. Even though the data will be garbage, you get the
necessary buffer into the array (and nothing more).
Previously, the problem was fixed by creating partial specializations of
the `Fetch` for these `ArrayHandle`s. This worked OK as long as you were
using the array directly. However, the approach failed if the `ArrayHandle`
was wrapped in another `ArrayHandle` (for example, if an `ArrayHandleView`
was applied to an `ArrayHandleGroupVecVariable`).
To get around this problem and simplify things, the basic `Fetch` for
direct output arrays is changed to handle all cases where the values in the
`ArrayHandle` cannot be directly constructed. A compile-time check of the
array's value type is checked with `std::is_default_constructible`. If it
can be constructed, then the array is not accessed. If it cannot be
constructed, then it grabs a value out of the array.
This feature enables the ability to anonomously create an array (such as
with `UnknownArrayHandle::NewInstance()`) and then use that as an output
array.
This feature enables the ability to anonomously create an array (such as
with `UnknownArrayHandle::NewInstance()`) and then use that as an output
array. Although resizing `ArrayHandleStride` is a little wonky, it
allows worklets to resize them after creation rather than having to know
what size to make and allocating the array.
CUDA 12 adds a `cub::Swap` function that creates ambiguity with `vtkm::Swap`.
This happens when a function from the `cub` namespace is called with an object
of a class defined in the `vtkm` namespace as an argument. If that function
has an unqualified call to `Swap`, it results in ADL being used, causing the
templated functions `cub::Swap` and `vtkm::Swap` to conflict.
The fields in a `DataSet` are indexed from `0` to `GetNumberOfFields() - 1`.
It is natural to assume that the fields will be indexed in the order that
they are added, but they are not. Rather, the indexing is arbitrary and can
change any time a field is added to the dataset.
To make this more clear, Doxygen documentation is added to the `DataSet`
methods to inform users to not make any assumptions about the order of
field indexing.