This resolves a compiler ambiguity I hit during development.
In my case, I created an `ArrayHandleDecorator` with one of the arrays being
an `ArrayHandleTransform`. The ambiguity occurs in function
`DecoratorStorageTraits<...>::BuffersToArray`, here an `ArrayHandleTransform`
is constructed using buffers (`std::vector<vtkm::cont::internal::Buffer>`)
This constructor is not defined for `ArrayHandleTransform`, but it's defined for
its superclass (`vtkm::cont::ArrayHandle`). `ArrayHandleTransform` does have a
non-explicit constructor that takes the array to be transformed and the
transform-functor as parameters, where the later has a default value.
This produces the following ambiguous options for the compiler:
1. Create a "to-be-transformed" ArrayHandle instance using the buffers, call
the `ArrayHandleTransform` constructor with this array with the defaulted
functor parameter.
2. Create the superclass instance using the buffer and call the
`ArrayHandleTransform` constructor that takes the superclass.
In this situation, option 2 is the correct choice.
The ambiguity is resolved by marking the constructors that take
buffers as explicit. These constructors are also added for the
derived classess via the `VTK_M_ARRAY_HANDLE_SUBCLASS_IMPL` macro.
There are occasions when you need a worklet to opeate on 2D or 3D
indices. Most worklets operate on 1D indices, which requires recomputing
the 3D index in each worklet instance. A workaround is to use a worklet
that does a 3D scheduling and pull the working index from that.
The problem was that there was no easy way to get this 3D index. To
provide this option, a feature was added to the `BoundaryState` class
that can be provided by `WorkletPointNeighborhood`.
Thus, to get a 3D index in a worklet, use the
`WorkletPointNeighborhood`, add `Boundary` as an argument to the
`ExecutionSignature`, and then call `GetCenterIndex` on the
`BoundaryState` object passed to the worklet operator.
Add a regression test for passing a variant as an argument to a worklet.
Variants are tricky objects, and the compiler might make some strange
assumptions during optimization.
One case that popped up in particular was when a variant contained two
objects with the same `sizeof` but the first object had padding. When the
variant contained the second object, the value under the padded part of
the first object was not set.
While adding checks to the size of implicit arrays, it was discovered
that some of the Mask and ScatterPermutation arrays were constructed
with the wrong sizes during dispatch. In particular, these arrays were
supposed to be sized on the output, but were instead sized on the input.
They went unnoticed because they were using implicit arrays that worked
even if the array access went out of bounds.
The previous version of the `PointAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `PointAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
The previous version of the `CellAverage` filter used a float fallback
to handle most array types. The problem with this approach other than
converting field types perhaps unexpectantly is that it does not work
with every `Vec` size. This change uses the extract by component feature
of `UnknownArrayHandle` to handle every array type.
To implement this change the `CellAverage` worklet had to be changed to
handle recombined vecs. This change resulted in a feature degridation
where it can no longer be compiled for inputs of incompatible `Vec`
sizes. This feature dates back to when worklets like this were exposed
in the interface. This worklet class is now hidden away from the exposed
interface, so this degredation should not affect end users. There are
some unit tests that use this worklet to test other features, and these
had to be updated.
With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
The name of the methods were changed from `AddGhostCellField` to
`SetGhostCellField` since only one field can be marked as the cell
ghost. Also automatically select a field that matches
`GetGlobalCellFieldName` if nothing else is set.
The cell set created in the `SplitSharpEdges` filter had the number of
points of the input, not the output. This inconsistency became worse now
that `DataSet` is doing more to check the consistency of point and cell
field lengths.
`ExecutionWholeArray` is an archaic class in VTK-m that is a thin wrapper
around an array portal. In the early days of VTK-m, this class was used to
transfer whole arrays to the execution environment. However, now the
supported method is to use `WholeArray*` tags in the `ControlSignature` of
a worklet.
Nevertheless, the `WholeArray*` tags caused the array portal transferred to
the worklet to be wrapped inside of an `ExecutionWholeArray` class. This
is unnecessary and can cause confusion about the types of data being used.
Most code is unaffected by this change. Some code that had to work around
the issue of the portal wrapped in another class used the `GetPortal`
method which is no longer needed (for obvious reasons). One extra feature
that `ExecutionWholeArray` had was that it provided an subscript operator
(somewhat incorrectly). Thus, any use of '[..]' to index the array portal
have to be changed to use the `Get` method.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
This commit address issue #713 and removes the need to pass information
about the spatial decomposition (block origins, block sizes, block index
and blocks per dimension) to the contour tree filter. Block origin
information is added to CellSetStructured (as GlobalPointSize) and the
distributed contour tree filter will get this information from
CellSetStructured instead of expecting it as parameters to the
constructor. Information about blocks per dimension and block indices
are computed from the information in CellSetStructure albeit requiring
global communication across all ranks. To avoid this communication cost,
the caller of the filter may explicitly specify this information via the
SetBlockIndices() method.
898a3e092 Move StreamSurface into NewFilterField
5ffae6111 Use CastAndCallForTypes with UnknownArray of seeds.
061fe6afb Fix dashboard compile errors.
42fd70d50 Remove virtuals from DataSetIntegrator classes.
2524c16a0 Missed some cuda fixes filters...
e1fbfea30 Remove device compiler dependencies.
2a4430447 tests need to be device compiled.
9b2a257d9 Move include out of .h file.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2777
AddGhostCellField function for Dataset class
setGhostCellName function for GhostCellClassify class
setGhostCellName function for GhostCellClassify class
added default ghost cell name in Dataset class
Default ghost cell field name defined in GhostCellClassify class
Default ghost cell field name for GhostCellClassify class
Unit test for ghost field name check
Unit test for ghost field name check updated
Default ghost field name updated
Get function for GhostCellClassify and default ghost name
UnitTestStreamlineFilter updated with AddGhostCellField
AddGhostCellField and GetGlobalGhostCellFieldName propagated
GhostCellClassify constructor now defined in header file
Assigned default values to dataset class members GhostSet and GhostCellName
default values set for GhostSet and GhostCellName in dataset constructor
Constructor removed from dataset class and noexcept for GetGlobalGhostName
added Dataset constructor with noexcept
additions to make sure default move constructor has not changed
GhostSetName field made as a shared pointer since string class is not noexcept
AddGhostCellField funtion added without field name
hasGhostCellField added and unit tests updated for addGhostCellField
hasGhostCellField added and unit tests updated for addGhostCellField
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
debugging UnitTestCellLocatorGerneral for CUDA error
UnitTestCellLocatorGeneral testing for error
UnitTestCellLocatorGeneral testing for cude error
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution print statement removed
Minor updates to Dataset class files
GlobalGhostCellFieldName implementation revised to return a static variable
GhostSet member removed, hasGhostCellField, constructor, copystructure updated
GetGhostCellField and GetGhostCellFieldName made cosistent with GetField
Fixes to a few function calls
nvcc is giving me lots of annoying warnings about unused functions.
Typically, this warning is given when a function declared as static or
in an anonymous namespace is never used. The "functions" in question are
not really functions. They are templated methods (in a class in an
anonymous namespace).
Specificaly, I'm getting errors like this:
```
/.../vtkm/cont/testing/UnitTestArrayHandleDecorator.cxx(96): warning #177-D: function "<unnamed>::DecoratorTests::InvertibleDecorImpl::CreateFunctor(PortalTs&&...) const [with PortalTs=<vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleCounting<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleConstant<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandle<vtkm::Int8, vtkm::cont::StorageTagBasic>>>]" was declared but never referenced
```
That said, these warnings appear to be an annoying but harmless bug in
nvcc. This warning is in error because
1. The method in question is _definitely_ being used.
2. I'm pretty sure this warning should not be given for a templated
method even if it was never used. SFINAE alone should be enough
justification to allow this to exist without warning.
The easiest way around the spurious error is to declare these structures
in a namespace with a name.
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
849106762 remove include CellDeepCopy
4108febd3 remove #include functional
daaac78f1 minor changes based on code review
aecdd7705 Update vtkm/filter/resampling/testing/CMakeLists.txt
38000ed6d Use ALL_BACKENDS for unit test
ab09f77b7 migrate Probe filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2771
`UnitTestDispatcherBase` previously used arrays from `std::vector` to
test dispatching data to worklets. This only works for devices that have
unified memory with the host.
Change the test to use `vtkm::cont::internal::Buffer` objects and
properly copy data to/from the device for devices that have separate
memory spaces.
There were several tests that were disabled for hip because they either
took too long to compile or were failing. We are getting closer to
making everything work, so re-enable this part of the build.
The enumerations in `vtkm::cont::Field::Association` were renamed in the
previous commit. The old names still exist, but are deprecated. Change
the rest of the code to use the new names.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
