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

453 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>
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
#include <vtkm/Deprecated.h>
clang-format: sort include directives
2017-05-18 14:51:24 +00:00
#include <vtkm/TopologyElementTag.h>
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
#include <vtkm/cont/ArrayGetValues.h>
#include <vtkm/cont/ArrayHandleCast.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>
Create ArrayHandleOffsetsToNumComponents This is a fancy array that takes an array of offsets and converts it to an array of the number of components for each packed entry. This replaces the use of `ArrayHandleDecorator` in `CellSetExplicit`. The two implementation should do the same thing, but the new `ArrayHandleOffsetsToNumComponents` should be less complex for compilers.
2020-09-24 18:16:11 +00:00
#include <vtkm/cont/ArrayHandleOffsetsToNumComponents.h>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#include <vtkm/cont/CellSet.h>
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
#include <vtkm/cont/UnknownArrayHandle.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
};
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
// The connectivity generally used for the visit-points-with-cells connectivity.
// This type of connectivity does not have variable shape types, and since it is
// never really provided externally we can use the defaults for the other arrays.
using DefaultVisitPointsWithCellsConnectivityExplicit =
vtkm::cont::internal::ConnectivityExplicitInternals<
typename ArrayHandleConstant<vtkm::UInt8>::StorageTag>;
VTKM_CONT_EXPORT void BuildReverseConnectivity(
const vtkm::cont::UnknownArrayHandle& connections,
const vtkm::cont::UnknownArrayHandle& offsets,
vtkm::Id numberOfPoints,
vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit& visitPointsWithCells,
vtkm::cont::DeviceAdapterId device);
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
} // namespace detail
CellSetExplicit storage tags are now easier to override.
2015-09-23 17:52:58 +00:00
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
#ifndef VTKM_DEFAULT_SHAPES_STORAGE_TAG
#define VTKM_DEFAULT_SHAPES_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
CellSetExplicit storage tags are now easier to override.
2015-09-23 17:52:58 +00:00
#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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <typename ShapesStorageTag = VTKM_DEFAULT_SHAPES_STORAGE_TAG,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
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
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using Thisclass = CellSetExplicit<ShapesStorageTag, 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
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
private:
clang-format: reformat the repository with clang-format-9
2020-08-17 14:18:24 +00:00
using Chooser = typename detail::
CellSetExplicitConnectivityChooser<Thisclass, VisitTopology, IncidentTopology>;
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
public:
using ConnectivityType = typename Chooser::ConnectivityType;
using ShapesArrayType = typename ConnectivityType::ShapesArrayType;
Convert VTK-m over to use 'using' instead of 'typedef'
2017-08-16 15:34:21 +00:00
using ConnectivityArrayType = typename ConnectivityType::ConnectivityArrayType;
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using OffsetsArrayType = typename ConnectivityType::OffsetsArrayType;
Create ArrayHandleOffsetsToNumComponents This is a fancy array that takes an array of offsets and converts it to an array of the number of components for each packed entry. This replaces the use of `ArrayHandleDecorator` in `CellSetExplicit`. The two implementation should do the same thing, but the new `ArrayHandleOffsetsToNumComponents` should be less complex for compilers.
2020-09-24 18:16:11 +00:00
using NumIndicesArrayType = vtkm::cont::ArrayHandleOffsetsToNumComponents<OffsetsArrayType>;
Deprecate ArrayHandle::ExecutionTypes The newer version of `ArrayHandle` no longer supports different types of portals for different devices. Thus, the `ReadPortalType` and `WritePortalType` are sufficient for all types of portals across all devices. This significantly simplifies supporting execution objects on devices, and thus this change also includes many changes to various execution objects to remove their dependence on the device adapter tag.
2021-02-01 15:03:11 +00:00
using ExecConnectivityType =
vtkm::exec::ConnectivityExplicit<typename ShapesArrayType::ReadPortalType,
typename ConnectivityArrayType::ReadPortalType,
typename OffsetsArrayType::ReadPortalType>;
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using ConnTypes =
ConnectivityChooser<vtkm::TopologyElementTagCell, vtkm::TopologyElementTagPoint>;
using RConnTypes =
ConnectivityChooser<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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using CellPointIdsType = typename ConnTypes::ConnectivityType;
using PointCellIdsType = typename RConnTypes::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
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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using ShapesArrayType = typename CellPointIdsType::ShapesArrayType;
using ConnectivityArrayType = typename CellPointIdsType::ConnectivityArrayType;
using OffsetsArrayType = typename CellPointIdsType::OffsetsArrayType;
using NumIndicesArrayType = typename ConnTypes::NumIndicesArrayType;
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
CellSet classes don't require a name
2019-08-13 21:28:37 +00:00
VTKM_CONT CellSetExplicit();
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 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
Mark virtual destructors as override where applicable
2020-01-13 15:06:47 +00:00
VTKM_CONT virtual ~CellSetExplicit() 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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT vtkm::Id GetNumberOfCells() const override;
VTKM_CONT vtkm::Id GetNumberOfPoints() const override;
VTKM_CONT vtkm::Id GetNumberOfFaces() const override;
VTKM_CONT vtkm::Id GetNumberOfEdges() const override;
VTKM_CONT void PrintSummary(std::ostream& out) const 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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT void ReleaseResourcesExecution() override;
VTKM_CONT std::shared_ptr<CellSet> NewInstance() const override;
VTKM_CONT void DeepCopy(const CellSet* src) override;
Improve CellSet API Add useful virtual functions to the vtkm::cont::CellSet base class.
2019-03-19 18:08:29 +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 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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT vtkm::IdComponent GetNumberOfPointsInCell(vtkm::Id cellid) const override;
VTKM_CONT 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
Do not use auto return type; it's not supported until C++14.
2020-05-14 22:10:32 +00:00
VTKM_CONT typename vtkm::cont::ArrayHandle<vtkm::UInt8, ShapesStorageTag>::ReadPortalType
ShapesReadPortal() const;
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT vtkm::UInt8 GetCellShape(vtkm::Id cellid) 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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <vtkm::IdComponent NumIndices>
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::Vec<vtkm::Id, NumIndices>& 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,
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
const vtkm::cont::ArrayHandle<vtkm::UInt8, ShapesStorageTag>& cellTypes,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityStorageTag>& connectivity,
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
const vtkm::cont::ArrayHandle<vtkm::Id, OffsetsStorageTag>& offsets);
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <typename Device, typename VisitTopology, typename IncidentTopology>
Make deprecated tags more descriptive Also, test to make sure that the deprecated types are still valid.
2021-02-09 16:45:41 +00:00
struct VTKM_DEPRECATED(
1.6,
"Replace ExecutionTypes<D, V, I>::ExecObjectType with ExecConnectivityType<V, I>.")
ExecutionTypes
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
private:
VTKM_IS_DEVICE_ADAPTER_TAG(Device);
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using Chooser = ConnectivityChooser<VisitTopology, IncidentTopology>;
using ShapesAT = typename Chooser::ShapesArrayType;
using ConnAT = typename Chooser::ConnectivityArrayType;
using OffsetsAT = typename Chooser::OffsetsArrayType;
public:
Deprecate ArrayHandle::ExecutionTypes The newer version of `ArrayHandle` no longer supports different types of portals for different devices. Thus, the `ReadPortalType` and `WritePortalType` are sufficient for all types of portals across all devices. This significantly simplifies supporting execution objects on devices, and thus this change also includes many changes to various execution objects to remove their dependence on the device adapter tag.
2021-02-01 15:03:11 +00:00
using ShapesPortalType = typename ShapesAT::ReadPortalType;
using ConnectivityPortalType = typename ConnAT::ReadPortalType;
using OffsetsPortalType = typename OffsetsAT::ReadPortalType;
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using ExecObjectType =
vtkm::exec::ConnectivityExplicit<ShapesPortalType, ConnectivityPortalType, OffsetsPortalType>;
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
};
Deprecate ArrayHandle::ExecutionTypes The newer version of `ArrayHandle` no longer supports different types of portals for different devices. Thus, the `ReadPortalType` and `WritePortalType` are sufficient for all types of portals across all devices. This significantly simplifies supporting execution objects on devices, and thus this change also includes many changes to various execution objects to remove their dependence on the device adapter tag.
2021-02-01 15:03:11 +00:00
template <typename VisitTopology, typename IncidentTopology>
using ExecConnectivityType =
typename ConnectivityChooser<VisitTopology, IncidentTopology>::ExecConnectivityType;
Support using Token calling PrepareForExecution in ExecutionObject The old version of ExecutionObject (that only takes a device) is still supported, but you will get a deprecated warning if that is what is defined. Supporing this also included sending vtkm::cont::Token through the vtkm::cont::arg::Transport mechanism, which was a change that propogated through a lot of code.
2020-01-19 06:36:14 +00:00
Deprecate ArrayHandle::ExecutionTypes The newer version of `ArrayHandle` no longer supports different types of portals for different devices. Thus, the `ReadPortalType` and `WritePortalType` are sufficient for all types of portals across all devices. This significantly simplifies supporting execution objects on devices, and thus this change also includes many changes to various execution objects to remove their dependence on the device adapter tag.
2021-02-01 15:03:11 +00:00
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT ExecConnectivityType<VisitTopology, IncidentTopology> PrepareForInput(
vtkm::cont::DeviceAdapterId,
VisitTopology,
IncidentTopology,
vtkm::cont::Token&) const;
template <typename VisitTopology, typename IncidentTopology>
Support using Token calling PrepareForExecution in ExecutionObject The old version of ExecutionObject (that only takes a device) is still supported, but you will get a deprecated warning if that is what is defined. Supporing this also included sending vtkm::cont::Token through the vtkm::cont::arg::Transport mechanism, which was a change that propogated through a lot of code.
2020-01-19 06:36:14 +00:00
VTKM_DEPRECATED(1.6, "Provide a vtkm::cont::Token object when calling PrepareForInput.")
Deprecate ArrayHandle::ExecutionTypes The newer version of `ArrayHandle` no longer supports different types of portals for different devices. Thus, the `ReadPortalType` and `WritePortalType` are sufficient for all types of portals across all devices. This significantly simplifies supporting execution objects on devices, and thus this change also includes many changes to various execution objects to remove their dependence on the device adapter tag.
2021-02-01 15:03:11 +00:00
VTKM_CONT ExecConnectivityType<VisitTopology, IncidentTopology> PrepareForInput(
vtkm::cont::DeviceAdapterId device,
VisitTopology visitTopology,
IncidentTopology incidentTopology) const
Support using Token calling PrepareForExecution in ExecutionObject The old version of ExecutionObject (that only takes a device) is still supported, but you will get a deprecated warning if that is what is defined. Supporing this also included sending vtkm::cont::Token through the vtkm::cont::arg::Transport mechanism, which was a change that propogated through a lot of code.
2020-01-19 06:36:14 +00:00
{
vtkm::cont::Token token;
return this->PrepareForInput(device, visitTopology, incidentTopology, token);
}
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>
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT const typename ConnectivityChooser<VisitTopology, IncidentTopology>::ShapesArrayType&
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
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>::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>
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT const typename ConnectivityChooser<VisitTopology, IncidentTopology>::OffsetsArrayType&
GetOffsetsArray(VisitTopology, IncidentTopology) const;
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +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>
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT typename ConnectivityChooser<VisitTopology, IncidentTopology>::NumIndicesArrayType
GetNumIndicesArray(VisitTopology, IncidentTopology) const;
template <typename VisitTopology, typename IncidentTopology>
VTKM_CONT bool HasConnectivity(VisitTopology visit, IncidentTopology incident) 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
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->HasConnectivityImpl(visit, incident);
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 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>
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT void ResetConnectivity(VisitTopology visit, IncidentTopology incident)
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
this->ResetConnectivityImpl(visit, incident);
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
}
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,
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
vtkm::TopologyElementTagPoint) const
{
VTKM_ASSERT(this->Data->CellPointIds.ElementsValid);
// no-op
}
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
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
VTKM_CONT void BuildConnectivity(vtkm::cont::DeviceAdapterId device,
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,
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
vtkm::TopologyElementTagCell) const
{
detail::BuildReverseConnectivity(this->Data->CellPointIds.Connectivity,
this->Data->CellPointIds.Offsets,
this->Data->NumberOfPoints,
this->Data->PointCellIds,
device);
}
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->CellPointIds.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
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->PointCellIds.ElementsValid;
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::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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
this->Data->CellPointIds = CellPointIdsType{};
this->Data->PointCellIds = PointCellIdsType{};
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
this->Data->PointCellIds = PointCellIdsType{};
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
CellPointIdsType CellPointIds;
PointCellIdsType PointCellIds;
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT
const CellPointIdsType& 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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->CellPointIds;
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT
const CellPointIdsType& 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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->CellPointIds;
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT
const PointCellIdsType& 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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->PointCellIds;
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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
VTKM_CONT
const PointCellIdsType& 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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
return this->Data->PointCellIds;
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
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <typename Storage1, typename Storage2, typename Storage3>
struct CellSetExplicitConnectivityChooser<vtkm::cont::CellSetExplicit<Storage1, Storage2, Storage3>,
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 =
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
vtkm::cont::internal::ConnectivityExplicitInternals<Storage1, Storage2, Storage3>;
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.
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
using ConnectivityType = vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit;
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,
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
Don't generate doxygen for serialization helpers
2019-09-12 21:19:36 +00:00
/// @cond SERIALIZATION
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
namespace vtkm
{
namespace cont
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <typename SST, typename CST, typename OST>
struct SerializableTypeString<vtkm::cont::CellSetExplicit<SST, CST, OST>>
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
{
static VTKM_CONT const std::string& Get()
{
static std::string name = "CS_Explicit<" +
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::UInt8, SST>>::Get() + "_ST," +
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::Id, CST>>::Get() + "_ST," +
SerializableTypeString<vtkm::cont::ArrayHandle<vtkm::Id, OST>>::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
{
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
template <typename SST, typename CST, typename OST>
struct Serialization<vtkm::cont::CellSetExplicit<SST, CST, OST>>
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
{
private:
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
using Type = vtkm::cont::CellSetExplicit<SST, CST, OST>;
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
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.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.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 CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
bb, cs.GetOffsetsArray(vtkm::TopologyElementTagCell{}, vtkm::TopologyElementTagPoint{}));
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
}
static VTKM_CONT void load(BinaryBuffer& bb, Type& cs)
{
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);
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
vtkm::cont::ArrayHandle<vtkm::UInt8, SST> shapes;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, shapes);
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
vtkm::cont::ArrayHandle<vtkm::Id, CST> connectivity;
VTK-m now doesn't clobber external DIY installations Fixes #334
2019-02-05 16:02:29 +00:00
vtkmdiy::load(bb, connectivity);
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
vtkm::cont::ArrayHandle<vtkm::Id, OST> 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
CellSet classes don't require a name
2019-08-13 21:28:37 +00:00
cs = Type{};
Refactor CellSetExplicit to remove NumIndices. See #408 for details.
2019-08-30 17:04:17 +00:00
cs.Fill(numberOfPoints, shapes, connectivity, offsets);
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
}
};
} // diy
Don't generate doxygen for serialization helpers
2019-09-12 21:19:36 +00:00
/// @endcond SERIALIZATION
Implement DataSet Serialization
2018-06-18 17:56:38 +00:00
Support using Token calling PrepareForExecution in ExecutionObject The old version of ExecutionObject (that only takes a device) is still supported, but you will get a deprecated warning if that is what is defined. Supporing this also included sending vtkm::cont::Token through the vtkm::cont::arg::Transport mechanism, which was a change that propogated through a lot of code.
2020-01-19 06:36:14 +00:00
#ifndef vtk_m_cont_CellSetExplicit_hxx
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>
Support using Token calling PrepareForExecution in ExecutionObject The old version of ExecutionObject (that only takes a device) is still supported, but you will get a deprecated warning if that is what is defined. Supporing this also included sending vtkm::cont::Token through the vtkm::cont::arg::Transport mechanism, which was a change that propogated through a lot of code.
2020-01-19 06:36:14 +00:00
#endif //vtk_m_cont_CellSetExplicit_hxx
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
#endif //vtk_m_cont_CellSetExplicit_h
Reference in New Issue Copy Permalink