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

584 lines
22 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.
// This software is distributed WITHOUT ANY WARRANTY; without even
// the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE. See the above copyright notice for more information.
//
// Copyright 2015 Sandia Corporation.
// Copyright 2015 UT-Battelle, LLC.
// Copyright 2015 Los Alamos National Security.
//
// Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation,
// the U.S. Government retains certain rights in this software.
//
// Under the terms of Contract DE-AC52-06NA25396 with Los Alamos National
// Laboratory (LANL), the U.S. Government retains certain rights in
// this software.
//============================================================================
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#ifndef vtk_m_cont_CellSetExplicit_h
#define vtk_m_cont_CellSetExplicit_h
Rename CellType to CellShape. We have been using the term "shape" in the cell set and connectivity classes. To be consistent, use the term "shape" for the geometric identify of the cell everywhere.
2015-08-16 18:53:44 +00:00
#include <vtkm/CellShape.h>
clang-format: sort include directives
2017-05-18 14:51:24 +00:00
#include <vtkm/TopologyElementTag.h>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
#include <vtkm/cont/CellSet.h>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
#include <vtkm/cont/internal/ConnectivityExplicitInternals.h>
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
#include <vtkm/exec/ConnectivityExplicit.h>
adding initial cell set structures
2015-04-15 16:43:12 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
#include <vtkm/cont/ArrayHandleConstant.h>
clang-format: sort include directives
2017-05-18 14:51:24 +00:00
#include <vtkm/cont/ArrayHandleCounting.h>
#include <vtkm/exec/ExecutionWholeArray.h>
#include <vtkm/worklet/DispatcherMapField.h>
#include <vtkm/worklet/WorkletMapField.h>
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
#include <map>
#include <utility>
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename CellSetType, typename FromTopology, typename ToTopology>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
struct CellSetExplicitConnectivityChooser
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typedef vtkm::cont::internal::ConnectivityExplicitInternals<> ConnectivityType;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
};
} // namespace detail
CellSetExplicit storage tags are now easier to override.
2015-09-23 17:52:58 +00:00
#ifndef VTKM_DEFAULT_SHAPE_STORAGE_TAG
#define VTKM_DEFAULT_SHAPE_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
#ifndef VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG
#define VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
#ifndef VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG
#define VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
#ifndef VTKM_DEFAULT_OFFSETS_STORAGE_TAG
#define VTKM_DEFAULT_OFFSETS_STORAGE_TAG VTKM_DEFAULT_STORAGE_TAG
#endif
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename ShapeStorageTag = VTKM_DEFAULT_SHAPE_STORAGE_TAG,
typename NumIndicesStorageTag = VTKM_DEFAULT_NUM_INDICES_STORAGE_TAG,
typename ConnectivityStorageTag = VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG,
typename OffsetsStorageTag = VTKM_DEFAULT_OFFSETS_STORAGE_TAG>
Fix CellSet* typeid to consistent across dynamic libraries. Since we don't have explicit template instantiations for CellSetExplicit and CellSetSingleType we need to mark them as being exported from all libraries.
2017-03-01 22:11:23 +00:00
class VTKM_ALWAYS_EXPORT CellSetExplicit : public CellSet
adding initial cell set structures
2015-04-15 16:43:12 +00:00
{
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
typedef CellSetExplicit<ShapeStorageTag,
NumIndicesStorageTag,
ConnectivityStorageTag,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
OffsetsStorageTag>
Thisclass;
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename FromTopology, typename ToTopology>
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
{
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
typedef
typename detail::CellSetExplicitConnectivityChooser<Thisclass, FromTopology, ToTopology>::
ConnectivityType ConnectivityType;
CellSetExplicit Getters now properly deduce the correct handle type. Previously the CellSetExplicit presumed that the CellToPoint and PointToCell Storage tags matched, which they don't when using custom storage tags.
2015-09-24 19:02:33 +00:00
typedef typename ConnectivityType::ShapeArrayType ShapeArrayType;
typedef typename ConnectivityType::NumIndicesArrayType NumIndicesArrayType;
typedef typename ConnectivityType::ConnectivityArrayType ConnectivityArrayType;
typedef typename ConnectivityType::IndexOffsetArrayType IndexOffsetArrayType;
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
};
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
public:
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
typedef vtkm::Id SchedulingRangeType;
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
Add CellSetPermutation which allows custom iteration over a cell set. When you create a CellSetPermutation you provide an array of the cell ids that you want to iterate. This allows the user to do custom blanking of a data set, or to do multi iteration over a set of cells.
2015-09-28 17:15:26 +00:00
//point to cell is used when iterating cells and asking for point properties
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typedef ConnectivityChooser<vtkm::TopologyElementTagPoint, vtkm::TopologyElementTagCell>
PointToCellConnectivityType;
Add CellSetPermutation which allows custom iteration over a cell set. When you create a CellSetPermutation you provide an array of the cell ids that you want to iterate. This allows the user to do custom blanking of a data set, or to do multi iteration over a set of cells.
2015-09-28 17:15:26 +00:00
typedef typename PointToCellConnectivityType::ShapeArrayType ShapeArrayType;
typedef typename PointToCellConnectivityType::NumIndicesArrayType NumIndicesArrayType;
typedef typename PointToCellConnectivityType::ConnectivityArrayType ConnectivityArrayType;
typedef typename PointToCellConnectivityType::IndexOffsetArrayType IndexOffsetArrayType;
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
CellSetExplicit(const std::string& name = std::string())
: CellSet(name)
, ConnectivityAdded(-1)
, NumberOfCellsAdded(-1)
, NumberOfPoints(0)
Created DynamicCellSet The DynamicCellSet will be used in place of the pointer to a CellSet in a DataSet. This will prevent us from having to cast it all the time and also remove reliance on boost smart_ptr.
2015-07-27 16:13:27 +00:00
{
}
Remove exports for header-only functions/methods Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and EXEC_CONT.) Remove the inline from these macros so that they can be applied to everything, including implementations in a library. Because inline is not declared in these modifies, you have to add the keyword to functions and methods where the implementation is not inlined in the class.
2016-10-19 22:42:58 +00:00
VTKM_CONT
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
CellSetExplicit(const Thisclass& src)
: CellSet(src)
, PointToCell(src.PointToCell)
, CellToPoint(src.CellToPoint)
, ConnectivityAdded(src.ConnectivityAdded)
, NumberOfCellsAdded(src.NumberOfCellsAdded)
, NumberOfPoints(src.NumberOfPoints)
{
}
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
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
Thisclass& operator=(const Thisclass& src)
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
{
this->CellSet::operator=(src);
this->PointToCell = src.PointToCell;
this->CellToPoint = src.CellToPoint;
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
this->ConnectivityAdded = src.ConnectivityAdded;
this->NumberOfCellsAdded = src.NumberOfCellsAdded;
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
this->NumberOfPoints = src.NumberOfPoints;
return *this;
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
virtual ~CellSetExplicit() {}
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
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
vtkm::Id GetNumberOfCells() const VTKM_OVERRIDE
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +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
return this->PointToCell.GetNumberOfElements();
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::Id GetNumberOfPoints() const VTKM_OVERRIDE { return this->NumberOfPoints; }
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
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
vtkm::Id GetNumberOfFaces() const VTKM_OVERRIDE { return -1; }
vtkm::Id GetNumberOfEdges() const VTKM_OVERRIDE { return -1; }
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
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
vtkm::Id GetSchedulingRange(vtkm::TopologyElementTagCell) const
{
return this->GetNumberOfCells();
}
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
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
vtkm::Id GetSchedulingRange(vtkm::TopologyElementTagPoint) const
{
return this->GetNumberOfPoints();
}
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
GetNumberOfPointsInCell consistently returns a vtkm::IdComponent
2015-09-23 18:36:56 +00:00
vtkm::IdComponent GetNumberOfPointsInCell(vtkm::Id cellIndex) 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
{
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
return this->PointToCell.NumIndices.GetPortalConstControl().Get(cellIndex);
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
}
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
vtkm::UInt8 GetCellShape(vtkm::Id cellIndex) 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
{
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
return this->PointToCell.Shapes.GetPortalConstControl().Get(cellIndex);
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
}
Cell to point compiler errors
2015-11-02 18:05:12 +00:00
template <vtkm::IdComponent ItemTupleLength>
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::Vec<vtkm::Id, ItemTupleLength>& ids) const
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
{
Cell to point compiler errors
2015-11-02 18:05:12 +00:00
this->PointToCell.BuildIndexOffsets(VTKM_DEFAULT_DEVICE_ADAPTER_TAG());
GetNumberOfPointsInCell consistently returns a vtkm::IdComponent
2015-09-23 18:36:56 +00:00
vtkm::IdComponent numIndices = this->GetNumberOfPointsInCell(index);
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::Id start = this->PointToCell.IndexOffsets.GetPortalConstControl().Get(index);
for (vtkm::IdComponent i = 0; i < numIndices && i < ItemTupleLength; i++)
ids[i] = this->PointToCell.Connectivity.GetPortalConstControl().Get(start + i);
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 compiler warnings. Add ArrayHandle method for getting cell id
2017-07-27 14:10:43 +00:00
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::cont::ArrayHandle<vtkm::Id>& ids) const
{
this->PointToCell.BuildIndexOffsets(VTKM_DEFAULT_DEVICE_ADAPTER_TAG());
vtkm::IdComponent numIndices = this->GetNumberOfPointsInCell(index);
ids.Allocate(numIndices);
vtkm::Id start = this->PointToCell.IndexOffsets.GetPortalConstControl().Get(index);
vtkm::cont::ArrayHandle<vtkm::Id>::PortalControl idPortal = ids.GetPortalControl();
auto PtCellPortal = this->PointToCell.Connectivity.GetPortalConstControl();
for (vtkm::IdComponent i = 0; i < numIndices && i < numIndices; i++)
idPortal.Set(i, PtCellPortal.Get(start + i));
}
Merge branch 'streamline_returntype' of gitlab.kitware.com:dpugmire/vtk-m into streamline_returntype
2017-08-28 18:43:04 +00:00
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::cont::ArrayHandle<vtkm::Id>& ids) const
{
this->PointToCell.BuildIndexOffsets(VTKM_DEFAULT_DEVICE_ADAPTER_TAG());
vtkm::IdComponent numIndices = this->GetNumberOfPointsInCell(index);
ids.Allocate(numIndices);
vtkm::Id start = this->PointToCell.IndexOffsets.GetPortalConstControl().Get(index);
vtkm::cont::ArrayHandle<vtkm::Id>::PortalControl idPortal = ids.GetPortalControl();
auto PtCellPortal = this->PointToCell.Connectivity.GetPortalConstControl();
for (vtkm::IdComponent i = 0; i < numIndices && i < numIndices; i++)
idPortal.Set(i, PtCellPortal.Get(start + i));
}
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.
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 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
this->PointToCell.Shapes.Allocate(numCells);
this->PointToCell.NumIndices.Allocate(numCells);
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
this->PointToCell.Connectivity.Allocate(connectivityMaxLen);
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
this->PointToCell.IndexOffsets.Allocate(numCells);
this->NumberOfCellsAdded = 0;
this->ConnectivityAdded = 0;
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>
clang-format: apply to the entire tree
2017-05-18 14:29:41 +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
{
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
using Traits = vtkm::VecTraits<IdVecType>;
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
VTKM_STATIC_ASSERT_MSG((std::is_same<typename Traits::ComponentType, vtkm::Id>::value),
"CellSetSingleType::AddCell requires vtkm::Id for indices.");
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
if (Traits::GetNumberOfComponents(ids) < numVertices)
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
throw vtkm::cont::ErrorBadValue("Not enough indices given to CellSetSingleType::AddCell.");
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
}
if (this->NumberOfCellsAdded >= this->PointToCell.Shapes.GetNumberOfValues())
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
throw vtkm::cont::ErrorBadValue("Added more cells then expected.");
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
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
if (this->ConnectivityAdded + numVertices > this->PointToCell.Connectivity.GetNumberOfValues())
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
{
Simplify exception hierarchy. Remove the ErrorControl class such that all subclasses now inherit from error. Renamed all exception classes via s/ErrorControl/Error/. See issue #57.
2017-01-09 21:15:32 +00:00
throw vtkm::cont::ErrorBadValue(
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
"Connectivity increased passed estimated maximum connectivity.");
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
}
this->PointToCell.Shapes.GetPortalControl().Set(this->NumberOfCellsAdded, cellType);
this->PointToCell.NumIndices.GetPortalControl().Set(this->NumberOfCellsAdded, numVertices);
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
for (vtkm::IdComponent iVec = 0; iVec < numVertices; ++iVec)
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
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
this->PointToCell.Connectivity.GetPortalControl().Set(this->ConnectivityAdded + iVec,
Traits::GetComponent(ids, iVec));
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
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
this->PointToCell.IndexOffsets.GetPortalControl().Set(this->NumberOfCellsAdded,
this->ConnectivityAdded);
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
this->NumberOfCellsAdded++;
this->ConnectivityAdded += numVertices;
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
}
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 CompleteAddingCells(vtkm::Id numPoints)
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
this->NumberOfPoints = numPoints;
this->PointToCell.Connectivity.Shrink(ConnectivityAdded);
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
this->PointToCell.ElementsValid = true;
Fix issue with PointToCell indices not being computed. Also, mark them as valid, when valid.
2015-12-08 20:14:43 +00:00
this->PointToCell.IndexOffsetsValid = true;
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
if (this->NumberOfCellsAdded != this->GetNumberOfCells())
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
throw vtkm::cont::ErrorBadValue("Did not add as many cells as expected.");
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
}
this->NumberOfCellsAdded = -1;
this->ConnectivityAdded = -1;
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
}
DataSet now holds DynamicCellSet instead of smart_ptr<CellSet> The Invoke of the topology dispatcher is also changed to expect a concrete cell set (which the DynamicCellSet is automatically cast to) rather than a connectivity structure. The dispatcher calls the GetNodeToCellConnectivity method for you. (That is currently the only one supported.)
2015-07-28 23:33:52 +00:00
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
/// Second method to add cells -- all at once.
/// Assigns the array handles to the explicit connectivity. This is
/// the way you can fill the memory from another system without copying
Remove exports for header-only functions/methods Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and EXEC_CONT.) Remove the inline from these macros so that they can be applied to everything, including implementations in a library. Because inline is not declared in these modifies, you have to add the keyword to functions and methods where the implementation is not inlined in the class.
2016-10-19 22:42:58 +00:00
VTKM_CONT
Make it not possible to create a cell set without specifying num points The CellSetExplicit and CellSetSingleType classes have an ivar that marks the number of points. There were several instances of code creating cell sets without specifying the number of points. This can be very bad if subsequent code needs that information.
2016-12-20 23:14:50 +00:00
void Fill(vtkm::Id numPoints,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
const vtkm::cont::ArrayHandle<vtkm::UInt8, ShapeStorageTag>& cellTypes,
const vtkm::cont::ArrayHandle<vtkm::IdComponent, NumIndicesStorageTag>& numIndices,
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityStorageTag>& connectivity,
const vtkm::cont::ArrayHandle<vtkm::Id, OffsetsStorageTag>& offsets =
vtkm::cont::ArrayHandle<vtkm::Id, OffsetsStorageTag>())
updating reg struct usage in cell set
2015-05-15 17:15:11 +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
this->NumberOfPoints = numPoints;
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
this->PointToCell.Shapes = cellTypes;
this->PointToCell.NumIndices = numIndices;
this->PointToCell.Connectivity = connectivity;
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
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
this->PointToCell.ElementsValid = true;
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
if (offsets.GetNumberOfValues() == cellTypes.GetNumberOfValues())
Correct issues found in code review.
2015-09-25 15:45:09 +00:00
{
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
this->PointToCell.IndexOffsets = offsets;
this->PointToCell.IndexOffsetsValid = true;
Correct issues found in code review.
2015-09-25 15:45:09 +00:00
}
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
else
Correct issues found in code review.
2015-09-25 15:45:09 +00:00
{
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
this->PointToCell.IndexOffsetsValid = false;
Correct issues found in code review.
2015-09-25 15:45:09 +00:00
if (offsets.GetNumberOfValues() != 0)
{
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
throw vtkm::cont::ErrorBadValue("Explicit cell offsets array unexpected size. "
"Use an empty array to automatically generate.");
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
}
Correct issues found in code review.
2015-09-25 15:45:09 +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
}
template <typename DeviceAdapter, typename FromTopology, typename ToTopology>
struct ExecutionTypes
{
VTKM_IS_DEVICE_ADAPTER_TAG(DeviceAdapter);
VTKM_IS_TOPOLOGY_ELEMENT_TAG(FromTopology);
VTKM_IS_TOPOLOGY_ELEMENT_TAG(ToTopology);
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typedef ConnectivityChooser<FromTopology, ToTopology> ConnectivityTypes;
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
typedef typename ConnectivityTypes::ShapeArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst ShapePortalType;
typedef typename ConnectivityTypes::NumIndicesArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst IndicePortalType;
typedef typename ConnectivityTypes::ConnectivityArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst ConnectivityPortalType;
typedef typename ConnectivityTypes::IndexOffsetArrayType::template ExecutionTypes<
DeviceAdapter>::PortalConst IndexOffsetPortalType;
Roll connectivity information into CellSet in control environment Previously there was a Connectivity* structure for both the control environment and the execution environment. This was necessary before because the connectivity is explicit to the from and to topology elements, so you would get this structure from the appropriate call to CellSet*. However, the symantics are changed so that the type of connectivity is selected in the worklet's dispatcher. Thus, it is now much cleaner to manage the CellSet structure in the CellSet class itself and just have a single set of Connectivity* classes in the execution environment.
2015-08-02 21:59:44 +00:00
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
typedef vtkm::exec::ConnectivityExplicit<ShapePortalType,
IndicePortalType,
ConnectivityPortalType,
IndexOffsetPortalType>
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
ExecObjectType;
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
};
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename Device, typename FromTopology, typename ToTopology>
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
typename ExecutionTypes<Device, FromTopology, ToTopology>::ExecObjectType
PrepareForInput(Device, FromTopology, ToTopology) 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
{
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
this->BuildConnectivity(Device(), FromTopology(), ToTopology());
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
const typename ConnectivityChooser<FromTopology, ToTopology>::ConnectivityType& connectivity =
this->GetConnectivity(FromTopology(), ToTopology());
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
Remove cont/Assert.h and exec/Assert.h These asserts are consolidated into the unified Assert.h. Also made some minor edits to add asserts where appropriate and a little bit of reconfiguring as found.
2016-04-20 21:41:14 +00:00
VTKM_ASSERT(connectivity.ElementsValid);
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
typedef typename ExecutionTypes<Device, FromTopology, ToTopology>::ExecObjectType ExecObjType;
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
return ExecObjType(connectivity.Shapes.PrepareForInput(Device()),
connectivity.NumIndices.PrepareForInput(Device()),
connectivity.Connectivity.PrepareForInput(Device()),
connectivity.IndexOffsets.PrepareForInput(Device()));
updating reg struct usage in cell set
2015-05-15 17:15:11 +00:00
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename Device, typename FromTopology, typename ToTopology>
VTKM_CONT void BuildConnectivity(Device, FromTopology, ToTopology) const
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
{
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
typedef CellSetExplicit<ShapeStorageTag,
NumIndicesStorageTag,
ConnectivityStorageTag,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
OffsetsStorageTag>
CSE;
Fix issue with PointToCell indices not being computed. Also, mark them as valid, when valid.
2015-12-08 20:14:43 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
CSE* self = const_cast<CSE*>(this);
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
self->CreateConnectivity(Device(), FromTopology(), ToTopology());
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
self->GetConnectivity(FromTopology(), ToTopology()).BuildIndexOffsets(Device());
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename Device>
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
VTKM_CONT void CreateConnectivity(Device,
vtkm::TopologyElementTagPoint,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::TopologyElementTagCell)
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
{
// nothing to do
}
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// Worklet to expand the PointToCell numIndices array by repeating cell index
class ExpandIndices : public vtkm::worklet::WorkletMapField
automatically build connectivity as needed.
2015-09-01 22:37:17 +00:00
{
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
public:
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
typedef void ControlSignature(FieldIn<> cellIndex,
FieldIn<> offset,
FieldIn<> numIndices,
Make sure tests for many devices are using requested devices There are several tests in the cont directory that are in header files so that they can be recompiled for different devices. Make sure that the tests are exclusively using the device being tested by making the error device adapter the default. If any part of the test tries to use the default device (which could be different than the one being tested), a compile error will occur. Several of these compile errors are fixed in this commit.
2016-06-23 23:34:01 +00:00
WholeArrayOut<> cellIndices);
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typedef void ExecutionSignature(_1, _2, _3, _4);
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
typedef _1 InputDomain;
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
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
ExpandIndices() {}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename PortalType>
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
VTKM_EXEC void operator()(const vtkm::Id& cellIndex,
const vtkm::Id& offset,
const vtkm::Id& numIndices,
const PortalType& cellIndices) const
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
{
Make sure tests for many devices are using requested devices There are several tests in the cont directory that are in header files so that they can be recompiled for different devices. Make sure that the tests are exclusively using the device being tested by making the error device adapter the default. If any part of the test tries to use the default device (which could be different than the one being tested), a compile error will occur. Several of these compile errors are fixed in this commit.
2016-06-23 23:34:01 +00:00
VTKM_ASSERT(cellIndices.GetNumberOfValues() >= offset + numIndices);
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
vtkm::Id startIndex = offset;
for (vtkm::Id i = 0; i < numIndices; i++)
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
{
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
cellIndices.Set(startIndex++, cellIndex);
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
}
}
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
};
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
template <typename Device>
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
VTKM_CONT void CreateConnectivity(Device,
vtkm::TopologyElementTagCell,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::TopologyElementTagPoint)
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
{
// PointToCell connectivity array (point indices) will be
// transformed into the CellToPoint numIndices array using reduction
//
// PointToCell numIndices array using expansion will be
// transformed into the CellToPoint connectivity array
Fix issue with PointToCell indices not being computed. Also, mark them as valid, when valid.
2015-12-08 20:14:43 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
if (this->CellToPoint.ElementsValid)
CellSetExplicit CreateConnectivity works even when NumberOfPoints is zero. Previously if you created a cell set explicit and didn't set the number of points you would get a runtime error when you over-ran an array's bounds. Now we account for this use case and properly generate the Cell To Point Connectivity.
2015-09-24 17:58:19 +00:00
{
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
return;
CellSetExplicit CreateConnectivity works even when NumberOfPoints is zero. Previously if you created a cell set explicit and didn't set the number of points you would get a runtime error when you over-ran an array's bounds. Now we account for this use case and properly generate the Cell To Point Connectivity.
2015-09-24 17:58:19 +00:00
}
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
typedef vtkm::cont::DeviceAdapterAlgorithm<Device> Algorithm;
CellSetExplicit CreateConnectivity works even when NumberOfPoints is zero. Previously if you created a cell set explicit and didn't set the number of points you would get a runtime error when you over-ran an array's bounds. Now we account for this use case and properly generate the Cell To Point Connectivity.
2015-09-24 17:58:19 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// Sizes of the PointToCell information
Cell to point compiler errors
2015-11-02 18:05:12 +00:00
vtkm::Id numberOfCells = this->GetNumberOfCells();
vtkm::Id connectivityLength = this->PointToCell.Connectivity.GetNumberOfValues();
fixing cell-to-point conn generation to not use intermediate storage.
2015-09-01 22:56:32 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// PointToCell connectivity will be basis of CellToPoint numIndices
vtkm::cont::ArrayHandle<vtkm::Id> pointIndices;
Algorithm::Copy(this->PointToCell.Connectivity, pointIndices);
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// PointToCell numIndices will be basis of CellToPoint connectivity
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
this->CellToPoint.Connectivity.Allocate(connectivityLength);
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
vtkm::cont::ArrayHandleCounting<vtkm::Id> index(0, 1, numberOfCells);
CellSetExplicit CreateConnectivity works even when NumberOfPoints is zero. Previously if you created a cell set explicit and didn't set the number of points you would get a runtime error when you over-ran an array's bounds. Now we account for this use case and properly generate the Cell To Point Connectivity.
2015-09-24 17:58:19 +00:00
Fix issue with PointToCell indices not being computed. Also, mark them as valid, when valid.
2015-12-08 20:14:43 +00:00
this->PointToCell.BuildIndexOffsets(Device());
Make sure tests for many devices are using requested devices There are several tests in the cont directory that are in header files so that they can be recompiled for different devices. Make sure that the tests are exclusively using the device being tested by making the error device adapter the default. If any part of the test tries to use the default device (which could be different than the one being tested), a compile error will occur. Several of these compile errors are fixed in this commit.
2016-06-23 23:34:01 +00:00
vtkm::worklet::DispatcherMapField<ExpandIndices, Device> expandDispatcher;
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
expandDispatcher.Invoke(index,
this->PointToCell.IndexOffsets,
this->PointToCell.NumIndices,
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
this->CellToPoint.Connectivity);
CellSetExplicit CreateConnectivity works even when NumberOfPoints is zero. Previously if you created a cell set explicit and didn't set the number of points you would get a runtime error when you over-ran an array's bounds. Now we account for this use case and properly generate the Cell To Point Connectivity.
2015-09-24 17:58:19 +00:00
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// SortByKey where key is PointToCell connectivity and value is the expanded cellIndex
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
Algorithm::SortByKey(pointIndices, this->CellToPoint.Connectivity);
Correct issues that buildbot brought up in the code.
2015-09-24 14:15:44 +00:00
CellSetExplicit can now build reverse connectivity even when empty. Before we would try to access the -1 index of the connectivity array
2017-07-03 17:45:08 +00:00
if (this->GetNumberOfPoints() <= 0 && connectivityLength > 0)
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
{
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
this->NumberOfPoints = pointIndices.GetPortalControl().Get(connectivityLength - 1) + 1;
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
}
Fix issue with PointToCell indices not being computed. Also, mark them as valid, when valid.
2015-12-08 20:14:43 +00:00
vtkm::Id numberOfPoints = this->GetNumberOfPoints();
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// CellToPoint numIndices from the now sorted PointToCell connectivity
vtkm::cont::ArrayHandleConstant<vtkm::Id> numArray(1, connectivityLength);
vtkm::cont::ArrayHandle<vtkm::Id> uniquePoints;
vtkm::cont::ArrayHandle<vtkm::Id> numIndices;
uniquePoints.Allocate(numberOfPoints);
numIndices.Allocate(numberOfPoints);
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
Algorithm::ReduceByKey(pointIndices, numArray, uniquePoints, numIndices, vtkm::Add());
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
// Set the CellToPoint information
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
this->CellToPoint.Shapes = vtkm::cont::make_ArrayHandleConstant(
static_cast<vtkm::UInt8>(CELL_SHAPE_VERTEX), numberOfPoints);
Parallel CellToPoint initial code.
2015-10-30 19:59:36 +00:00
Algorithm::Copy(numIndices, this->CellToPoint.NumIndices);
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
this->CellToPoint.ElementsValid = true;
this->CellToPoint.IndexOffsetsValid = false;
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
void PrintSummary(std::ostream& out) const VTKM_OVERRIDE
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +00:00
{
Add explicit 1D rendering. Also added some data model suport.
2016-11-28 21:07:40 +00:00
out << " ExplicitCellSet: " << this->Name << std::endl;
out << " PointToCell: " << std::endl;
this->PointToCell.PrintSummary(out);
out << " CellToPoint: " << std::endl;
this->CellToPoint.PrintSummary(out);
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
}
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename FromTopology, typename ToTopology>
VTKM_CONT const typename ConnectivityChooser<FromTopology, ToTopology>::ShapeArrayType&
GetShapesArray(FromTopology, ToTopology) const
adding topology types to explicit cell set connectivity array accessors.
2015-09-02 16:26:37 +00:00
{
return this->GetConnectivity(FromTopology(), ToTopology()).Shapes;
}
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename FromTopology, typename ToTopology>
VTKM_CONT const typename ConnectivityChooser<FromTopology, ToTopology>::NumIndicesArrayType&
GetNumIndicesArray(FromTopology, ToTopology) const
adding topology types to explicit cell set connectivity array accessors.
2015-09-02 16:26:37 +00:00
{
return this->GetConnectivity(FromTopology(), ToTopology()).NumIndices;
}
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename FromTopology, typename ToTopology>
VTKM_CONT const typename ConnectivityChooser<FromTopology, ToTopology>::ConnectivityArrayType&
GetConnectivityArray(FromTopology, ToTopology) const
adding topology types to explicit cell set connectivity array accessors.
2015-09-02 16:26:37 +00:00
{
return this->GetConnectivity(FromTopology(), ToTopology()).Connectivity;
}
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
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename FromTopology, typename ToTopology>
VTKM_CONT const typename ConnectivityChooser<FromTopology, ToTopology>::IndexOffsetArrayType&
GetIndexOffsetArray(FromTopology, ToTopology) const
adding topology types to explicit cell set connectivity array accessors.
2015-09-02 16:26:37 +00:00
{
return this->GetConnectivity(FromTopology(), ToTopology()).IndexOffsets;
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +00:00
}
CellSetExplicit has userdefined offset storage.
2015-09-23 21:42:12 +00:00
protected:
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typename ConnectivityChooser<vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>::ConnectivityType PointToCell;
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
// TODO: Actually implement CellToPoint and other connectivity. (That is,
// derive the connectivity from PointToCell.
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typename ConnectivityChooser<vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint>::ConnectivityType CellToPoint;
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
private:
// A set of overloaded methods to get the connectivity from a pair of
// topology element types.
#define VTKM_GET_CONNECTIVITY_METHOD(FromTopology, ToTopology, Ivar) \
VTKM_CONT \
const typename ConnectivityChooser<FromTopology, ToTopology>::ConnectivityType& GetConnectivity( \
FromTopology, ToTopology) const \
{ \
return this->Ivar; \
} \
VTKM_CONT \
typename ConnectivityChooser<FromTopology, ToTopology>::ConnectivityType& GetConnectivity( \
FromTopology, ToTopology) \
{ \
return this->Ivar; \
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
}
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
VTKM_GET_CONNECTIVITY_METHOD(vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell,
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
PointToCell)
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
VTKM_GET_CONNECTIVITY_METHOD(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
CellToPoint)
#undef VTKM_GET_CONNECTIVITY_METHOD
Derived CellSetExplicit classes can now modify the incremental build state.
2016-02-22 18:29:00 +00:00
protected:
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
// These are used in the AddCell and related methods to incrementally add
Derived CellSetExplicit classes can now modify the incremental build state.
2016-02-22 18:29:00 +00:00
// cells. They need to be protected as subclasses of CellSetExplicit
// need to set these values when implementing Fill()
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
vtkm::Id ConnectivityAdded;
vtkm::Id NumberOfCellsAdded;
adding support and tests for cell-to-point topology worklet.
2015-08-28 17:51:42 +00:00
vtkm::Id NumberOfPoints;
adding initial cell set structures
2015-04-15 16:43:12 +00:00
};
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
namespace detail
{
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
template <typename Storage1, typename Storage2, typename Storage3, typename Storage4>
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
struct CellSetExplicitConnectivityChooser<
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::cont::CellSetExplicit<Storage1, Storage2, Storage3, Storage4>,
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
vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>
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
{
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
typedef vtkm::cont::internal::
ConnectivityExplicitInternals<Storage1, Storage2, Storage3, Storage4>
ConnectivityType;
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,
vtkm::TopologyElementTagCell,
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
vtkm::TopologyElementTagPoint>
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.
typedef vtkm::cont::internal::ConnectivityExplicitInternals<
clang-format: apply to the entire tree
2017-05-18 14:29:41 +00:00
typename ArrayHandleConstant<vtkm::UInt8>::StorageTag>
ConnectivityType;
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
adding initial cell set structures
2015-04-15 16:43:12 +00:00
}
} // namespace vtkm::cont
#endif //vtk_m_cont_CellSetExplicit_h
Reference in New Issue Copy Permalink