Shuenhoy/vtk-m2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
5cd47a7065
vtk-m2/vtkm/cont/CellSetExplicit.h

417 lines
16 KiB
C
Raw Normal View History

Correct headers to have the new copyright.
2015-06-03 19:06:43 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
conslidate the license statement
2019-04-15 23:24:21 +00:00
//
Correct headers to have the new copyright.
2015-06-03 19:06:43 +00:00
// 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.
//============================================================================
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#ifndef vtk_m_cont_CellSetExplicit_h
#define vtk_m_cont_CellSetExplicit_h
Rename CellType to CellShape. We have been using the term "shape" in the cell set and connectivity classes. To be consistent, use the term "shape" for the geometric identify of the cell everywhere.
2015-08-16 18:53:44 +00:00
#include <vtkm/CellShape.h>
clang-format: sort include directives
2017-05-18 14:51:24 +00:00
#include <vtkm/TopologyElementTag.h>
Fix CellSetExplicit CellToPoint The computation of CellToPoint was not correctly handling the case where some points are not part of any cell.
2017-07-21 16:15:54 +00:00
#include <vtkm/cont/ArrayHandleConstant.h>
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
#include <vtkm/cont/ArrayHandleCounting.h>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#include <vtkm/cont/CellSet.h>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
#include <vtkm/cont/internal/ConnectivityExplicitInternals.h>
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
#include <vtkm/exec/ConnectivityExplicit.h>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
#include <vtkm/cont/vtkm_cont_export.h>
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace vtkm
{
namespace cont
{
adding initial cell set structures
2015-04-15 16:43:12 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace detail
{
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename CellSetType, typename VisitTopology, typename IncidentTopology>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
struct CellSetExplicitConnectivityChooser
{
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ConnectivityType = vtkm::cont::internal::ConnectivityExplicitInternals<>;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
};
} // namespace detail
CellSetExplicit storage tags are now easier to override.
2015-09-23 17:52:58 +00:00
#ifndef VTKM_DEFAULT_SHAPE_STORAGE_TAG
#define VTKM_DEFAULT_SHAPE_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
#ifndef VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG
#define VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
#ifndef VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG
#define VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
#ifndef VTKM_DEFAULT_OFFSETS_STORAGE_TAG
#define VTKM_DEFAULT_OFFSETS_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ShapeStorageTag = VTKM_DEFAULT_SHAPE_STORAGE_TAG,
typename NumIndicesStorageTag = VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG,
typename ConnectivityStorageTag = VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG,
typename OffsetsStorageTag = VTKM_DEFAULT_OFFSETS_STORAGE_TAG>
Fix CellSet* typeid to consistent across dynamic libraries. Since we don't have explicit template instantiations for CellSetExplicit and CellSetSingleType we need to mark them as being exported from all libraries.
2017-03-01 22:11:23 +00:00
class VTKM_ALWAYS_EXPORT CellSetExplicit : public CellSet
adding initial cell set structures
2015-04-15 16:43:12 +00:00
{
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using Thisclass = CellSetExplicit<ShapeStorageTag,
NumIndicesStorageTag,
ConnectivityStorageTag,
OffsetsStorageTag>;
Add default constructors/destructors/assignment to CellSet classes The CellSet classes all exclusively work in the control environment. However, CUDA likes to add __device__ to constructors, destructors, and assignment operators it automatically adds. This in turn causes warnings about the __device__ function using host-only classes (like boost::shared_ptr). Solve this problem by adding explicit methods for all of these.
2015-10-21 22:27:09 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
struct ConnectivityChooser
{
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ConnectivityType =
typename detail::CellSetExplicitConnectivityChooser<Thisclass,
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VisitTopology,
IncidentTopology>::ConnectivityType;
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ShapeArrayType = typename ConnectivityType::ShapeArrayType;
using NumIndicesArrayType = typename ConnectivityType::NumIndicesArrayType;
using ConnectivityArrayType = typename ConnectivityType::ConnectivityArrayType;
using IndexOffsetArrayType = typename ConnectivityType::IndexOffsetArrayType;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
};
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
using VisitCellsWithPointsInternalsType =
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
typename ConnectivityChooser<vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint>::ConnectivityType;
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
using VisitPointsWithCellsInternalsType =
typename ConnectivityChooser<vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>::ConnectivityType;
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
public:
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using SchedulingRangeType = vtkm::Id;
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
Add CellSetPermutation which allows custom iteration over a cell set. When you create a CellSetPermutation you provide an array of the cell ids that you want to iterate. This allows the user to do custom blanking of a data set, or to do multi iteration over a set of cells.
2015-09-28 17:15:26 +00:00
//point to cell is used when iterating cells and asking for point properties
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
using VisitCellsWithPointsConnectivityType =
ConnectivityChooser<vtkm::TopologyElementTagCell, vtkm::TopologyElementTagPoint>;
Add default constructors/destructors/assignment to CellSet classes The CellSet classes all exclusively work in the control environment. However, CUDA likes to add __device__ to constructors, destructors, and assignment operators it automatically adds. This in turn causes warnings about the __device__ function using host-only classes (like boost::shared_ptr). Solve this problem by adding explicit methods for all of these.
2015-10-21 22:27:09 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
using ShapeArrayType = typename VisitCellsWithPointsConnectivityType::ShapeArrayType;
using NumIndicesArrayType = typename VisitCellsWithPointsConnectivityType::NumIndicesArrayType;
using ConnectivityArrayType =
typename VisitCellsWithPointsConnectivityType::ConnectivityArrayType;
using IndexOffsetArrayType = typename VisitCellsWithPointsConnectivityType::IndexOffsetArrayType;
Add default constructors/destructors/assignment to CellSet classes The CellSet classes all exclusively work in the control environment. However, CUDA likes to add __device__ to constructors, destructors, and assignment operators it automatically adds. This in turn causes warnings about the __device__ function using host-only classes (like boost::shared_ptr). Solve this problem by adding explicit methods for all of these.
2015-10-21 22:27:09 +00:00
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT CellSetExplicit(const std::string& name = std::string());
VTKM_CONT CellSetExplicit(const Thisclass& src);
Make sure important vtkm::cont classes have noexcept move ops. This is important so they can be stored efficiently inside containers such as std::vector that require strong move guarantees.
2018-12-07 20:54:20 +00:00
VTKM_CONT CellSetExplicit(Thisclass&& src) noexcept;
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT Thisclass& operator=(const Thisclass& src);
Make sure important vtkm::cont classes have noexcept move ops. This is important so they can be stored efficiently inside containers such as std::vector that require strong move guarantees.
2018-12-07 20:54:20 +00:00
VTKM_CONT Thisclass& operator=(Thisclass&& src) noexcept;
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
virtual ~CellSetExplicit();
Introduce vtkm_cont library to reduce weak vtable creation. This reduces the number of weak vtables vtkm generates, resulting in a reduction of binary sizes for projects that include vtkm classes in multiple translation units.
2016-12-16 22:04:58 +00:00
Remove all uses of VTKM_OVERRIDE at instead just use override. Since VTK-m now requires C++11 it is safe to remove our custom defines and move to using the keyword directly.
2017-11-02 12:36:05 +00:00
vtkm::Id GetNumberOfCells() const override;
vtkm::Id GetNumberOfPoints() const override;
vtkm::Id GetNumberOfFaces() const override;
vtkm::Id GetNumberOfEdges() const override;
void PrintSummary(std::ostream& out) const override;
Add a release resources API to CellSet and its derived classes
2018-05-30 18:32:06 +00:00
void ReleaseResourcesExecution() override;
Introduce vtkm_cont library to reduce weak vtable creation. This reduces the number of weak vtables vtkm generates, resulting in a reduction of binary sizes for projects that include vtkm classes in multiple translation units.
2016-12-16 22:04:58 +00:00
CellSet uses NewInstance to be consistent with the rest of VTK-m
2019-04-02 20:23:51 +00:00
std::shared_ptr<CellSet> NewInstance() const override;
Improve CellSet API Add useful virtual functions to the vtkm::cont::CellSet base class.
2019-03-19 18:08:29 +00:00
void DeepCopy(const CellSet* src) override;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT vtkm::Id GetSchedulingRange(vtkm::TopologyElementTagCell) const;
VTKM_CONT vtkm::Id GetSchedulingRange(vtkm::TopologyElementTagPoint) const;
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
Improve CellSet API Add useful virtual functions to the vtkm::cont::CellSet base class.
2019-03-19 18:08:29 +00:00
VTKM_CONT vtkm::IdComponent GetNumberOfPointsInCell(vtkm::Id cellIndex) const override;
void GetCellPointIds(vtkm::Id id, vtkm::Id* ptids) const override;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Improve CellSet API Add useful virtual functions to the vtkm::cont::CellSet base class.
2019-03-19 18:08:29 +00:00
VTKM_CONT vtkm::UInt8 GetCellShape(vtkm::Id cellIndex) const override;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Cell to point compiler errors
2015-11-02 18:05:12 +00:00
template <vtkm::IdComponent ItemTupleLength>
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::Vec<vtkm::Id, ItemTupleLength>& ids) const;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Fix merges with master.
2017-08-28 20:58:44 +00:00
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::cont::ArrayHandle<vtkm::Id>& ids) const;
Merge branch 'streamline_returntype' of gitlab.kitware.com:dpugmire/vtk-m into streamline_returntype
2017-08-28 18:50:46 +00:00
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
/// First method to add cells -- one at a time.
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT void PrepareToAddCells(vtkm::Id numCells, vtkm::Id connectivityMaxLen);
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Make it not possible to create a cell set without specifying num points The CellSetExplicit and CellSetSingleType classes have an ivar that marks the number of points. There were several instances of code creating cell sets without specifying the number of points. This can be very bad if subsequent code needs that information.
2016-12-20 23:14:50 +00:00
template <typename IdVecType>
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT void AddCell(vtkm::UInt8 cellType, vtkm::IdComponent numVertices, const IdVecType& ids);
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
VTKM_CONT void CompleteAddingCells(vtkm::Id numPoints);
DataSet now holds DynamicCellSet instead of smart_ptr<CellSet> The Invoke of the topology dispatcher is also changed to expect a concrete cell set (which the DynamicCellSet is automatically cast to) rather than a connectivity structure. The dispatcher calls the GetNodeToCellConnectivity method for you. (That is currently the only one supported.)
2015-07-28 23:33:52 +00:00
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
/// Second method to add cells -- all at once.
/// Assigns the array handles to the explicit connectivity. This is
/// the way you can fill the memory from another system without copying
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
Make it not possible to create a cell set without specifying num points The CellSetExplicit and CellSetSingleType classes have an ivar that marks the number of points. There were several instances of code creating cell sets without specifying the number of points. This can be very bad if subsequent code needs that information.
2016-12-20 23:14:50 +00:00
void Fill(vtkm::Id numPoints,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
const vtkm::cont::ArrayHandle<vtkm::UInt8, ShapeStorageTag>& cellTypes,
const vtkm::cont::ArrayHandle<vtkm::IdComponent, NumIndicesStorageTag>& numIndices,
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityStorageTag>& connectivity,
const vtkm::cont::ArrayHandle<vtkm::Id, OffsetsStorageTag>& offsets =
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
vtkm::cont::ArrayHandle<vtkm::Id, OffsetsStorageTag>());
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename DeviceAdapter, typename VisitTopology, typename IncidentTopology>
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
struct ExecutionTypes
{
VTKM_IS_DEVICE_ADAPTER_TAG(DeviceAdapter);
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VTKM_IS_TOPOLOGY_ELEMENT_TAG(VisitTopology);
VTKM_IS_TOPOLOGY_ELEMENT_TAG(IncidentTopology);
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
using ConnectivityTypes = ConnectivityChooser<VisitTopology, IncidentTopology>;
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ShapePortalType = typename ConnectivityTypes::ShapeArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst;
using IndicePortalType =
typename ConnectivityTypes::NumIndicesArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst;
using ConnectivityPortalType =
typename ConnectivityTypes::ConnectivityArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst;
using IndexOffsetPortalType =
typename ConnectivityTypes::IndexOffsetArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst;
using ExecObjectType = vtkm::exec::ConnectivityExplicit<ShapePortalType,
IndicePortalType,
ConnectivityPortalType,
IndexOffsetPortalType>;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
};
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename Device, typename VisitTopology, typename IncidentTopology>
typename ExecutionTypes<Device, VisitTopology, IncidentTopology>::ExecObjectType
PrepareForInput(Device, VisitTopology, IncidentTopology) const;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT const typename ConnectivityChooser<VisitTopology, IncidentTopology>::ShapeArrayType&
GetShapesArray(VisitTopology, IncidentTopology) const;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT const typename ConnectivityChooser<VisitTopology,
IncidentTopology>::NumIndicesArrayType&
GetNumIndicesArray(VisitTopology, IncidentTopology) const;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT const typename ConnectivityChooser<VisitTopology,
IncidentTopology>::ConnectivityArrayType&
GetConnectivityArray(VisitTopology, IncidentTopology) const;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT const typename ConnectivityChooser<VisitTopology,
IncidentTopology>::IndexOffsetArrayType&
GetIndexOffsetArray(VisitTopology, IncidentTopology) const;
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +00:00
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
// Can be used to check if e.g. CellToPoint table is built.
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT bool HasConnectivity(VisitTopology from, IncidentTopology to) const
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
{
return this->HasConnectivityImpl(from, to);
}
// Can be used to reset a connectivity table, mostly useful for benchmarking.
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT void ResetConnectivity(VisitTopology from, IncidentTopology to)
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
{
this->ResetConnectivityImpl(from, to);
}
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
protected:
Use requested device in CellSetExplicit::PrepareForInput. The BuildConnectivity method was falling back to the global runtime device tracker instead of using the templated device.
2018-08-22 18:50:38 +00:00
VTKM_CONT void BuildConnectivity(vtkm::cont::DeviceAdapterId,
vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint) const;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VTKM_CONT void BuildConnectivity(vtkm::cont::DeviceAdapterId,
vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell) const;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
VTKM_CONT bool HasConnectivityImpl(vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint) const
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
return this->Data->VisitCellsWithPoints.ElementsValid;
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
}
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VTKM_CONT bool HasConnectivityImpl(vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell) const
{
return this->Data->VisitPointsWithCells.ElementsValid;
}
VTKM_CONT void ResetConnectivityImpl(vtkm::TopologyElementTagCell, vtkm::TopologyElementTagPoint)
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
{
// Reset entire cell set
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
this->Data->VisitCellsWithPoints = VisitCellsWithPointsInternalsType{};
this->Data->VisitPointsWithCells = VisitPointsWithCellsInternalsType{};
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
this->Data->ConnectivityAdded = -1;
this->Data->NumberOfCellsAdded = -1;
this->Data->NumberOfPoints = 0;
}
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VTKM_CONT void ResetConnectivityImpl(vtkm::TopologyElementTagPoint, vtkm::TopologyElementTagCell)
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
this->Data->VisitPointsWithCells = VisitPointsWithCellsInternalsType{};
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
}
// Store internals in a shared pointer so shallow copies stay consistent.
// See #2268.
struct Internals
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
VisitCellsWithPointsInternalsType VisitCellsWithPoints;
VisitPointsWithCellsInternalsType VisitPointsWithCells;
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
// These are used in the AddCell and related methods to incrementally add
// cells. They need to be protected as subclasses of CellSetExplicit
// need to set these values when implementing Fill()
vtkm::Id ConnectivityAdded;
vtkm::Id NumberOfCellsAdded;
vtkm::Id NumberOfPoints;
VTKM_CONT
Internals()
: ConnectivityAdded(-1)
, NumberOfCellsAdded(-1)
, NumberOfPoints(0)
{
}
};
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
Refactor CellSetExplicit to store connectivity in a shared_ptr. This addresses issue #268 by ensuring that the CellToPoint validity flag survives FunctionInterface's value copies.
2018-08-22 16:09:56 +00:00
std::shared_ptr<Internals> Data;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
private:
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
const VisitCellsWithPointsInternalsType& GetConnectivity(vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint) const
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
return this->Data->VisitCellsWithPoints;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
}
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
const VisitCellsWithPointsInternalsType& GetConnectivity(vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint)
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
return this->Data->VisitCellsWithPoints;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
}
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
const VisitPointsWithCellsInternalsType& GetConnectivity(vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell) const
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
return this->Data->VisitPointsWithCells;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
}
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
const VisitPointsWithCellsInternalsType& GetConnectivity(vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell)
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
{
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
return this->Data->VisitPointsWithCells;
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
}
adding initial cell set structures
2015-04-15 16:43:12 +00:00
};
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace detail
{
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename Storage1, typename Storage2, typename Storage3, typename Storage4>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
struct CellSetExplicitConnectivityChooser<
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::cont::CellSetExplicit<Storage1, Storage2, Storage3, Storage4>,
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
{
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ConnectivityType =
vtkm::cont::internal::ConnectivityExplicitInternals<Storage1, Storage2, Storage3, Storage4>;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
};
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename CellSetType>
Respect VTK-m convention of parameters all or nothing on a line clang-format BinPack settings have been disabled to make sure that the VTK-m style guideline is obeyed.
2017-05-26 17:53:28 +00:00
struct CellSetExplicitConnectivityChooser<CellSetType,
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>
CellSetExplicit Reverse Connectivity is abit more efficient. Both computing the reverse connectivity and also the total footprint are now smaller.
2016-11-29 19:17:02 +00:00
{
//only specify the shape type as it will be constant as everything
//is a vertex. otherwise use the defaults.
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ConnectivityType = vtkm::cont::internal::ConnectivityExplicitInternals<
typename ArrayHandleConstant<vtkm::UInt8>::StorageTag>;
CellSetExplicit Reverse Connectivity is abit more efficient. Both computing the reverse connectivity and also the total footprint are now smaller.
2016-11-29 19:17:02 +00:00
};
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
} // namespace detail
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
Fix many warnings from doxygen There are still some warnings left: * Some text in markdown files are incorrectly picked up as doxygen commands * ArrayPortalTransform weirdly inherits from a specialized version of itself. It's technically correct C++ code, but gives doxygen fits.
2017-09-21 23:14:55 +00:00
/// \cond
/// Make doxygen ignore this section
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
#ifndef vtk_m_cont_CellSetExplicit_cxx
extern template class VTKM_CONT_TEMPLATE_EXPORT CellSetExplicit<>; // default
extern template class VTKM_CONT_TEMPLATE_EXPORT CellSetExplicit<
typename vtkm::cont::ArrayHandleConstant<vtkm::UInt8>::StorageTag,
typename vtkm::cont::ArrayHandleConstant<vtkm::IdComponent>::StorageTag,
VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG,
typename vtkm::cont::ArrayHandleCounting<vtkm::Id>::StorageTag>; // CellSetSingleType base
#endif
Fix many warnings from doxygen There are still some warnings left: * Some text in markdown files are incorrectly picked up as doxygen commands * ArrayPortalTransform weirdly inherits from a specialized version of itself. It's technically correct C++ code, but gives doxygen fits.
2017-09-21 23:14:55 +00:00
/// \endcond
adding initial cell set structures
2015-04-15 16:43:12 +00:00
}
} // namespace vtkm::cont
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
//=============================================================================
// Specializations of serialization related classes
namespace vtkm
{
namespace cont
{
template <typename ShapeST, typename CountST, typename ConnectivityST, typename OffsetST>
Clarify intent of TypeString and TypeName functions. TypeName is used for logging, and is now TypeToString. TypeString is used for serialization, and is now SerializableTypeString.
2019-02-28 18:15:27 +00:00
struct SerializableTypeString<
vtkm::cont::CellSetExplicit<ShapeST, CountST, ConnectivityST, OffsetST>>
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
{
static VTKM_CONT const std::string& Get()
{
static std::string name = "CS_Explicit<" +
Clarify intent of TypeString and TypeName functions. TypeName is used for logging, and is now TypeToString. TypeString is used for serialization, and is now SerializableTypeString.
2019-02-28 18:15:27 +00:00
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::UInt8, ShapeST>>::Get() + "_ST," +
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::IdComponent, CountST>>::Get() + "_ST," +
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityST>>::Get() + "_ST," +
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::Id, OffsetST>>::Get() + "_ST>";
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
return name;
}
};
}
} // vtkm::cont
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
namespace mangled_diy_namespace
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
{
template <typename ShapeST, typename CountST, typename ConnectivityST, typename OffsetST>
struct Serialization<vtkm::cont::CellSetExplicit<ShapeST, CountST, ConnectivityST, OffsetST>>
{
private:
using Type = vtkm::cont::CellSetExplicit<ShapeST, CountST, ConnectivityST, OffsetST>;
public:
static VTKM_CONT void save(BinaryBuffer& bb, const Type& cs)
{
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::save(bb, cs.GetName());
vtkmdiy::save(bb, cs.GetNumberOfPoints());
vtkmdiy::save(
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
bb, cs.GetShapesArray(vtkm::TopologyElementTagCell{}, vtkm::TopologyElementTagPoint{}));
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::save(
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
bb, cs.GetNumIndicesArray(vtkm::TopologyElementTagCell{}, vtkm::TopologyElementTagPoint{}));
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::save(
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
bb, cs.GetConnectivityArray(vtkm::TopologyElementTagCell{}, vtkm::TopologyElementTagPoint{}));
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::save(
Refactor topology mappings to clarify meaning. The `From` and `To` nomenclature for topology mapping has been confusing for both users and developers, especially at lower levels where the intention of mapping attributes from one element to another is easily conflated with the concept of mapping indices (which maps in the exact opposite direction). These identifiers have been renamed to `VisitTopology` and `IncidentTopology` to clarify the direction of the mapping. The order in which these template parameters are specified for `WorkletMapTopology` have also been reversed, since eventually there may be more than one `IncidentTopology`, and having `IncidentTopology` at the end will allow us to replace it with a variadic template parameter pack in the future. Other implementation details supporting these worklets, include `Fetch` tags, `Connectivity` classes, and methods on the various `CellSet` classes (such as `PrepareForInput` have also reversed their template arguments. These will need to be cautiously updated. The convenience implementations of `WorkletMapTopology` have been renamed for clarity as follows: ``` WorkletMapPointToCell --> WorkletVisitCellsWithPoints WorkletMapCellToPoint --> WorkletVisitPointsWithCells ``` The `ControlSignature` tags have been renamed as follows: ``` FieldInTo --> FieldInVisit FieldInFrom --> FieldInMap FromCount --> IncidentElementCount FromIndices --> IncidentElementIndices ```
2019-07-30 16:53:51 +00:00
bb, cs.GetIndexOffsetArray(vtkm::TopologyElementTagCell{}, vtkm::TopologyElementTagPoint{}));
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
}
static VTKM_CONT void load(BinaryBuffer& bb, Type& cs)
{
std::string name;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, name);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
vtkm::Id numberOfPoints = 0;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, numberOfPoints);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
vtkm::cont::ArrayHandle<vtkm::UInt8, ShapeST> shapes;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, shapes);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
vtkm::cont::ArrayHandle<vtkm::IdComponent, CountST> counts;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, counts);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityST> connectivity;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, connectivity);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
vtkm::cont::ArrayHandle<vtkm::Id, OffsetST> offsets;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, offsets);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
cs = Type(name);
cs.Fill(numberOfPoints, shapes, counts, connectivity, offsets);
}
};
} // diy
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
#include <vtkm/cont/CellSetExplicit.hxx>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#endif //vtk_m_cont_CellSetExplicit_h
Reference in New Issue Copy Permalink