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.
In addition to using uniform coordinates, the ContourFlyingEdges filter can now process any type of coordinate system, making the filter use Flying Edges in more cases
In order to compile the contour filter more efficiently, we split the contour filter into two separate translation units, corresponding to the new filters ContourFlyingEdges and ContourMarchingCells. The API for Contour filter is left totally unchanged, and tries to use flying edges if the dataset is structured and uniform.
All three contour filters inherit from the `AbstractContour` class, providing utility methods used in the implementations.
The clip filter used to copy the input points and point fields as is,
regardless of if they were actually part of the output. With this change,
we track which input points are actually part of the output and copy
only those values.
Address: #112
MR !2969 was meant to update the clip filters such that their field
mapping works on any field type and preserves the value type. Although
this was done for `ClipWithField`, it was not fully implemented for
`ClipWithImplicitFunction`. These changes update
`ClipWithImplicitFunction` to match its sibling.
Use the extract component functionality to get data from any type of
array. This prevents converting fields to `vtkm::DefaultFloat` and
supports any size `Vec` in the component.
The previous implementation of the map field in the clip filters
(`ClipWithField` and `ClipWithImplicitFunction`) checked for common field
types and interpolated those. If the field value type did not match, it
would either convert the field to floats (which is at odds with what VTK
does) or fail outright if the `Vec` length is not supported.
The map field function for clip has been changed to support all possible
types. It does this by using the extract component functionality to get
data from any type of array.
aa7b83bb2 Handle random seed generation better for PerlinNoise
84bc72312 Make source parameters more clear
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2933
During the VTK-m 1.8 and 1.9 development, the filter infrastructure was
overhauled. Part of this created a completely new set of base classes. To
avoid confusion with the original filter base classes and ease transition,
the new filter base classes were named `NewFilter*`. Eventually after all
filters were transitioned, the old filter base classes were deprecated.
With the release of VTK-m 2.0, the old filter base classes are removed. The
"new" filter base classes are no longer new. Thus, they have been renamed
simply `Filter` (and `FilterField`).
Originally, most of the sources used constructor parameters to set the
various options of the source. Although convenient, it was difficult to
keep track of what each parameter meant. To make the code more clear,
source parameters are now set with accessor functions (e.g.
`SetPointDimensions`). Although this makes code more verbose, it helps
prevent mistakes and makes the changes more resilient to future changes.
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.
Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s.
However, a `CoordinateSystem` is really just a `Field` with some special
attributes. Thus, coordiante systems are now just listed along with the
rest of the fields, and the coordinate systems are simply strings that
point back to the appropriate field. (This was actually the original
concept for `DataSet`, but the coordinate systems were separated from
fields for some now obsolete reasons.)
`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 was causing an issue in VTK as the VTK specific typelist was not
being used. This resulted in a field's type being changed from `UInt8` to
`Float32` and caused a test to fail.
There was a bug with Flying Edges checking the boundary conditions in
the z-direction. It was comparing the z index to the size of the y
dimension, not the z dimension. This simple typo was probably missed
because most of the tests use square meshes. To catch the problem, you
need a mesh that has a different number of points in the y and z
directions and the contour has to go past the positive z boundary.
When this error was hit, the indices for the edges on that boundary were
not recorded, and later interpolation used garbage values for edge's
point ids.
There were several cases where parameters of basic types were declared
const-by-value, instead of just by-value which is the convention
followed in vtk-m.
There were also some cases where compound types were being declared
const-by-value instead of const-by-reference.
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.
Previously, MIRFilter directly used MeshQuality's worklet to compute
areas/volumes. However, it is not a great idea to be touching the
internal worklets of other filters, which are going to change soon.
Besides, this should speed up compilation a little bit since the mesh
quality will only have to be compiled once.
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.
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.
5cb9792bd SurfaceNormal -> SurfaceNormals
b2947a1d7 Improve deprecation support of CellMeasures
5b7893a3f Support deprecated MeshQuality features
d22a509b5 Split CoordinateSystemTransform.h
c238cfea5 Improve deprecation support for moved or renamed headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2718
VTK-m has a deprecation method that supports API changes in minor
releases. When an API change is made, the old API is marked with the
VTKM_DEPRECATED macro. If code attempts to use the old API, it still
works, but the compiler issues a warning that the thing is deprecated
and where to find the new API.
We have recently run into an issue when the API changes have a header
file renamed or moved. We still keep the old header file with the old
API, so code including that file will still work. However, sometimes
code expected the contents of that header file without directly
including that header file. In these cases, the code could get an error
about missing classes.
As an example, consider the change from `DynamicCellSet` to
`UnknownCellSet`/`UncertainCellSet`. The deprecated `DynamicCellSet` is
still around. But there is a lot of code that did not directly include
DynamicCellSet.h. This header file was necessarily included by
DataSet.h. Now, when this code uses `vtkm::cont::DynamicCellSet`, you
get a confusing error that the class does not exist. Backward
compatibility broken.
In response to this, we should be more careful about where we put the
deprecated API. Instead of containing the deprecated API, moved headers
should be empty except for a warning and an inclusion of the new header
file. The deprecated API should be moved to the new header file. For
example, in the case of `DynamicCellSet`, the implementation for the
deprecated `DynamicCellSet` is moved to UnknownCellSet.h, which is
included by anything that was including DynamicCellSet.h before.
