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
5bd60a0b7 Add `CreateResult` to `NewFilter` and absorb field mapping
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2686
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.
