There were several places in the code that had to check the type of an
`UnknownArrayHandle` and conditionally get or copy that array. This code
is simplified by using `ArrayCopyShallowIfPossible`.
Often times you have an array of an unknown type (likely from a data set),
and you need it to be of a particular type (or can make a reasonable but
uncertain assumption about it being a particular type). You really just
want a shallow copy (a reference in a concrete `ArrayHandle`) if that is
possible.
`ArrayCopyShallowIfPossible` pulls an array of a specific type from an
`UnknownArrayHandle`. If the type is compatible, it will perform a shallow
copy. If it is not possible, a deep copy is performed to get it to the
correct type.
Fixes#572.
ca86402f9 Provide additional debug info in case contour tree hangs
48d91b99f Throw exception if merge tree gets stuck in a loop
c7ea03ee2 Throw exception if contour tree gets stuck in a loop
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2420
f883b5e03 Avoid divide by zero in rendering TriangleIntersections
ede775692 Allow for empty Z bounds in ResetToBounds
4c1514bb3 Fix divide by zero in CanvasRayTracer
83369ed95 Remove unused fields from Ortho2DRayGen
c1a790db2 Fix BIH split calculations for empty regions
9ce97352d Fix divide-by-zero in UnitTestCellInterpolate
e4ae3cee1 Avoid floating point exception in Orthonormalize
f74a2239e Break LUP factorization when invalid matrix found
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Matt Larsen <larsen30@llnl.gov>
Merge-request: !2527
If the camera is not a 3D camera, then it might be the case that the
calling code has not set the bounds in the Z direction. Allow this to
happen as long as you are not using a 3D camera.
The divide by zero happened when mapping a surface to a depth buffer.
Some rays terminated at the origin, which is a singularity in the
project matrix.
This might be indicative of a larger problem. Rays really shouldn't
terminate before the near plane.
There were apparently some fields copy/pasted from the 3D version were
not used in the 2D version (probably because they had no meaning). In
one case, one was erroneously normalized, and could cause a floating
point exception.
When computing the cost for splitting, if a regions was empty you would
get a floating point error when multiplying the (invalid) region bound
(inf or -inf) with the number of points (0). It would then check for NaN
costs and reset that. This worked but caused a floating point exception,
which is problematic for some users.
Instead, check for empty regions before computing the cost and reset the
cost that way.
Singular matrices cannot be LUP factorized, so this condition is
detected and returned in a `valid` flag. However, when the detection
happened, the rest of the computation continued to happen. This could
lead to floating point exceptions, which some applications do not like.
So, when an invalid array is detected, return immediately.
Some functions are supposed to behave correctly when given a NaN. This
might only be valid if floation point exceptions are not trapped, so
disable trapping for these tests.
Some simulations trap floating point exceptions to ensure that their
code is working correctly, and we want VTK-m to work correctly in their
code. To check this, we want to turn on floating point exception
trapping in our test code. This is very implementation-specific, so for
now we are just turning it on for GCC. This will at least alert a
problem on some of the dashboards.
1. Use cudaPerThreadStream instead of the default streams
2. Since there have been changes to ArrayHandle code, the API to create
ArrayHandle from a device pointer has changed.
8d7cf2c85 Support all Allocate flags in UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2522