The original design of the filter base class required several specialized
base classes to control what information was pulled from the input
`DataSet` and provided to the derived class. Since the filter base class was
redesigned, the derived classes all get a `DataSet` and pull their own
information from it. Thus, most specialized filter base classes became
unnecessary and removed.
The one substantial exception was the `FilterField`. This filter base class
managed input and output arrays. This was kept separate from the base
`Filter` because not all filters need the ability to select this
information.
That said, this separation has not been particularly helpful. There are
several other features of `Filter` that does not apply to all subclasses.
Furthermore, there are several derived filters that are using `FilterField`
merely to pick a single part, like selecting a coordinate system, and
ignoring the rest of the abilities.
Thus, it makes more sense to deprecate `FilterField` and have these classes
inherit directly from `Filter`.
The `FilterField` class provides convenience functions for subclasses to
determine the `ArrayHandle` type for scalar and vector fields. However, you
needed to know the specific size of vectors. For filters that support an
input field of any type, a new form, `CastAndCallVariableVecField` has been
added. This calls the underlying functor with an `ArrayHandleRecombineVec`
of the appropriate component type.
The `CastAndaCallVariableVecField` method also reduces the number of
instances created by having a float fallback for any component type that
does not satisfy the field types.
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`).
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 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 `MultiBlock` class has been renamed to `PartitionedDataSet`, and its API
has been refactored to refer to "partitions", rather than "blocks".
Additionally, the `AddBlocks` method has been changed to `AppendPartitions` to
more accurately reflect the operation performed. The associated
`AssignerMultiBlock` class has also been renamed to
`AssignerPartitionedDataSet`.
This change is motivated towards unifying VTK-m's data model with VTK. VTK has
started to move away from `vtkMultiBlockDataSet`, which is a hierarchical tree
of nested datasets, to `vtkPartitionedDataSet`, which is always a flat vector
of datasets used to assist geometry distribution in multi-process environments.
This simplifies traversal during processing and clarifies the intent of the
container: The component datasets are partitions for distribution, not
organizational groupings (e.g. materials).
Ref #405
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
This revamps Filter API to improve support for multiblock dataset and
distributed use-cases. Filters now operate on MultiBlock alone thus
`Filter::Execute(MultiBlock&)` is the primary method.
`Filter::Execute(DataSet*)` is only provided as an convenience that
internally puts the dataset into a MultiBlock and calls the primary
method.
Subclasses can provides PreExecute and PostExecute overrides to handle
init/reduction operations for filters with operating on multiple blocks.
Since blocks can be distributed, filters are expected to handle that as
well.
Subclasses can provide `PrepareForExecution(MultiBlock*..)` to customize
behavior for handling multiblock inputs. Default is to simply loop
over blocks.
This commit removes `vtkm::filter::Result`. All methods that used
`vtkm::filter::Result` simply change to use `vtkm::cont::Dataset` instead.
The utility API on `Result` that was used to add fields to the resulting
dataset is now available via `vtkm::filter::internal::CreateResult`.
MapFieldOntoOutput is no longer public API. Since `vtkm::cont::Filter`
invokes it when appropriate, we no longer need to keep it public.
Also removes the overload of MapFieldOntoOutput that doesn't take
policy. That is no longer needed since vtkm::cont::Filter always can
provide the current policy being used.
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.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
They now grab the global runtime device tracker. In some cases, I've
added the ability to set/get the tracker to change it from the global.
In others I just removed the local copy, since it was just hooked into
the global tracker.
Before it was in the vtkm::cont::internal namespace. However, we expect
to be using this feature quite a bit more as we want VTK-m to handle
multiple devices effectively (as in, just figure it out and go).
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
The TryExecute function was based off of the ResolveFieldTypeAnd*
classes made for filters. To reduce the amount of code duplication,
modify these two filter classes to use the more general TryExecute
functionality.
VTK-m style guidelines dictate that all classes part of the API should
be in their own header file. Thus, we have moved the result classes out
of the filter header files and into their own headers.
We have also renamed these clases to ResultField and ResultDataSet to
better match the class naming conventions of VTK-m.
Since we are moving around these result classes, we have also revamped
their structure. They are now in a hierarchy with a common ResultBase
class. Additionally, all result classes have a reference to a complete
DataSet that can be considered the output of the filter. This will make
it easier for users to consistently deal with filter results.
These changes cover issues #60 and #62.
The base classes for all the filters are named with 'Filter' at the end.
Generally the convention in VTK-m is to place the most general
descriptor (in this case Filter) first, which makes it easier to find
items in ordered lists.
This commit resolves issue #59.
