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).
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.
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.
