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.
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.
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.
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
`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).
Years ago we discovered a problem with TBB's parallel sort, which we
patch in our local repo and submitted a change to TBB, which has been
accepted.
The code to decide whether to use our parallel_sort patch does not work
with the latest versions of TBB because it requires including a header
that changed names to get the TBB version.
We no longer support any TBB version with this bug, so just remove the
patch from VTK-m.
The list defining the common storage types was defined in
DefaultTypes.h.in. The problem was that derived default types could not
just add their own type. They had to redefine the whole list.
Instead, move the list to StorageList.h. Also updated
DefaultTypesVTK.h.in to use this list when using XGC. This enables
ArrayHandleSOA for this case.
968c66f94 add TODO to update kokkos initialize
18d7827db update vtkm test arguments
5fa8734bb update vtkm initialize flags to have 'vtkm' prefix and deprecate old flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2456
Deprecate `VirtualObjectHandle` and all other classes that are used to
implement objects with virtual methods in the execution environment.
Additionally, the code is updated so that if the
`VTKm_NO_DEPRECATED_VIRTUAL` flag is set none of the code is compiled at
all. This opens us up to opportunities that do not work with virtual
methods such as backends that do not support virtual methods and dynamic
libraries for CUDA.
The both the underlying `UnknownArrayHandle` and `ArrayHandleVirtual`
handle `ArrayHandleCast` specially. This caused problems when passing an
`ArrayHandleCast` to `VariantArrayHandle::AsVirtual`. Solve the problem
by stripping out the cast storage tags and letting these classes handle
it internally.
It's annoying to have to fix a problem in a method of a deprecated class
that returns another class that is deprecated for a different reason. No
one should really be running this.
`UnknownArrayHandle` treats a `ArrayHandleCast` and
`ArrayHandleMultiplexer` special. When you put one of these arrays in an
`UnknownArrayHandle`, it takes the original array out and stores it. If
you try to take an array of that type out, it will again do the proper
conversion.
The only problem is that if you use `IsType`, the result can be
unexpected. This is what happened with `CastAndCall`, which was using
`IsType` internally. Changed that to `CanConvert` to properly get the
array handle out.
`VaraintArrayHandle` has been replaced by `UnknownArrayHandle` and
`UncertainArrayHandle`. Officially make it deprecated and point users to
the new implementations.
Using this internal class is a bit tricky because it requires a pointer
to a C array that is expected to contain portals. Both the C array and
the portals must be defined for the expected device. This is already
handled by the associated Storage. Assuming all of this holds, make sure
the `ArrayPortalRecombineVec` is trivially copyable. This is a
requirement for passing objects to the execution environment.