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
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.
When `PointTransform` was converted to the new filter structure, some of
the methods that were moved from .hxx to .cxx (and therefore compiled in
a library) were still marked as `inline`. This caused the compiler to
not compile the function into the library if it was not used. Fix the
problem by removing the `inline` modifier to the method implementations.
The scalar field difference along x, y, and z should be divided by the
spacing not multiplied. This was causing some test failures in VTK and
ParaView when overriding the default contour filter with `vtkmContour`.
Previously, the mesh parameters used for the `ParticleDensity` filters
had to be provided in the constructor. However, this is different than
most other filters in VTK-m. It also can be more error prone as it is
easy to mix up unnamed arguments.
Add methods to `ParticleDensityBase` to allow setting/getting parameters
like `Dimensions` and `Bounds` to make it more clear what the values
mean.
The deprecated class `vtkm::filter::MeshQuality` contained a private
method that was referenced in its inlined constructor. The problem was
that this private method was compiled in the `vtkm_filter_mesh_info`
library but not properly exported. Fix this by adding an export to the
class.
e6b37f7a4 Remove deprecated use of old unscoped enums in FieldToColors
f37cc7657 Use scoped enum for FieldToColors modes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2734
For the templated methods that we are precompiling instances for, do not
put their implementation inside of the class declaration. The problem is
that if you define a method inside of a class, it is implicitly inline.
If it is inline, a compiler might choose to compile it even if an
external symbol exists.
It appears that some compilers treat template instances different than
calling a template. For example, if you have
```cpp
template <typename T, typename U>
void Foo(T t, U u);
template <typename T>
void Foo(T t, int u);
template void Foo(int t, int u);
```
that some compilers will complain that the instance is ambiguous because
it matches both versions of Foo even though the second one is the one
that is called (unless you specifically declare template parameters).
This is what happend with the gradient instances. Fix the problem by
wrapping the "ambiguous" cases to be called by a simple, single
templated function.
When the gradient filter was moved over to the new filter structure, it
lost its instantiations. This is a problem because the gradient filter,
which compresses a lot of the code into single worklet calls for
efficiency, is one of the longest to compile filters.
This commit restores the instantiations with the updated instantiation
functionality. This breaks up the code into many translation units that
can be compiled simultaneously and thus not hold up the entire compile
on one process.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.
When the Marching Cubes algorithm merges points together for multiple
isosurfaces, it uses an ArrayHandleZip to combine the isosurface id and
the edge identification. This is to prevent merging points from
different isosurfaces. However, internally this has to do an array copy.
It was doing this copy with `ArrayCopy`. A recent change to that method
made the copy fail for `ArrayHandleZip`. The fix is to change to
`ArrayCopyDevice`.
The reason why this bug was introduced was because there was no test
case for this specific use. A regression test has been updated to test
for this case.
