diff --git a/vtkm/filter/CMakeLists.txt b/vtkm/filter/CMakeLists.txt index 3c8154ec6..9eee185a4 100644 --- a/vtkm/filter/CMakeLists.txt +++ b/vtkm/filter/CMakeLists.txt @@ -313,7 +313,7 @@ install(TARGETS vtkm_filter EXPORT ${VTKm_EXPORT_NAME}) add_subdirectory(internal) add_subdirectory(particleadvection) -add_subdirectory(FieldTransform) +add_subdirectory(field_transform) #-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - if (VTKm_ENABLE_TESTING) diff --git a/vtkm/filter/NewFilter.cxx b/vtkm/filter/NewFilter.cxx index c4d2c428c..659e65599 100644 --- a/vtkm/filter/NewFilter.cxx +++ b/vtkm/filter/NewFilter.cxx @@ -12,7 +12,6 @@ #include #include -#include #include #include @@ -38,6 +37,13 @@ void RunFilter(NewFilter* self, } } // anonymous namespace +NewFilter::~NewFilter() = default; + +bool NewFilter::CanThread() const +{ + return true; +} + //---------------------------------------------------------------------------- vtkm::cont::PartitionedDataSet NewFilter::DoExecute(const vtkm::cont::PartitionedDataSet& input) { @@ -76,6 +82,10 @@ vtkm::cont::PartitionedDataSet NewFilter::DoExecute(const vtkm::cont::Partitione return output; } +vtkm::cont::DataSet NewFilter::Execute(const vtkm::cont::DataSet& input) +{ + return this->DoExecute(input); +} vtkm::cont::PartitionedDataSet NewFilter::Execute(const vtkm::cont::PartitionedDataSet& input) { @@ -84,13 +94,10 @@ vtkm::cont::PartitionedDataSet NewFilter::Execute(const vtkm::cont::PartitionedD (int)input.GetNumberOfPartitions(), vtkm::cont::TypeToString().c_str()); - // Call `void Derived::PreExecute(input, policy)`, if defined. this->PreExecute(input); - // Call `PrepareForExecution` (which should probably be renamed at some point) vtkm::cont::PartitionedDataSet output = this->DoExecute(input); - // Call `Derived::PostExecute(input, output, policy)` if defined. this->PostExecute(input, output); return output; diff --git a/vtkm/filter/NewFilter.h b/vtkm/filter/NewFilter.h index fe52fd9bc..fdbc009d9 100644 --- a/vtkm/filter/NewFilter.h +++ b/vtkm/filter/NewFilter.h @@ -10,19 +10,13 @@ #ifndef vtk_m_filter_NewFilter_h #define vtk_m_filter_NewFilter_h -#include #include -#include #include #include #include #include -#include #include -#include -#include -#include #include namespace vtkm @@ -33,7 +27,7 @@ namespace filter /// /// This is the base class for all filters. To add a new filter, one can /// subclass this (or any of the existing subclasses e.g. FilterField, -/// FilterDataSet, FilterDataSetWithField, etc. and implement relevant methods. +/// FilterParticleAdvection, etc.) and implement relevant methods. /// /// \section FilterUsage Usage /// @@ -63,53 +57,56 @@ namespace filter /// type, thus `Execute(DataSet&)` returns a DataSet while /// `Execute(PartitionedDataSet&)` returns a PartitionedDataSet. /// -/// The implementation for `Execute(DataSet&)` is merely provided for -/// convenience. Internally, it creates a PartitionedDataSet with a single -/// partition for the input and then forwards the call to -/// `Execute(PartitionedDataSet&)`. The method returns the first partition, if -/// any, from the PartitionedDataSet returned by the forwarded call. If the -/// PartitionedDataSet returned has more than 1 partition, then -/// `vtkm::cont::ErrorFilterExecution` will be thrown. +/// The pure virtual function `Execute(DataSet&)` is the main extension point of the +/// Filter interface. Filter developer needs to override `Execute(DataSet)` to implement +/// the business logic of filtering operations on a single DataSet. +/// +/// The default implementation of `Execute(PartitionedDataSet&)` is merely provided for +/// convenience. Internally, it iterates DataSets of a PartitionedDataSet and pass +/// each individual DataSets to `Execute(DataSet&)`, possibly in a multi-threaded setting. +/// Developer of `Execute(DataSet&)` needs to indicate the thread-safeness of `Execute(DataSet&)` +/// by overriding the `CanThread()` virtual method which by default returns `true`. +/// +/// In the case that filtering on a PartitionedDataSet can not be simply implemented as a +/// for-each loop on the component DataSets, filter implementor needs to override the +/// `Execute(PartitionedDataSet&)`. See the implementation of +/// `FilterParticleAdvection::Execute(PartitionedDataSet&)` for an example. /// /// \section FilterSubclassing Subclassing /// /// Typically, one subclasses one of the immediate subclasses of this class such as -/// FilterField, FilterDataSet, FilterDataSetWithField, etc. Those may impose +/// FilterField, FilterParticleAdvection, etc. Those may impose /// additional constraints on the methods to implement in the subclasses. /// Here, we describes the things to consider when directly subclassing /// vtkm::filter::Filter. /// /// \subsection FilterPreExecutePostExecute PreExecute and PostExecute /// -/// Subclasses may provide implementations for either or both of the following +/// Subclasses may provide implementations for either or both of the following protected /// methods. /// /// \code{cpp} /// -/// template -/// void PreExecute(const vtkm::cont::PartitionedDataSet& input, -/// const vtkm::filter::PolicyBase& policy); +/// void PreExecute(const vtkm::cont::PartitionedDataSet& input); /// -/// template -/// void PostExecute(const vtkm::cont::PartitionedDataSet& input, vtkm::cont::PartitionedDataSet& output -/// const vtkm::filter::PolicyBase& policy); +/// void PostExecute(const vtkm::cont::PartitionedDataSet& input, +/// vtkm::cont::PartitionedDataSet& output); /// /// \endcode /// -/// As the name suggests, these are called and the beginning and before the end -/// of an `Filter::Execute` call. Most filters that don't need to handle +/// As the name suggests, these are called and the before the beginning and after the end of +/// iterative `Filter::Execute(DataSet&)` calls. Most filters that don't need to handle /// PartitionedDataSet specially, e.g. clip, cut, iso-contour, need not worry /// about these methods or provide any implementation. If, however, your filter -/// needs do to some initialization e.g. allocation buffers to accumulate +/// needs to do some initialization e.g. allocation buffers to accumulate /// results, or finalization e.g. reduce results across all partitions, then /// these methods provide convenient hooks for the same. /// -/// \subsection FilterPrepareForExecution PrepareForExecution +/// \subsection FilterExecution Execute /// -/// A concrete subclass of Filter must provide `PrepareForExecution` -/// implementation that provides the meat for the filter i.e. the implementation -/// for the filter's data processing logic. There are two signatures -/// available; which one to implement depends on the nature of the filter. +/// A concrete subclass of Filter must provide `Execute` implementation that provides the meat +/// for the filter i.e. the implementation for the filter's data processing logic. There are +/// two signatures available; which one to implement depends on the nature of the filter. /// /// Let's consider simple filters that do not need to do anything special to /// handle PartitionedDataSet e.g. clip, contour, etc. These are the filters @@ -120,10 +117,7 @@ namespace filter /// /// \code{cpp} /// -/// template -/// vtkm::cont::DataSet PrepareForExecution( -/// const vtkm::cont::DataSet& input, -/// const vtkm::filter::PolicyBase& policy); +/// vtkm::cont::DataSet Execution(const vtkm::cont::DataSet& input); /// /// \endcode /// @@ -131,9 +125,9 @@ namespace filter /// result and return it. If there are any errors, the subclass must throw an /// exception (e.g. `vtkm::cont::ErrorFilterExecution`). /// -/// In this case, the Filter superclass handles iterating over multiple +/// In this simple case, the Filter superclass handles iterating over multiple /// partitions in the input PartitionedDataSet and calling -/// `PrepareForExecution` iteratively. +/// `Execute(DataSet&)` iteratively. /// /// The aforementioned approach is also suitable for filters that need special /// handling for PartitionedDataSets which can be modelled as PreExecute and @@ -144,42 +138,136 @@ namespace filter /// results, one can implement the following signature. /// /// \code{cpp} -/// template -/// vtkm::cont::PartitionedDataSet PrepareForExecution( -/// const vtkm::cont::PartitionedDataSet& input, -/// const vtkm::filter::PolicyBase& policy); +/// vtkm::cont::PartitionedDataSet Execute( +/// const vtkm::cont::PartitionedDataSet& input); /// \endcode /// /// The responsibility of this method is the same, except now the subclass is /// given full control over the execution, including any mapping of fields to /// output (described in next sub-section). /// -/// \subsection FilterMapFieldOntoOutput DoMapField +/// \subsection FilterMappingFields MapFieldsOntoOutput /// -/// Subclasses may provide `DoMapField` method with the following -/// signature: +/// For subclasses that map input fields into output fields, the implementation of its +/// `Execute(DataSet&)` should call `Filter::MapFieldsOntoOutput` with a properly defined +/// `Mapper`, before returning the output DataSet. For example: /// /// \code{cpp} +/// VTKM_CONT DataSet SomeFilter::Execute(const vtkm::cont::DataSet& input) +/// { +/// vtkm::cont::DataSet output; +/// output = ... // Generation of the new DataSet /// -/// template -/// VTKM_CONT bool DoMapField(vtkm::cont::DataSet& result, -/// const vtkm::cont::Field& field, -/// const vtkm::filter::PolicyBase& policy); +/// // Mapper is a callable object (function object, lambda, etc.) that takes an input Field +/// // and maps it to an output Field and then add the output Field to the output DataSet +/// auto mapper = [](auto& outputDs, const auto& inputField) { +/// auto outputField = ... // Business logic for mapping input field to output field +/// output.AddField(outputField); +/// }; +/// MapFieldsOntoOutput(input, output, mapper); /// +/// return output; +/// } /// \endcode /// -/// When present, this method will be called after each partition execution to -/// map an input field from the corresponding input partition to the output -/// partition. +/// `MapFieldsOntoOutput` iterates through each `FieldToPass` in the input DataSet and calls the +/// Mapper to map the input Field to output Field. For simple filters that just pass on input +/// fields to the output DataSet without any computation, an overload of +/// `MapFieldsOntoOutput(const vtkm::cont::DataSet& input, vtkm::cont::DataSet& output)` is also +/// provided as a convenience that uses the default mapper which trivially add input Field to +/// output DaaSet (via a shallow copy). /// +/// \subsection FilterThreadSafety CanThread +/// +/// By default, the implementation of `Execute(DataSet&)` should model a *pure function*, i.e. it +/// does not have any mutable shared state. This makes it thread-safe by default and allows +/// the default implementation of `Execute(PartitionedDataSet&)` to be simply a parallel for-each, +/// thus facilitates multi-threaded execution without any lock. +/// +/// Many legacy (VTKm 1.x) filter implementations needed to store states between the mesh generation +/// phase and field mapping phase of filter execution, for example, parameters for field +/// interpolation. The shared mutable states were mostly stored as mutable data members of the +/// filter class (either in terms of ArrayHandle or some kind of Worket). The new filter interface, +/// by combining the two phases into a single call to `Execute(DataSet&)`, we have eliminated most +/// of the cases that require such shared mutable states. New implementations of filters that +/// require passing information between these two phases can now use local variables within the +/// `Execute(DataSet&)`. For example: +/// +/// \code{cpp} +/// struct SharedState; // shared states between mesh generation and field mapping. +/// VTKM_CONT DataSet ThreadSafeFilter::Execute(const vtkm::cont::DataSet& input) +/// { +/// // Mutable states that was a data member of the filter is now a local variable. +/// // Each invocation of Execute(DataSet) in the multi-threaded execution of +/// // Execute(PartitionedDataSet&) will have a copy of `states` on each thread's stack +/// // thus making it thread-safe. +/// SharedStates states; +/// +/// vtkm::cont::DataSet output; +/// output = ... // Generation of the new DataSet and store interpolation parameters in `states` +/// +/// // Lambda capture of `states`, effectively passing the shared states to the Mapper. +/// auto mapper = [&states](auto& outputDs, const auto& inputField) { +/// auto outputField = ... // Use `states` for mapping input field to output field +/// output.AddField(outputField); +/// }; +/// MapFieldsOntoOutput(input, output, mapper); +/// +/// return output; +/// } +/// \endcode +/// +/// In the rare cases that filter implementation can not be made thread-safe, the implementation +/// needs to override the `CanThread()` virtual method to return `false`. The default +/// `Execute(PartitionedDataSet&)` implementation will fallback to a serial for loop execution. +/// +/// \subsection FilterThreadScheduling DoExecute +/// The default multi-threaded execution of `Execute(PartitionedDataSet&)` uses a simple FIFO queue +/// of DataSet and pool of *worker* threads. Implementation of Filter subclass can override the +/// `DoExecute(PartitionedDataSet)` virtual method to provide implementation specific scheduling +/// policy. The default number of *worker* threads in the pool are determined by the +/// `DetermineNumberOfThreads()` virtual method using several backend dependent heuristic. +/// Implementations of Filter subclass can also override +/// `DetermineNumberOfThreads()` to provide implementation specific heuristic. +/// +/// \subsection FilterNameLookup Overriding Overloaded Functions +/// Since we have two overloads of `Execute`, we need to work with C++'s rule for name lookup for +/// inherited, overloaded functions when overriding them. In most uses cases, we intend to only +/// override the `Execute(DataSet&)` overload in an implementation of a NewFilter subclass, such as +/// +/// \code{cpp} +/// class FooFilter : public NewFilter +/// { +/// ... +/// vtkm::cont::DataSet Execute(const vtkm::cont::DataSet& input) override; +/// ... +/// } +/// \endcode +/// +/// However, the compiler will stop the name lookup process once it sees the +/// `FooFilter::Execute(DataSet)`. When a user calls `FooFilter::Execute(PartitionedDataSet&)`, +/// the compiler will not find the overload from the base class `NewFilter`, resulting in failed +/// overload resolution. The solution to such a problem is to use a using-declaration in the +/// subclass definition to bring the `NewFilter::Execute(PartitionedDataSet&)` into scope for +/// name lookup. For example: +/// +/// \code{cpp} +/// class FooFilter : public NewFilter +/// { +/// ... +/// using vtkm::filter::NewFilter::Execute; // bring overloads of Execute into name lookup +/// vtkm::cont::DataSet Execute(const vtkm::cont::DataSet& input) override; +/// ... +/// } +/// \endcode class VTKM_FILTER_CORE_EXPORT NewFilter { public: VTKM_CONT - virtual ~NewFilter() = default; + virtual ~NewFilter(); VTKM_CONT - virtual bool CanThread() const { return true; } + virtual bool CanThread() const; VTKM_CONT bool GetRunMultiThreadedFilter() const @@ -205,36 +293,6 @@ public: /// A filter is able to state what subset of types it supports. using SupportedTypes = VTKM_DEFAULT_TYPE_LIST; - /// \brief Specify which additional field storage to support. - /// - /// When a filter gets a field value from a DataSet, it has to determine what type - /// of storage the array has. Typically this is taken from the default storage - /// types defined in DefaultTypes.h. In some cases it is useful to support additional - /// types. For example, the filter might make sense to support ArrayHandleIndex or - /// ArrayHandleConstant. If so, the storage of those additional types should be - /// listed here. - using AdditionalFieldStorage = vtkm::ListEmpty; - - /// \brief Specify which structured cell sets to support. - /// - /// When a filter gets a cell set from a DataSet, it has to determine what type - /// of concrete cell set it is. This provides a list of supported structured - /// cell sets. - using SupportedStructuredCellSets = VTKM_DEFAULT_CELL_SET_LIST_STRUCTURED; - - /// \brief Specify which unstructured cell sets to support. - /// - /// When a filter gets a cell set from a DataSet, it has to determine what type - /// of concrete cell set it is. This provides a list of supported unstructured - /// cell sets. - using SupportedUnstructuredCellSets = VTKM_DEFAULT_CELL_SET_LIST_UNSTRUCTURED; - - /// \brief Specify which unstructured cell sets to support. - /// - /// When a filter gets a cell set from a DataSet, it has to determine what type - /// of concrete cell set it is. This provides a list of supported cell sets. - using SupportedCellSets = VTKM_DEFAULT_CELL_SET_LIST; - //@{ /// \brief Specify which fields get passed from input to output. /// @@ -289,15 +347,14 @@ public: /// Executes the filter on the input and produces a result dataset. /// /// On success, this the dataset produced. On error, vtkm::cont::ErrorExecution will be thrown. - VTKM_CONT virtual vtkm::cont::DataSet Execute(const vtkm::cont::DataSet& input) = 0; + VTKM_CONT vtkm::cont::DataSet Execute(const vtkm::cont::DataSet& input); //@} //@{ /// Executes the filter on the input PartitionedDataSet and produces a result PartitionedDataSet. /// /// On success, this the dataset produced. On error, vtkm::cont::ErrorExecution will be thrown. - VTKM_CONT virtual vtkm::cont::PartitionedDataSet Execute( - const vtkm::cont::PartitionedDataSet& input); + VTKM_CONT vtkm::cont::PartitionedDataSet Execute(const vtkm::cont::PartitionedDataSet& input); //@} // FIXME: Is this actually materialize? Are there different kinds of Invoker? @@ -306,40 +363,15 @@ public: /// which device adapters a filter uses. void SetInvoker(vtkm::cont::Invoker inv) { this->Invoke = inv; } - // TODO: de-virtual, move to protected. - VTKM_CONT - virtual vtkm::Id DetermineNumberOfThreads(const vtkm::cont::PartitionedDataSet& input); - protected: vtkm::cont::Invoker Invoke; vtkm::Id CoordinateSystemIndex = 0; - //@{ - /// when operating on vtkm::cont::PartitionedDataSet, we - /// want to do processing across ranks as well. Just adding pre/post handles - /// for the same does the trick. - VTKM_CONT virtual void PreExecute(const vtkm::cont::PartitionedDataSet&) {} - - VTKM_CONT virtual void PostExecute(const vtkm::cont::PartitionedDataSet&, - vtkm::cont::PartitionedDataSet&) - { - } - //@} - - VTKM_CONT virtual vtkm::cont::PartitionedDataSet DoExecute( - const vtkm::cont::PartitionedDataSet& inData); - - static void defaultMapper(vtkm::cont::DataSet& output, const vtkm::cont::Field& field) - { - output.AddField(field); - }; - template VTKM_CONT void MapFieldsOntoOutput(const vtkm::cont::DataSet& input, vtkm::cont::DataSet& output, Mapper&& mapper) { - // TODO: in the future of C++20, we can make it a "filtered_view". for (vtkm::IdComponent cc = 0; cc < input.GetNumberOfFields(); ++cc) { auto field = input.GetField(cc); @@ -356,6 +388,30 @@ protected: } private: + VTKM_CONT + virtual vtkm::Id DetermineNumberOfThreads(const vtkm::cont::PartitionedDataSet& input); + + //@{ + /// when operating on vtkm::cont::PartitionedDataSet, we + /// want to do processing across ranks as well. Just adding pre/post handles + /// for the same does the trick. + VTKM_CONT virtual void PreExecute(const vtkm::cont::PartitionedDataSet&) {} + + VTKM_CONT virtual void PostExecute(const vtkm::cont::PartitionedDataSet&, + vtkm::cont::PartitionedDataSet&) + { + } + //@} + + VTKM_CONT virtual vtkm::cont::DataSet DoExecute(const vtkm::cont::DataSet& inData) = 0; + VTKM_CONT virtual vtkm::cont::PartitionedDataSet DoExecute( + const vtkm::cont::PartitionedDataSet& inData); + + static void defaultMapper(vtkm::cont::DataSet& output, const vtkm::cont::Field& field) + { + output.AddField(field); + }; + vtkm::filter::FieldSelection FieldsToPass = vtkm::filter::FieldSelection::MODE_ALL; bool RunFilterWithMultipleThreads = false; }; diff --git a/vtkm/filter/FieldTransform/CMakeLists.txt b/vtkm/filter/field_transform/CMakeLists.txt similarity index 67% rename from vtkm/filter/FieldTransform/CMakeLists.txt rename to vtkm/filter/field_transform/CMakeLists.txt index c6ddf467c..f9eec9bbc 100644 --- a/vtkm/filter/FieldTransform/CMakeLists.txt +++ b/vtkm/filter/field_transform/CMakeLists.txt @@ -7,25 +7,20 @@ ## the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR ## PURPOSE. See the above copyright notice for more information. ##============================================================================ -set(fieldtransform_headers +set(fieldt_ransform_headers GenerateIds.h) -set(fieldtransform_sources_device +set(field_transform_sources_device GenerateIds.cxx) vtkm_library( - NAME vtkm_filter_fieldtransform - HEADERS ${fieldtransform_headers} - DEVICE_SOURCES ${fieldtransform_sources_device} + NAME vtkm_filter_field_transform + HEADERS ${field_transform_headers} + DEVICE_SOURCES ${field_transform_sources_device} USE_VTKM_JOB_POOL ) -set_property(TARGET - vtkm_filter_fieldtransform - PROPERTY UNITY_BUILD_MODE GROUP - ) - -target_link_libraries(vtkm_filter_fieldtransform PUBLIC vtkm_worklet vtkm_filter_core) -target_link_libraries(vtkm_filter PUBLIC INTERFACE vtkm_filter_fieldtransform) +target_link_libraries(vtkm_filter_field_transform PUBLIC vtkm_worklet vtkm_filter_core) +target_link_libraries(vtkm_filter PUBLIC INTERFACE vtkm_filter_field_transform) #-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - if (VTKm_ENABLE_TESTING) diff --git a/vtkm/filter/FieldTransform/GenerateIds.cxx b/vtkm/filter/field_transform/GenerateIds.cxx similarity index 83% rename from vtkm/filter/FieldTransform/GenerateIds.cxx rename to vtkm/filter/field_transform/GenerateIds.cxx index b9fe9b0e3..f1296f14d 100644 --- a/vtkm/filter/FieldTransform/GenerateIds.cxx +++ b/vtkm/filter/field_transform/GenerateIds.cxx @@ -9,12 +9,13 @@ //============================================================================ #include #include -#include +#include namespace { -vtkm::cont::UnknownArrayHandle GenerateArray(const vtkm::filter::GenerateIds& self, vtkm::Id size) +vtkm::cont::UnknownArrayHandle GenerateArray(const vtkm::filter::field_transform::GenerateIds& self, + vtkm::Id size) { vtkm::cont::ArrayHandleIndex indexArray(size); @@ -38,8 +39,9 @@ namespace vtkm { namespace filter { - -vtkm::cont::DataSet GenerateIds::Execute(const vtkm::cont::DataSet& input) +namespace field_transform +{ +vtkm::cont::DataSet GenerateIds::DoExecute(const vtkm::cont::DataSet& input) { vtkm::cont::DataSet output = input; @@ -58,6 +60,6 @@ vtkm::cont::DataSet GenerateIds::Execute(const vtkm::cont::DataSet& input) return output; } - +} // namespace field_transform } // namespace vtkm::filter } // namespace vtkm diff --git a/vtkm/filter/FieldTransform/GenerateIds.h b/vtkm/filter/field_transform/GenerateIds.h similarity index 91% rename from vtkm/filter/FieldTransform/GenerateIds.h rename to vtkm/filter/field_transform/GenerateIds.h index 8b03b49c1..284d450cd 100644 --- a/vtkm/filter/FieldTransform/GenerateIds.h +++ b/vtkm/filter/field_transform/GenerateIds.h @@ -10,14 +10,15 @@ #ifndef vtk_m_filter_GenerateIds_h #define vtk_m_filter_GenerateIds_h -#include #include +#include namespace vtkm { namespace filter { - +namespace field_transform +{ /// \brief Adds fields to a `DataSet` that give the ids for the points and cells. /// /// This filter will add (by default) a point field named `pointids` that gives the @@ -27,7 +28,7 @@ namespace filter /// convenient for adding indices to operations designed for fields and generally /// creating test data. /// -class VTKM_FILTER_FIELDTRANSFORM_EXPORT GenerateIds : public vtkm::filter::NewFilter +class VTKM_FILTER_FIELD_TRANSFORM_EXPORT GenerateIds : public vtkm::filter::NewFilter { std::string PointFieldName = "pointids"; std::string CellFieldName = "cellids"; @@ -84,9 +85,9 @@ public: bool GetUseFloat() const { return this->UseFloat; } void SetUseFloat(bool flag) { this->UseFloat = flag; } - vtkm::cont::DataSet Execute(const vtkm::cont::DataSet& input) override; + vtkm::cont::DataSet DoExecute(const vtkm::cont::DataSet& input) override; }; - +} // namespace field_transform } // namespace vtkm::filter } // namespace vtkm diff --git a/vtkm/filter/FieldTransform/testing/CMakeLists.txt b/vtkm/filter/field_transform/testing/CMakeLists.txt similarity index 95% rename from vtkm/filter/FieldTransform/testing/CMakeLists.txt rename to vtkm/filter/field_transform/testing/CMakeLists.txt index fd25171c6..8b1d72d89 100644 --- a/vtkm/filter/FieldTransform/testing/CMakeLists.txt +++ b/vtkm/filter/field_transform/testing/CMakeLists.txt @@ -12,7 +12,7 @@ set(unit_tests UnitTestGenerateIds.cxx) set(libraries - vtkm_filter_fieldtransform + vtkm_filter_field_transform vtkm_source) vtkm_unit_tests( diff --git a/vtkm/filter/FieldTransform/testing/UnitTestGenerateIds.cxx b/vtkm/filter/field_transform/testing/UnitTestGenerateIds.cxx similarity index 92% rename from vtkm/filter/FieldTransform/testing/UnitTestGenerateIds.cxx rename to vtkm/filter/field_transform/testing/UnitTestGenerateIds.cxx index 91f05fe07..312dad2df 100644 --- a/vtkm/filter/FieldTransform/testing/UnitTestGenerateIds.cxx +++ b/vtkm/filter/field_transform/testing/UnitTestGenerateIds.cxx @@ -9,7 +9,7 @@ //============================================================================ #include #include -#include +#include #include namespace @@ -34,8 +34,9 @@ void CheckField(const vtkm::cont::UnknownArrayHandle& array, vtkm::Id expectedSi } } -void TryGenerateIds(vtkm::filter::GenerateIds& filter, // Why is Filter::Execute not const? - const vtkm::cont::DataSet& input) +void TryGenerateIds( + vtkm::filter::field_transform::GenerateIds& filter, // Why is Filter::Execute not const? + const vtkm::cont::DataSet& input) { vtkm::cont::DataSet output = filter.Execute(input); VTKM_TEST_ASSERT(output.GetNumberOfPoints() == input.GetNumberOfPoints()); @@ -77,7 +78,7 @@ void TryGenerateIds(vtkm::filter::GenerateIds& filter, // Why is Filter::Execute void TestGenerateIds() { vtkm::cont::DataSet input = vtkm::source::Tangle{ vtkm::Id3(8) }.Execute(); - vtkm::filter::GenerateIds filter; + vtkm::filter::field_transform::GenerateIds filter; TryGenerateIds(filter, input); diff --git a/vtkm/filter/testing/UnitTestContourFilter.cxx b/vtkm/filter/testing/UnitTestContourFilter.cxx index 7356dfbe3..f39ef5eee 100644 --- a/vtkm/filter/testing/UnitTestContourFilter.cxx +++ b/vtkm/filter/testing/UnitTestContourFilter.cxx @@ -15,7 +15,7 @@ #include #include -#include +#include #include #include @@ -32,7 +32,7 @@ public: vtkm::Id3 dims(4, 4, 4); vtkm::source::Tangle tangle(dims); - vtkm::filter::GenerateIds genIds; + vtkm::filter::field_transform::GenerateIds genIds; genIds.SetUseFloat(true); genIds.SetGeneratePointIds(false); genIds.SetCellFieldName("cellvar"); diff --git a/vtkm/worklet/testing/UnitTestContour.cxx b/vtkm/worklet/testing/UnitTestContour.cxx index 087d2adf2..5d2906fe6 100644 --- a/vtkm/worklet/testing/UnitTestContour.cxx +++ b/vtkm/worklet/testing/UnitTestContour.cxx @@ -16,7 +16,7 @@ #include #include -#include +#include #include #include @@ -186,7 +186,7 @@ void TestContourUniformGrid() vtkm::Id3 dims(4, 4, 4); vtkm::source::Tangle tangle(dims); - vtkm::filter::GenerateIds genIds; + vtkm::filter::field_transform::GenerateIds genIds; genIds.SetUseFloat(true); genIds.SetGeneratePointIds(false); genIds.SetCellFieldName("cellvar"); @@ -365,7 +365,7 @@ void TestContourClipped() vtkm::Id3 dims(4, 4, 4); vtkm::source::Tangle tangle(dims); - vtkm::filter::GenerateIds genIds; + vtkm::filter::field_transform::GenerateIds genIds; genIds.SetUseFloat(true); genIds.SetGeneratePointIds(false); genIds.SetCellFieldName("cellvar");