The `GhostCellRemove` filter had some methods inconsistent with the naming
convention elsewhere in VTK-m. The class itself was also in need of some
updated documentation. Both of these issues have been fixed.
Additionally, there were some conditions that could lead to unexpected
behavior. For example, if the filter was asked to remove only ghost cells
and a cell was both a ghost cell and blank, it would not be removed. This
has been updated to be more consistent with expectations.
Previously, `VecFromPortal` could only be set to a standard `Vec`.
However, because this is a `Vec`-like object with a runtime-size, it is
hard to do general arithmetic on it. It is easier to do in place so
there is some place to put the result. To make it easier to operate on
this as the result of other `Vec`-likes, extend the operators like `+=`,
`*=`, etc to support this.
The original intent of calling the `Statistics` filter on a
`PartitionedDataSet` was that the resulting `PartitionedDataSet` would
have partitions matching the input giving the statics of each partition
(as well as the overall statistics in global fields). There is a comment
in the code that says as much.
However, the partitioned version of `Execute` deleted the statistics.
This corrects the behavior by leaving in the partitions' statistics.
This is also now being tested.
75b4998de added fix using read portal after sort and unit test using on the fly dataset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !3102
There are numerous scripts and configuration files defined in the CI setup
and elsewhere that were missing the copyright statement. Add more types
of files to check in the CopyrightStatement test, and update the files
with the appropriate statement.
The CompositeVectors filter does not run any worklet of its
own. It uses precompiled array manipulation and copies for
its implementation.
It shouldn't matter if a device compiler is used. (It should
be a quick compile.) But for some reason the nvcc compiler
was choking on an `auto`. Rather than figure out why nvcc is
barfing, I just stopped using it for this file.
5d0481342 Fix compile issues when using cuda 12
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2960
(cherry picked from commit f8af0b17f4cc771ceb2cc2e2b40947be450099cc)
The `ExternalFaces` filter uses hash codes to find duplicate (i.e.
internal) faces. The issue with hash codes is that you have to deal with
unique entries that have identical hashes. The worklet to count how many
unique, unmatched faces were associated with each hash code was correct.
However, the code to then grab the ith unique face in a hash was wrong.
This has been fixed.
Fixes#789
Kokkos 4 switches from their interal library based off of desul to using desul directly.
This removes VTK-m's dependency on the Kokkos internal implementation (Kokkos::Impl) to
using desul directly.
This filter takes a `DataSet` and returns a point cloud representation that
has a vertex cell associated with each point in it. This is useful for
filling in a `CellSet` for data that has points but no cells. It is also
useful for operations in which you want to throw away the cell geometry and
operate on the data as a collection of disparate points.
Although the contour filter was recently divided into 2 filters, flying
edges and marching cubes, the marching cubes version still had many
conditions and was the file that took the longest to compile on Frontier.
To help speed up parallel compiles and prevent a single run of a
compiler from being overwhelmed, the compilation of all the marching
cubes conditions has been split up using instantiations.
8f4d5fdf8 Remove some unneeded test comments and debug code
7bea5413c Revert from VOIIsGlobal to IncludeOffset. Add comment about deprecation reasoning.
523c8f3f2 Add test whether GlobalPointDimensions are preserved
84e719ae1 Set GlobalPointIndexStart correctly, copy GlobalPointDimensions
e55b700f7 Deprecate SetIncludeOffset and rename to SetVOIIsGlobal
e013ad126 Add test for GlobalPointIndexStart to TestingExtractStructured
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abdelilah Essiari <aessiari@lbl.gov>
Merge-request: !3086
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.