The change affects the method GetThreadIndices for both
WorkletMapTopology and WorkletPointNeighborhood.
Before an scatter or mask which was not ScatterIdentity or MaskNone
was not allowed and it was enforced at compilation time.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Cell operations like interpolate and finding parametric coordinates can
fail under certain conditions. Typically these call RaiseError on the
worklet. But that can make a worklet unstable, so provide paths where no
error is raised.
aa7dcf915 push forward until new valid cell
6aafc42f1 move forward until encountering new cell for lost rays
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1985
fd3052542 Restructure Contour algorithm to make it easier to add specialized versions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1973
75cb53d3a Reset ArrayPortalToken when Detach is called
53c17a687 Release locks in ArrayHandleVirtual control portals
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1982
When `ArrayPortalToken::Detach` was called, the contained `Token` was
detached, but `ArrayPortal` being wrapped might also be holding its own
portal that it is decorating. To ensure that any dependent portals are
also detached, `ArrayPortalToken::Detach` resets itself.
This fixes an issue where getting a `ReadPortal` or a `WritePortal` from
an `ArrayHandleVirtual` could cause a deadlock from a held token even if
the returned portal was detached or destroyed.
The problem was that `ArrayHandleVirtual` was keeping a reference to the
`ArrayPortal` from the concrete array. This was because the returned
`ArrayPortalRef`, which was designed to work on both control and
execution environments, had no good way to destroy the portal. This
meant that the `ArrayHandleVirtual` was caching a copy of the concrete
array's portal. This was not a great idea before because the array could
get invalidated. It is worse now because it keeps the concrete array
locked.
Fixed the problem by subclassing `vtkm::ArrayPortalRef` to make a
control-specific version that will delete the concrete portal on its own
destruction.
424dfbaf5 Add call to UpdateSeedResoltuion() to set output dataset resolution.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !1981
This commit changes how CoordinateSystemTransforms write their result.
Before theoy would write their result in a DataSet in which the new
Coords where stored in a field with the name of:
- cylindricalCoordinateSystemTransform
- sphericalCoordinateSystemTransform
Now, they write their results as a DataSet in which its first Coords
are the transformed Coords. Previous Coordinates are appended
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
This commit also:
- Removes a corner case not longer used at ArrayPortalGroupVecVariable::get
- Changes doc regarding the number of offset elements in the input
array handler of ConvertNumComponentsToOffsets.
- Updates invokation of make_ArrayGroupVectVariable in multiple files
- Adds its corresponding changelog entry
1f1688483 Initial infrastructure to allow WorkletMapField to have 3D scheduling
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !1938
e5a6f2d4b Make ArrayPortalWrapper more tolerant of host objects
8569359e1 Add threads library to vtkm_cont
69c03d902 Fix deadlock in rendering
14c3d90ac Fix race condition in UnitTestToken
9b876df96 Remove PortalType from ArrayHandleImplicitTraits
188d1c567 Correct "invalid" portal in ArrayHandleTransform
ec34cb56c Use new ways to get array portal in control environment
8ddde979f ArrayPortalToIterators gets custom iterator from ArrayPortalToken
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !1953
The ArrayPortalWrapper is used for both execution and control portals.
When it was wrapped around a control portal that does not work on CUDA
devices, we were getting ugly warnings even though the intention was
only to use it in the control environment.
With the new thread safety/token code, the vtkm_cont library now relies
on the pthreads library (or whatever threads library is used by std on
the system). Make sure this library gets added to vtkm_cont.
Apparently when future::get returns, it is not the case that all
resources of the future are cleaned up (only that the calling function
has returned). Do not rely on this resource cleanup for the test to
pass.
The type for PortalType was declared before the class from which the
type came from. Normally this was not a big deal since the template was
resolved later, but nvcc seemed to have a problem with it.