The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from
the `UnknownArrayHandle` was on a device. Seems right, but it is
actually operating on an `ArrayHandleRecombineVec`. This is a special
array that mostly behaves like other `ArrayHandle`s, but because it has
variable vec size, it breaks some `ArrayHandle` conventions.
One of the iffy things it has to do is stick the dependent `Buffer`
objects into the metadata of its own `Buffer` rather than list them in
the `Buffer` list. This means that `ArrayHandle` cannot properly check
them to see where they are located. Instead, it just sees that the one
`Buffer` it has is empty.
A recent change to `IsOnDevice` made it return true for any device if
the `Buffer` is empty. So previously this was broken in that it reported
that the array was not on any device. That changed to report that it was
on all devices, even inactive ones. So the code went from not
efficiently copying to throwing an exception.
This has been fixed by pulling one of the dependent arrays and checking
that one.
Previously, all of the `ArrayGetValues` implementations were templated
functions that had to be built. That meant that any code using them had
to be compiled with a device compiler and create special code for it.
This change uses an `UnknownArrayHandle` to encapsulate the
`ArrayHandle` and call a per-compiled library function. This means that
the code only has to be compiled once.
3feff3689 Save device choice on spawned control threads
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2543
Having UnknownArrayHandle.h include DefaultTypes.h is problematic,
because that header includes lots of other classes like cell sets.
Keeping these from in turn depending back on UnknownArrayHandle.h is
difficult. So this dependancy is broken.
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.
The `RuntimeDeviceTracker` is a thread-local variable that monitors the
devices to use separately on each thread. This is an important feature
to allow different threads to control different devices.
When a tracker is created on a new thread, it was simply reset, which
makes sense. However, the reset does not take into account the device
selected by `vtkm::cont::Initialize`. This means that if VTK-m was used
in a different thread than it was initialized, it would ignore the
`--vtkm-device` parameter.
To get around this problem, keep track of the `RuntimeDeviceTracker` on
the "main" thread. When a `RuntimeDeviceTracker` is created on a new
thread, it copies the state from that tracker.
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
f878ba8da Move the check for 0 inputs. With mpi, 0 input is ok for a rank.
4b2dbfbad Remove unused header.
b08082472 Clean up the code a bit.
c4341adfe update cmakelists.txt. The merge somehow missed this..
90bed8d0c refactor particle adv-based filters and make a temporal particle adv filter.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2515
`UnknownArrayHandle` supported an `Allocate` method to change
the size of the underlying array without knowing its type.
However, it did not give all the features of `ArrayHandle`'s
allocate. Namely, you could not specify that the data should
be preserved and you could not provide a `Token` object. This
change adds these (optional) parameters.
TBB 2020 introduced a new class called `task_group`. TBB 2021 removed
the old class `task` as its functionality was replaced by `task_group`.
Our parallel radix sort for TBB was implemented using `task`s, so change
it to use `task_group` (which actually cleans up the code a bit).
