Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-19 18:45:43 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
9e56a5d881
vtk-m/vtkm/filter/FilterDataSetWithField.h

141 lines
4.5 KiB
C
Raw Normal View History

First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//
// Copyright 2014 Sandia Corporation.
// Copyright 2014 UT-Battelle, LLC.
// Copyright 2014 Los Alamos National Security.
//
// Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation,
// the U.S. Government retains certain rights in this software.
//
// Under the terms of Contract DE-AC52-06NA25396 with Los Alamos National
// Laboratory (LANL), the U.S. Government retains certain rights in
// this software.
//============================================================================
#ifndef vtk_m_filter_DataSetWithFieldFilter_h
#define vtk_m_filter_DataSetWithFieldFilter_h
clang-format: sort include directives
2017-05-18 14:51:24 +00:00
#include <vtkm/cont/CoordinateSystem.h>
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
#include <vtkm/cont/DataSet.h>
#include <vtkm/cont/DynamicCellSet.h>
#include <vtkm/cont/Field.h>
Move RuntimeDeviceTracker to vtkm::cont 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).
2017-02-22 20:33:52 +00:00
#include <vtkm/cont/RuntimeDeviceTracker.h>
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
#include <vtkm/filter/PolicyBase.h>
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
#include <vtkm/filter/ResultDataSet.h>
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
namespace vtkm {
namespace filter {
template<class Derived>
Rename filter base classes to follow VTK-m naming convention 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.
2016-05-05 18:42:46 +00:00
class FilterDataSetWithField
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
{
public:
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Rename filter base classes to follow VTK-m naming convention 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.
2016-05-05 18:42:46 +00:00
FilterDataSetWithField();
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
Update classes using RuntimeDeviceTracker 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.
2017-02-23 16:54:41 +00:00
VTKM_CONT
~FilterDataSetWithField();
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
void SetActiveCellSet(vtkm::Id index)
{ this->CellSetIndex = index; }
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
vtkm::Id GetActiveCellSetIndex() const
{ return this->CellSetIndex; }
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
void SetActiveCoordinateSystem(vtkm::Id index)
{ this->CoordinateSystemIndex = index; }
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
vtkm::Id GetActiveCoordinateSystemIndex() const
{ return this->CoordinateSystemIndex; }
Update classes using RuntimeDeviceTracker 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.
2017-02-23 16:54:41 +00:00
VTKM_CONT
void SetRuntimeDeviceTracker(const vtkm::cont::RuntimeDeviceTracker &tracker)
{ this->Tracker = tracker; }
VTKM_CONT
const vtkm::cont::RuntimeDeviceTracker &GetRuntimeDeviceTracker() const
{ return this->Tracker; }
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input, const std::string &inFieldName);
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input, const vtkm::cont::Field &field);
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input, const vtkm::cont::CoordinateSystem &field);
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const std::string &inFieldName,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy );
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::Field &field,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy );
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet Execute(const vtkm::cont::DataSet &input,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::CoordinateSystem &field,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy );
//From the field we can extract the association component
// ASSOC_ANY -> unable to map
// ASSOC_WHOLE_MESH -> (I think this is points)
// ASSOC_POINTS -> map using point mapping
// ASSOC_CELL_SET -> how do we map this?
// ASSOC_LOGICAL_DIM -> unable to map?
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
bool MapFieldOntoOutput(ResultDataSet& result,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::Field& field);
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
bool MapFieldOntoOutput(ResultDataSet& result,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::Field& field,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy);
private:
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet PrepareForExecution(const vtkm::cont::DataSet& input,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::Field& field,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy);
//How do we specify float/double coordinate types?
template<typename DerivedPolicy>
Remove exports for header-only functions/methods 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.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Give result classes their own header file. 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.
2016-05-05 21:07:55 +00:00
ResultDataSet PrepareForExecution(const vtkm::cont::DataSet& input,
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
const vtkm::cont::CoordinateSystem& field,
const vtkm::filter::PolicyBase<DerivedPolicy>& policy);
std::string OutputFieldName;
vtkm::Id CellSetIndex;
vtkm::Id CoordinateSystemIndex;
Move RuntimeDeviceTracker to vtkm::cont 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).
2017-02-22 20:33:52 +00:00
vtkm::cont::RuntimeDeviceTracker Tracker;
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
};
}
} // namespace vtkm::filter
Rename filter base classes to follow VTK-m naming convention 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.
2016-05-05 18:42:46 +00:00
#include <vtkm/filter/FilterDataSetWithField.hxx>
First draft of vtkm::filter design.
2016-01-19 14:59:31 +00:00
Add missing new lines and #endif comments to vtkm::filter
2016-04-07 21:09:11 +00:00
#endif // vtk_m_filter_DataSetWithFieldFilter_h
Reference in New Issue Copy Permalink