Added features with reporting types with `UnknownArrayHandle`. First,
added a method named `GetArrayTypeName` that returns a string containing
the type of the contained array. There were already methods
`GetValueType` and `GetStorageType`, but this provides a convenience to
get the whole name in one go.
Also improved the reporting when an `AsArrayHandle` call failed. Before,
the thrown method just reported that the `UnknownArrayHandle` could not
be converted to the given type. Now, it also reports the type actually
held by the `UnknownArrayHandle` so the user can better understand why
the conversion failed.
VTK-m contains a helpful method named `vtkm::cont::TypeToString` that
either takes a type as a template argument or a `std::type_info` object
and returns a human-readable string for that type.
The standard C++ library has an alternate for `std::type_info` named
`std::type_index`, which has the added ability to be used in a container
like `set` or `map`. The `TypeToString` overloads have been extended to
also accept a `std::type_info` and report the name of the type stored in
it (rather than the name of `type_info` itself).
39054e644 Add corner case unit test.
0a3fd2629 Add test file for corner case.
4b0896bd8 Fix for corner case in particle advection.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abhishek Yenpure <abhishek@uoregon.edu>
Merge-request: !2545
Since we have (hopefully) gotten rid of all unbounded recursion and
calls to function pointers or virtual methods, the CUDA compiler should
be able to statically determine the size of the stack needed. Thus, we
shouldn't need `ScopedCudaStackSize` at all.
However, there is one odd case where using it seems to be necessary. It
is unclear why, but that is an issue for another day.
The implementation of the search in the k-d tree is problematic because
it uses unbounded recursion. This is a problem for GPU devices, which
have very short stacks set by how many calls the compiler determines.
This is fixable, but the fix is not trivial.
This class is not used anywhere in VTK-m other than a trivial test.
Thus, I am just deprecating the class. I am also deleting the test, so
the code is not run anymore.
The maximum recursion that could happen was 1 call in, but compilers had
trouble determining that. Split this into 2 non-recursive functions so
the compiler can easily determine the stack depth.
It is sometimes the case that you want to copy the state of one
`RuntimeDeviceTracker` to another. This is particularly the case when
creating threads in the control environment. Each thread has its own
copy of `RuntimeDeviceTracker`, so when you spawn a thread you probably
want to copy the state of the tracker from the calling thread.
This method is a remenant of when `ArrayHandle` could only store data on
one device at a time. It is now capable of storing data on any number of
devices (as well as the host), so asking for "the" device no longer
makes sense. Thus, this method is deprecated in favor of
`ArrayHandle::IsOnDevice`.
This deprecation leads to fixing some older functionality that still
assumed data could only be on one device at a time.
Fixes#592.
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
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
