There was a use of a deprecated method buried in a support class of
`WorkletCellNeighborhood`. This fixes that deprecation and also adds a
missing test for `WorkletCellNeighborhood` to prevent such things in the
future.
The header file `GenerateTestDataSets.h` was located in
`vtkm/worklet/testing`. However, the only tests that used this header
are in `vtkm/filter/flow/testing`. Thus, the header file is moved to where
it is used.
Some versions of doxygen have issues with documenting `typedef`s (or the
equivalent `using`). This was causing warnings with doxygen and failing
to create some of the documentation. This fixes the problem by moving the
documentation to the classes things are defined to.
The `DeviceAdapter` provides an abstract interface to the accelerator
devices worklets and other algorithms run on. As such, the programmer has
less control about how the device launches each worklet. Each device
adapter has its own configuration parameters and other ways to attempt to
optimize how things are run, but these are always a universal set of
options that are applied to everything run on the device. There is no way
to specify launch parameters for a particular worklet.
To provide this information, VTK-m now supports `Hint`s to the device
adapter. The `DeviceAdapterAlgorithm::Schedule` method takes a templated
argument that is of the type `HintList`. This object contains a template
list of `Hint` types that provide suggestions on how to launch the parallel
execution. The device adapter will pick out hints that pertain to it and
adjust its launching accordingly.
These are called hints rather than, say, directives, because they don't
force the device adapter to do anything. The device adapter is free to
ignore any (and all) hints. The point is that the device adapter can take
into account the information to try to optimize for itself.
A provided hint can be tied to specific device adapters. In this way, an
worklet can further optimize itself. If multiple hints match a device
adapter, the last one in the list will be selected.
The `Worklet` base now has an internal type named `Hints` that points to a
`HintList` that is applied when the worklet is scheduled. Derived worklet
classes can provide hints by simply defining their own `Hints` type.
The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an
`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array.
Of these, the `Counts` array is redundant because the counts are trivially
computed by subtracting adjacent entries in the offsets array. This pattern
shows up a lot in VTK-m, and most places we have moved to removing the
counts and just using the offsets.
This change removes the `Count` array from the `Keys` object. Where the
count is needed internally, adjacent offsets are subtracted. The deprecated
`GetCounts` method is implemented by copying values into a new array.
This feature was introduced but is never used anywhere. It is up to the
worklet subclass to determine what to do with the boundaries with the
`BoundaryState` object.
In the future we may have a neighborhood worklet of compile-fixed sized
for better memory access efficiency. If that is the case, we can
reintroduce this idea. We can decide on the right implementation if that
design ever comes to pass.
Adding `0.5` is not correct in all cases. Namely, adding `0.5` will
cause the value immediately before it to be rounded to `1` due to the
"round to nearest even" rule. Trust the standard library to get this
right.
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.
