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.
The basic use of `FieldSelection` is to construct the class with a mode
(`None`, `Any`, `Select`, `Exclude`), and then specify particular fields
based off of this mode. This works fine for basic uses where the same code
that constructs a `FieldSelection` sets all the fields.
But what happens, for example, if you have code that takes an existing
`FieldSelection` and wants to exclude the field named `foo`? If the
`FieldSelection` mode happens to be anything other than `Exclude`, the code
would have to go through several hoops to construct a new `FieldSelection`
object with this modified selection.
To make this case easier, `FieldSelection` now has the ability to specify
the mode independently for each field. The `AddField` method now has an
optional mode argument the specifies whether the mode for that field should
be `Select` or `Exclude`.
In the example above, the code can simply add the `foo` field with the
`Exclude` mode. Regardless of whatever state the `FieldSelection` was in
before, it will now report the `foo` field as not selected.
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.
As a general C++ "rule of three," if one of a copy constructor, copy
assignment, or destructor is defined, all three should be defined. Some
compilers issue warnings if this rule of three is violated.
It is sometimes the case that we define a destructor simply because it
is only valid in the control environment. When doing so, add
implementations for copy constructor and assignment as well.
Having a custom assignment operator means that the compiler
isn't required to generate the implicit copy constructor.
This makes sure they are constructed.
Previously you passed a FieldSelection to Filter::Execute to specify
which fields to pass from input to output. There is no real reason for
this as other information about input and output fields are member
variables to Filter. This moves field selection as a member variable as
well. (This should also help confusion when updating old code to new to
prevent users from mistaking field passing with input fields.
Also added a few convenience constructors to FieldSelection so that you
can call Field::SetFieldsToPass() with just the string of what you want
to pass.
This allows you to turn off the selection of fields rather than turn
them on. It could be helpful, for example, if you were isosurfacing on a
single isovalue and didn't want to pass the field you are contouring on
(because it's all the same value).
This mode forces the selection to be empty. Although there is no
practical difference between having MODE_NONE and having MODE_SELECTED
with nothing selected (which is the default), this is a semantically
nicer way to say you don't want any fields.
Since we have changed the default behavior of Filter::Execute to be
MODE_ALL, this is a nice addition so that you can clearly specify you
don't want to pass any fields by adding
vtkm::filter::FieldSelection::MODE_NONE as the second argument. (Making
it MODE_SELECTED is not clear that you want none.)
Filters now support executing on a dataset to produce a result dataset
with automatic mapping of fields to the output dataset. Fields to map
can be selected using `vtkm::filter::FieldSelection` class, which provides
constructors to map all or no fields, along with a selection of fields.
This updates all tests to use the new filter API.
