These new features to VTK-m lists allow you to compute a single value
from a list. `ListReduce` allows you to compute a value based on a
predicate. `ListAll` and `ListAny` use this feature to determine if all
or any of a list of `true_type` or `false_type` objects are true.
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
0ba7a222b point_to_cell wanning resolution
dea63919d point_to_cell wanning resolution
5bb7773cc Point_to_cell warning resolution
0ce7d9258 tutorial example fixes to resolve warnings
8e57362a2 tutorial example fixes to resolve warnings
5fc268d31 switched back to the old version of extract_edges
0300973df switched back to the old version of extract_edges
f5e827ad1 Enable building tutorials on all CI builds
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2653
Moved deprecated class to new headers (so that indirect includes still
work).
Changed vtkm::filter::mesh_info::IntegrationType to a scoped enum (which
we favor in VTK-m).
Correct the implementation of the deprecated integration types (which
would not have actually compiled anyway).
Reenable the `vtkm::filter::CellMetric` class and
`vtkm::filter::MetricNames` static variable for backward compatibility.
(Both are of course marked deprecated.)
Also, adjust names in the new `vtkm::filter::mesh_info::CellMetric` to
conform with the rest of VTK-m style for scoped enums.
This header file contained two filters: `CylindricalCoordinateTransform`
and `SphericalCoordinateTransform`. By convention, each header (and
source) file should contain one filter. Now that filters are split into
separate libraries, there is little reason to combine things into header
files.
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.
If you have a really long list, compilers might error out if you have a
recursive operation on it. Such an error can be confusing, so for now
create an error if the list is too long.
