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.
There are some special functions/methods that take as an argument a
function-like object and then call that function with some arguments.
There are some instances where a templated function was passed given the
appropriate template. Even though there is a specific function, this
gets passed as a function pointer and calling a function pointer on some
devices is a no-no.
Replace these function arguments with lambdas, which are constructed as
unnamed functor objects.
The member variables of the `vtkm::Particle` classes are now hidden. This
means that external code will not be directly able to access member
variables like `Pos`, `Time`, and `ID`. Instead, these need to be retrieved
and changed through accessor methods.
This follows standard C++ principles. It also helps us future-proof the
classes. It means that we can provide subclasses or alternate forms of
`Particle` that operate differently. It also makes it possible to change
interfaces while maintaining a deprecated interface.
The PerlinNoise source has a mode where if a seed is not set, it will
choose a new seed every time it is executed. It did this by using the
value 0 as an indicator to do this (and initializing the Seed to 0).
However, there was a problem with one of the benchmarks that was
specifically setting the seed to 0 and getting unexpected results.
Fix the problem by adding a separate, hidden member of the PerlinNoise
class that keeps track of whether to generate new seeds or not.
aa7b83bb2 Handle random seed generation better for PerlinNoise
84bc72312 Make source parameters more clear
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2933
During the VTK-m 1.8 and 1.9 development, the filter infrastructure was
overhauled. Part of this created a completely new set of base classes. To
avoid confusion with the original filter base classes and ease transition,
the new filter base classes were named `NewFilter*`. Eventually after all
filters were transitioned, the old filter base classes were deprecated.
With the release of VTK-m 2.0, the old filter base classes are removed. The
"new" filter base classes are no longer new. Thus, they have been renamed
simply `Filter` (and `FilterField`).
Originally, most of the sources used constructor parameters to set the
various options of the source. Although convenient, it was difficult to
keep track of what each parameter meant. To make the code more clear,
source parameters are now set with accessor functions (e.g.
`SetPointDimensions`). Although this makes code more verbose, it helps
prevent mistakes and makes the changes more resilient to future changes.
This method is principally obsolete and should have been removed when
coordinate systems were converted into fields. I noticed it was still
there when updating the documentation.
This removal required some changes to the CleanGrid filter, but this
actually simplified the code.
With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s.
However, a `CoordinateSystem` is really just a `Field` with some special
attributes. Thus, coordiante systems are now just listed along with the
rest of the fields, and the coordinate systems are simply strings that
point back to the appropriate field. (This was actually the original
concept for `DataSet`, but the coordinate systems were separated from
fields for some now obsolete reasons.)
Previously, point fields compressed by ZFP were attached as point fields
on the output. However, using them as a point field would cause
problems. So, instead attache them as `WholeDataSet` fields.
Also fixed a problem where the 1D decompressor created an output of the
wrong size.
The `VTKM_LOG_SCOPE` macro was not working as intended. It was supposed
to print a log message immediately and then print a second log message
when leaving the scope along with the number of seconds that elapsed
between the two messages.
This was not what was happening. The second log message was being
printed immediately after the first. This is because the scope was taken
inside of the `LogScope` method. The macro has been rewritten to put the
tracking in the right scope.
The name of the methods were changed from `AddGhostCellField` to
`SetGhostCellField` since only one field can be marked as the cell
ghost. Also automatically select a field that matches
`GetGlobalCellFieldName` if nothing else is set.
