The `StorageListEfficientExtract` type is never used in
`UnitTestSerializationArrayHandle`. Although these types are used,
because they all support efficient component extraction from the array,
there is no need to treat them special. As such, this list was never
used.
When calling `ArrayExtractComponent`, some arrays cannot really have a
component extracted. In this case there is a fallback and a warning is
generated.
Of course it is good to test this behavior. The
`UnitTestArrayExtractComponent` does test this and as such generates
this warning (intentionally). Add a note to the output that this warning
is expected.
`ArrayHandleCast` was giving warnings about casting to a type that could
not hold the range to the source even when that was not true. The
problem was it was using `std::numeric_limits::min` for the lower end of
the range. But for floating point values, `min` is not really `min`.
Rather, it is the smallest representable number. (This is probably a C++
bug we are stuck with.) You really need to use `lowest`.
The actually serialization was not doing any inefficient component
extraction, but the array handle comparisons were. This made it hard to
verify that the actual serialization was not being slow. Fixed the
comparison to make sure that it only used efficient paths.
One of the tests was to make sure that the `ArrayHandleMultiplexer` is
working in the exec environment. It was doing this with an `ArrayCopy`.
However, the `ArrayCopy` was falling back to the host, so the test was
not doing what was expected.
Now use `DeviceAdapterAlgorithm::Copy` to force the array to work on the
device.
The `ExtractStructured` code was calling `ArrayCopy` on a permutation of
odd arrays, which was causing problems with the copy. Specifically use
`ArrayCopyDevice` to ensure the copy happens efficiently.
ca032801a Allow ArrayExtractComponent to work with Vec-like value types
f48b4b761 Add implementation of VecTraits for Range and Bounds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Gunther Weber <ghweber@lbl.gov>
Merge-request: !2683
af87308b9 better type safety, coding style conformation
16b8ed769 Merge branch 'new_contour' of gitlab.kitware.com:ollielo/vtk-m into new_contour
d8fdda5c3 use the new CreateResult
3a9e9f1ac Merge branch 'master' into new_contour
83c6032c9 minor update
1b028ab61 delete unused worklet unit test
175f9010a Merge branch 'master' into new_contour
5e991e4bf Merge branch 'master' into new_contour
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2669
The original version of `Filter` classes had a helper header file named
`CreateResult.h` that had several forms of a `CreateResult` function that
helped correctly create the `DataSet` to be returned from a filter's
`DoExecute`. With the move to the `NewFilter` structure, these functions
did not line up very well with how `DataSet`s should actually be created.
A replacement for these functions have been added as protected helper
methods to `NewFilter` and `NewFilterField`. In addition to moving them
into the filter themselves, the behavior of `CreateResult` has been merged
with the map field to output functionality. The original implementation of
`Filter` did this mapping internally in a different step. The first design
of `NewFilter` required the filter implementer to call a
`MapFieldsOntoOutput` themselves. This new implementation wraps the
functionality of `CreateResult` and `MapFieldsOntoOutput` together so that
the `DataSet` will be created correctly with a single call to
`CreateResult`. This makes it easier to correctly create the output.
`RectilinearLocator::LocateCell` and `UniformLocator::LocateCell` assume
that the point in inside the bounds of the cell set, but may return a
cell location that does not exist, i.e., cell location that is outside
of the bounds of the cell set due to errors from floating point
operations.
This fix, given the assumption above, bounds the calculated cell
location to within the cellset by capping the indices to within the
limits.
Before, `ArrayExtractComponent` only worked with `Vec` types. Anything
that was not specifically a `Vec` was assumed to be a basic component
even if it had `VecTraits`. This was changed to extract components out
of anything that has `VecTraits`. The assumption is that all components
of the Vec-like object are packed tightly in the object.
This allows `ArrayExtractComponent` to work with objects like
`vtkm::Range` and `vtkm::Bounds` and extract their parts as expected.
Added specializations of `vtkm::VecTraits` for the simple structures of
`vtkm::Range` and `vtkm::Bounds`. This expands the support for using
these structures in things like `ArrayHandle` and `UnknownArrayHandle`.
32507a510 Update CrossProduct filter to new filter base class
72065024a Add CastAndCallScalarField and CastAndCallVecField to NewFilterField
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2681
0c47645ba Remove DotProduct from worklet directory
d76929a78 Allow dot product to work with any field type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2682
The previous implementation of the `DotProduct` filter only worked with
arrays containing "common" types. The filter has been updated to use the
extract component feature of `UnknownArrayHandle` to support computing
the dot product of arrays of almost any type.
These methods somewhat simplify doing the `CastAndCall` from an
`UnknownArrayhandle` that comes from an input field.
The motivation for this change is for the User's guide, where I am
having a chicken-and-egg problem of wanting to describe how to make a
simple filter implementation without having to go into details about
`UnknownArrayHandle`.
The `ArrayCopy` method has been changed to be precompiled. It handles
most standard array types. But there are some special `ArrayHandle`
types that are not correctly handled, and these go to a slow fallback.
Find places in the code that use that fallback and fix them.
There are also some instances of replacing an `ArrayHandleCounting` with
an `ArrayHandleIndex`. This change is probably not strictly necessary to
make the `ArrayCopy` faster, but when it can be used `ArrayHandleIndex`
is generally better.
Many arrays decorate other arrays but still allow an efficient component
extraction. However, the component can only be extracted if it can be
efficiently extracted from the array being decorated. In this case, the
array reported that it could efficiently extract even though it could
not.
Fixed this by having the `ArrayExtractComponentImpl` classes inherit
from the respective superclass. This will in turn inhert the
`ArrayExtractComponentImplInefficient` if it is the base class.
There are some common uses of `ArrayCopy` that don't use basic arrays.
Rather than move away from `ArrayCopy` for these use cases, compile a
special fast path for these cases.
This required some restructuring of the code to get the template
resolution to work correctly.
Rather than require `ArrayCopy` to create special versions of copy for
all arrays, use a precompiled versions. This should speed up compiles,
reduce the amount of code being generated, and require the device
compiler on fewer source files.
There are some cases where you still need to copy arrays that are not
well supported by the precompiled versions in `ArrayCopy`. (It will
always work, but the fallback is very slow.) In this case, you will want
to switch over to `ArrayCopyDevice`, which has the old behavior.
There was a precompiled version of mapping permutations in the
filter library. However, there are reasons to be able to copy
a permutation of an array outside of filters. So add the
capability to the more general filter library.
