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

329 lines
12 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>
Change TopologyType identifiers from enumeration to tags. Previously, the items used to identify parts of topology like points, cells, faces, etc. were in an enumeration. However, they are only really used in template specialization, and it is easier to use tags in this case. So, change the enumeration to a set of tag structures. Also made the following changes: * Renamed TopologyType to TopologyElement, which is more indicative of what we are referring to. * Moved the structures from the vtkm::cont namespace to the vtkm namespace. There is no reason not to be able to use them from either the control or execution environments. * Added a VTKM_IS_TOPOLOGY_ELEMENT_TAG macro to do type checks on template arguments that are supposed to be topology element tags.
2015-07-31 19:59:37 +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
namespace vtkm {
namespace cont {
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 {
template<typename CellSetType, typename FromTopology, typename ToTopology>
struct CellSetExplicitConnectivityChooser
{
typedef vtkm::cont::internal::ConnectivityExplicitInternals<>
ConnectivityType;
};
} // namespace detail
CellSetExplicit can now use different storage backends. CellSetExplicit can now use different storage backends to allow for cheaper representations of the data. For example a pool of triangles can now implicit handles for shape and num indices. This does raise the question if runtime polymorphism is the best approach for CellSet, or if we should do some from of CRTP.
2015-06-01 13:55:53 +00:00
template<typename ShapeStorageTag = VTKM_DEFAULT_STORAGE_TAG,
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
typename NumIndicesStorageTag = VTKM_DEFAULT_STORAGE_TAG,
CellSetExplicit can now use different storage backends. CellSetExplicit can now use different storage backends to allow for cheaper representations of the data. For example a pool of triangles can now implicit handles for shape and num indices. This does raise the question if runtime polymorphism is the best approach for CellSet, or if we should do some from of CRTP.
2015-06-01 13:55:53 +00:00
typename ConnectivityStorageTag = VTKM_DEFAULT_STORAGE_TAG >
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
class CellSetExplicit : public CellSet
adding initial cell set structures
2015-04-15 16:43:12 +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
template<typename FromTopology, typename ToTopology>
struct ConnectivityChooser
{
typedef typename detail::CellSetExplicitConnectivityChooser<
CellSetExplicit<
ShapeStorageTag,NumIndicesStorageTag,ConnectivityStorageTag>,
FromTopology,
ToTopology>::ConnectivityType ConnectivityType;
};
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
Conform DataSet classes to coding practices better The most common changes were making class members uppercase and spelled out, adding "this->" whenever a class member is used, and declare functions and members with export macros. Also fixed some uses of int (instead of vtkm::Id or something similar) and a bit of indentation. I also sprinkled some const goodness over the code. It should be noted that I had about a week delay between first making these changes and checking them in. In the mean time Sujin also made some similar changes, so there might be some repetative changes.
2015-07-12 16:05:47 +00:00
VTKM_CONT_EXPORT
Use std::string() instead of "" to initialize strings. As per Robert Maynard's request.
2015-07-30 18:55:24 +00:00
CellSetExplicit(const std::string &name = std::string(),
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
vtkm::IdComponent dimensionality = 3)
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
: CellSet(name, dimensionality),
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
ConnectivityLength(-1),
NumberOfCells(-1)
adding wrapper for exec connectivity.
2015-05-12 13:39:00 +00:00
{
}
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
VTKM_CONT_EXPORT
CellSetExplicit(int dimensionality)
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
: CellSet(std::string(), dimensionality),
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
ConnectivityLength(-1),
NumberOfCells(-1)
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
{
}
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
virtual vtkm::Id GetNumberOfCells() const
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
}
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_CONT_EXPORT
vtkm::Id GetSchedulingRange(vtkm::TopologyElementTagCell) const
{
return this->GetNumberOfCells();
}
VTKM_CONT_EXPORT
Change Node -> Point Most of VTK-m follows the convention of calling the 0D topology elements "points" (which follows the convention of VTK). However, there were several places where they were referred to as "nodes." Make things consistent by calling them points everywhere. Also merged some redundant ExecutionSignature tags.
2015-08-03 16:06:59 +00:00
vtkm::Id 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
}
VTKM_CONT_EXPORT
Change Node -> Point Most of VTK-m follows the convention of calling the 0D topology elements "points" (which follows the convention of VTK). However, there were several places where they were referred to as "nodes." Make things consistent by calling them points everywhere. Also merged some redundant ExecutionSignature tags.
2015-08-03 16:06:59 +00:00
vtkm::Id 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
}
template <vtkm::IdComponent ItemTupleLength>
VTKM_CONT_EXPORT
void GetIndices(vtkm::Id index,
vtkm::Vec<vtkm::Id,ItemTupleLength> &ids) const
{
Reintroduce explicit connectivity class for cont environment (Re-) Add a helper structure that holds the connectivity information for a particular topology connection (e.g. from points to cells) to make it easier to manage connections in multiple different directions in CellSetExplicit. Unlike the previous version of connectivity, this structure is considered "internal" and not exposed through the API so that CellSetExplicit can better manage the data. Also, many of the helper methods remain in CellSetExplicit since they were specific for point-to- Also, CellSetExplicit has a mechanism to take an arbitrary pair of TopologyElementTags and get the appropriate connectivity. This should simplify adding connections in the future.
2015-08-11 18:42:34 +00:00
this->PointToCell.BuildIndexOffsets(VTKM_DEFAULT_DEVICE_ADAPTER_TAG());
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 numIndices = this->GetNumberOfIndices(index);
vtkm::Id start =
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.IndexOffset.GetPortalConstControl().Get(index);
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
for (vtkm::IdComponent i=0; i<numIndices && i<ItemTupleLength; i++)
ids[i] = this->Connectivity.GetPortalConstControl().Get(start+i);
}
/// First method to add cells -- one at a time.
VTKM_CONT_EXPORT
void PrepareToAddCells(vtkm::Id numShapes, vtkm::Id connectivityMaxLen)
{
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.Allocate(numShapes);
this->PointToCell.NumIndices.Allocate(numShapes);
this->PointToCell.Connectivity.Allocate(connectivityMaxLen);
this->PointToCell.IndexOffsets.Allocate(numShapes);
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
this->NumberOfCells = 0;
this->ConnectivityLength = 0;
}
template <vtkm::IdComponent ItemTupleLength>
VTKM_CONT_EXPORT
Add CellShapeTag classes Each cell shape id has an associated cell shape tag. There is also a macro to write functions that are conditional on the cell shape.
2015-08-16 21:31:36 +00:00
void AddCell(vtkm::IdComponent cellType,
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
int numVertices,
const vtkm::Vec<vtkm::Id,ItemTupleLength> &ids)
{
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.GetPortalControl().Set(this->NumberOfCells, cellType);
this->PointToCell.NumIndices.GetPortalControl().Set(this->NumberOfCells, 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
for (vtkm::IdComponent i=0; i < numVertices; ++i)
{
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.GetPortalControl().Set(
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
this->ConnectivityLength+i,ids[i]);
}
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.IndexOffsets.GetPortalControl().Set(
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
this->NumberOfCells, this->ConnectivityLength);
this->NumberOfCells++;
this->ConnectivityLength += numVertices;
}
VTKM_CONT_EXPORT
void CompleteAddingCells()
{
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.Shrink(ConnectivityLength);
this->PointToCell.ElementsValid = true;
this->NumberOfCells = this->ConnectivityLength = -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.
/// Copies the data from the vectors, so they can be released.
VTKM_CONT_EXPORT
void FillViaCopy(const std::vector<vtkm::Id> &cellTypes,
const std::vector<vtkm::Id> &numIndices,
const std::vector<vtkm::Id> &connectivity)
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
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.Allocate( static_cast<vtkm::Id>(cellTypes.size()) );
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
std::copy(cellTypes.begin(), cellTypes.end(),
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
vtkm::cont::ArrayPortalToIteratorBegin(
this->PointToCell.Shapes.GetPortalControl()));
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.NumIndices.Allocate( static_cast<vtkm::Id>(numIndices.size()) );
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
std::copy(numIndices.begin(), numIndices.end(),
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
vtkm::cont::ArrayPortalToIteratorBegin(
this->PointToCell.NumIndices.GetPortalControl()));
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.Connectivity.Allocate( static_cast<vtkm::Id>(connectivity.size()) );
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
std::copy(connectivity.begin(), connectivity.end(),
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
vtkm::cont::ArrayPortalToIteratorBegin(
this->PointToCell.Connectivity.GetPortalControl()));
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;
this->PointToCell.IndexOffsetsValid = false;
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
void Fill(const vtkm::cont::ArrayHandle<vtkm::Id, ShapeStorageTag> &cellTypes,
const vtkm::cont::ArrayHandle<vtkm::Id, NumIndicesStorageTag> &numIndices,
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityStorageTag> &connectivity)
updating reg struct usage in cell set
2015-05-15 17:15:11 +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.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;
this->PointToCell.IndexOffsetsValid = false;
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);
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
typedef typename
ConnectivityChooser<FromTopology,ToTopology>::ConnectivityType
ContObjectType;
typedef typename ContObjectType::ShapeArrayType::template ExecutionTypes<DeviceAdapter>::PortalConst ShapePortalType;
typedef typename ContObjectType::NumIndicesArrayType::template ExecutionTypes<DeviceAdapter>::PortalConst IndicePortalType;
typedef typename ContObjectType::ConnectivityArrayType::template ExecutionTypes<DeviceAdapter>::PortalConst ConnectivityPortalType;
typedef typename ContObjectType::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
typedef vtkm::exec::ConnectivityExplicit<ShapePortalType,
IndicePortalType,
ConnectivityPortalType,
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
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
> ExecObjectType;
};
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
template<typename Device, typename FromTopology, typename ToTopology>
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
{
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
const typename
ConnectivityChooser<FromTopology,ToTopology>::ConnectivityType
&connectivity = this->GetConnectivity(FromTopology(), ToTopology());
VTKM_ASSERT_CONT(connectivity.ElementsValid);
connectivity.BuildIndexOffsets(Device());
typedef typename
ExecutionTypes<Device,FromTopology,ToTopology>::ExecObjectType
ExecObjType;
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
}
Conform DataSet classes to coding practices better The most common changes were making class members uppercase and spelled out, adding "this->" whenever a class member is used, and declare functions and members with export macros. Also fixed some uses of int (instead of vtkm::Id or something similar) and a bit of indentation. I also sprinkled some const goodness over the code. It should be noted that I had about a week delay between first making these changes and checking them in. In the mean time Sujin also made some similar changes, so there might be some repetative changes.
2015-07-12 16:05:47 +00:00
virtual void PrintSummary(std::ostream &out) const
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +00:00
{
Conform DataSet classes to coding practices better The most common changes were making class members uppercase and spelled out, adding "this->" whenever a class member is used, and declare functions and members with export macros. Also fixed some uses of int (instead of vtkm::Id or something similar) and a bit of indentation. I also sprinkled some const goodness over the code. It should be noted that I had about a week delay between first making these changes and checking them in. In the mean time Sujin also made some similar changes, so there might be some repetative changes.
2015-07-12 16:05:47 +00:00
out << " ExplicitCellSet: " << this->Name
<< " dim= " << this->Dimensionality << std::endl;
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
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
}
VTKM_CONT_EXPORT
Make all the Get methods return by const ref.
2015-08-19 14:58:40 +00:00
const vtkm::cont::ArrayHandle<vtkm::Id, ShapeStorageTag> &
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
GetShapesArray() const { return this->PointToCell.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
VTKM_CONT_EXPORT
Make all the Get methods return by const ref.
2015-08-19 14:58:40 +00:00
const vtkm::cont::ArrayHandle<vtkm::Id, NumIndicesStorageTag> &
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
GetNumIndicesArray() const { return this->PointToCell.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
VTKM_CONT_EXPORT
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectivityStorageTag> &
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
GetConnectivityArray() const { return this->PointToCell.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
VTKM_CONT_EXPORT
const vtkm::cont::ArrayHandle<vtkm::Id> &
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
GetIndexOffsetArray() const {
return this->PointToCell.IndexOffsets;
Add PrintSummary() for DataSet.
2015-05-20 19:26:10 +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
private:
typename ConnectivityChooser<
vtkm::TopologyElementTagPoint,vtkm::TopologyElementTagCell>::
ConnectivityType PointToCell;
// TODO: Actually implement CellToPoint and other connectivity. (That is,
// derive the connectivity from PointToCell.
typename ConnectivityChooser<
vtkm::TopologyElementTagCell,vtkm::TopologyElementTagPoint>::
ConnectivityType CellToPoint;
// 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_EXPORT \
const typename ConnectivityChooser< \
FromTopology,ToTopology>::ConnectivityType & \
GetConnectivity(FromTopology, ToTopology) const \
{ \
return this->Ivar; \
} \
VTKM_CONT_EXPORT \
typename ConnectivityChooser< \
FromTopology,ToTopology>::ConnectivityType & \
GetConnectivity(FromTopology, ToTopology) \
{ \
return this->Ivar; \
}
VTKM_GET_CONNECTIVITY_METHOD(vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell,
PointToCell)
VTKM_GET_CONNECTIVITY_METHOD(vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint,
CellToPoint)
#undef VTKM_GET_CONNECTIVITY_METHOD
// These are used in the AddCell and related methods to incrementally add
// cells.
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 ConnectivityLength;
vtkm::Id NumberOfCells;
adding initial cell set structures
2015-04-15 16:43:12 +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 {
template<typename Storage1, typename Storage2, typename Storage3>
struct CellSetExplicitConnectivityChooser<
vtkm::cont::CellSetExplicit<Storage1,Storage2,Storage3>,
vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>
{
typedef vtkm::cont::internal::ConnectivityExplicitInternals<
Storage1,Storage2,Storage3> ConnectivityType;
};
} // 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