f8f41e0ef Update use of field association enumerations
56670dbba Rename field associations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2733
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.
The symbols in `vtkm::cont::Field::Association` have been changed from
`ANY`, `WHOLE_MESH`, `POINTS`, and `CELL_SET` to `Any`, `WholeMesh`,
`Points`, and `Cells`, respectively. The reason for this change is twofold:
* The general standard that VTK-m follows for `enum struct` enumerators
is to use camel case (with the first character capitalized), not all
upper case.
* The use of `CELL_SET` for fields associated with cells is obsolete. A
`DataSet` used to support having more than one `CellSet`, and so a
field association on cells was actually bound to a particular
`CellSet`. However, that is no longer the case. A `DataSet` has exactly
one `CellSet`, so a cell field no longer has to point to a `CellSet`.
Thus the enumeration symbol for `Cells` should match the one for
`Points`.
For backward compatibility, the old enumerations still exist. They are
aliases for the new names, and they are marked as deprecated, so using them
will result in a compiler warning (on some systems).
9d6f63b67 Add vtkm_cont_testing to interface of vtkm_cont
2723cd082 Include UncertainCellSet.h from UnknownCellSet.h
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2732
In the transition of the `Histogram` filter to the new filter types, a
bug was introduced. The `Histogram` filter has an option to set the
range for which to compute the histogram. (The range of the data will be
used instead if none is specified.) This range was properly used when
computing the histogram on a `PartitionedDataSet`. However, when running
on a single `DataSet`, the new filter structure skipped over the
partition code that checked to see if the range was specified. (It also
skipped over the code that properly computed the range in MPI.)
This change properly checks to see if `Execute` was called with a single
`DataSet` and updates the `ComputedRange` appropriately.
Recent changes to VTK-m include changes to MakeDataSet.h that require
the vtkm_cont_testing library to be loaded. This is problematic for
software using an earlier minor revision as they do not expect to need
to include this library.
For now, include vtkm_cont_testing in the interface of vtkm_cont so that
downstream code will load it. This should be a temporary solution. As we
move to new versions of VTK-m, we should break this link and require
downstream components to include it themselves.
This is mostly to support external code that expects deprecated
behavior. UnknownCellSet/UncertainCellSet replace DynamicCellSet. In the
deprecated class, you could use `ResetCellSetList` without having to
include a secondary file. It would be better to support that now so the
minor change does not break things.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
GCC 11 is having trouble compiling brigand.hpp at all, even before we
instantiate any templates. Since we no longer need it, let's get rid of
it. It was always placed in an internal namespace.
Add deprecation warnings to the code whenever someone uses brigand.hpp.
We are no longer supporting this header file, but we'll give code a
chance to transition off of it.
Also added some other deprecation warnings to other header files that
are themselves deprecated but only issued warnings if you used something
in it.
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.
