6592e5288 Fix IsWritableArrayHandle for portals that exist but cannot be written
0e15a1116 Enable writing to ArrayHandleCast
6d37ce945 Remove invalid PortalType
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1731
Previously, IsWriteableArrayHandle just checked to see if an
ArrayHandle's portal has a ValueType of void* because we had coded the
special read-only array handles to have fake portals for writing.
However, we recently removed that because it was more trouble than it
was worth. Now IsWritableArrayHandle checks for the existance of the Set
method. If it does not exist, then the portal is considered read-only.
Also corrected spelling (writeable -> writable).
Previously, `ArrayHandleCast` was considered a read-only array handle.
However, it is trivial to reverse the cast (now that `ArrayHandleTransform`
supports an inverse transform). So now you can write to a cast array
(assuming the underlying array is writable).
One trivial consequence of this change is that you can no longer make a
cast that cannot be reversed. For example, it was possible to cast a simple
scalar to a `Vec` even though it is not possible to convert a `Vec` to a
scalar value. This was of dubious correctness (it is more of a construction
than a cast) and is easy to recreate with `ArrayHandleTransform`.
Several ArrayHandles (actuall Storage implementations) had a fake portal
type that only defined invalid value types and no Get/Set methods. The
idea was to quickly identify when using a read-only array for writing.
However, this was more trouble than it was worth as the compiler just
gives an incomprehensible error and it is hard to track down the actual
value.
Now actually define some type even if it is never used.
b622c7962 Fixed index out of bounds error for the cell counts array
4d61066e9 Removed all modifications in the internal device adapter algorithm header files.
06ac9f721 Revised version of the original mesh quality merge request
e54001367 Added few lines of code missing from cuda device adapter header
3dd34d251 Added custom CopyIf function
417dbcea7 Removed all modifications in the internal device adapter algorithm header files.
50cb805ce Fixed cuda device adapter alg
8c070caa0 Added few lines of code missing from cuda device adapter header
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1714
28484fc6a Update examples and benchmarks to use new VTK-m CMake helper function
ea50e82aa Move VTK-m CMake testing wrappers to the testing folder
0b7dd7c38 Add CMake vtkm_add_target_information() to make using vtk-m easier
e934e2273 vtkm_library WRAP_FOR_CUDA renamed to clarify the intent of the property
a2e6660fd Remove unused vtkm_compile_as_cuda CMake function
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1718
461f87dbc Fix issues with PointLocatorUniformGrid not finding all points
e473cb4bb Fix PointLocatorUniformGrid for points on boundary
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !1720
There was a known issue where PointLocatorUniformGrid would quickly quit
once it found a point. Instead, look at one more level of bins just in
case there is a closer one near the boundary. (Still not guaranteed, but
likely.)
Also, fix a typo that caused some bins in the y and z direction to not
be searched.
When creating the search structures in PointLocatorUniformGrid, a point
outside the boundary would be given an invalid bin id. These points
could never be found. Generally, this is not a big deal for points
outside of the boundary, but it could be a problem for points on the
boundary. A point on the boundary could be taken as outside the
boundary. Since the boundary is chosen from limits of the points, some
will almost always be on the boundary.
Fix this problem by clamping all points to the nearest valid bin. This
could cause a problem if the user has selected a boundary excluding a
lot of points. All those points could be grouped to the same edge bins,
but that is probably not a great idea anyway.
The VTK-m testing infrastructure isn't public facing so it doesn't
need to be installed or clutter the main VTKmWrappers file.
At the same time I have refactored the code to make it clearer
to understand, and remove unused options.
We want the option name to be clear that it might be applicable for
more than just CUDA. If VTK-m ever supported something like SYCL
it would not be clear that those sources should go in `WRAP_FOR_CUDA`.
