vtk-m/vtkm/cont/CellSetExtrude.h

242 lines
8.1 KiB
C
Raw Normal View History

2019-06-21 15:35:46 +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.
//============================================================================
#ifndef vtk_m_cont_CellSetExtrude_h
#define vtk_m_cont_CellSetExtrude_h
#include <vtkm/TopologyElementTag.h>
#include <vtkm/cont/ArrayHandle.h>
#include <vtkm/cont/ArrayHandleCounting.h>
2020-12-08 19:38:33 +00:00
#include <vtkm/cont/ArrayHandleXGCCoordinates.h>
#include <vtkm/cont/CellSet.h>
#include <vtkm/cont/Invoker.h>
#include <vtkm/exec/ConnectivityExtrude.h>
#include <vtkm/exec/arg/ThreadIndicesExtrude.h>
namespace vtkm
{
namespace cont
{
namespace detail
{
template <typename VisitTopology, typename IncidentTopology>
struct CellSetExtrudeConnectivityChooser;
template <>
struct CellSetExtrudeConnectivityChooser<vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint>
{
using ExecConnectivityType = vtkm::exec::ConnectivityExtrude;
};
template <>
struct CellSetExtrudeConnectivityChooser<vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell>
{
using ExecConnectivityType = vtkm::exec::ReverseConnectivityExtrude;
};
} // namespace detail
2019-06-22 00:51:44 +00:00
class VTKM_CONT_EXPORT CellSetExtrude : public CellSet
{
public:
2019-08-13 21:28:37 +00:00
VTKM_CONT CellSetExtrude();
2019-06-22 00:51:44 +00:00
VTKM_CONT CellSetExtrude(const vtkm::cont::ArrayHandle<vtkm::Int32>& conn,
vtkm::Int32 numberOfPointsPerPlane,
vtkm::Int32 numberOfPlanes,
const vtkm::cont::ArrayHandle<vtkm::Int32>& nextNode,
2019-08-13 21:28:37 +00:00
bool periodic);
VTKM_CONT CellSetExtrude(const CellSetExtrude& src);
VTKM_CONT CellSetExtrude(CellSetExtrude&& src) noexcept;
VTKM_CONT CellSetExtrude& operator=(const CellSetExtrude& src);
VTKM_CONT CellSetExtrude& operator=(CellSetExtrude&& src) noexcept;
virtual ~CellSetExtrude() override;
vtkm::Int32 GetNumberOfPlanes() const;
vtkm::Id GetNumberOfCells() const override;
vtkm::Id GetNumberOfPoints() const override;
vtkm::Id GetNumberOfFaces() const override;
vtkm::Id GetNumberOfEdges() const override;
2019-06-22 00:51:44 +00:00
VTKM_CONT vtkm::Id2 GetSchedulingRange(vtkm::TopologyElementTagCell) const;
2019-06-22 00:51:44 +00:00
VTKM_CONT vtkm::Id2 GetSchedulingRange(vtkm::TopologyElementTagPoint) const;
vtkm::UInt8 GetCellShape(vtkm::Id id) const override;
vtkm::IdComponent GetNumberOfPointsInCell(vtkm::Id id) const override;
void GetCellPointIds(vtkm::Id id, vtkm::Id* ptids) const override;
std::shared_ptr<CellSet> NewInstance() const override;
void DeepCopy(const CellSet* src) override;
void PrintSummary(std::ostream& out) const override;
void ReleaseResourcesExecution() override;
const vtkm::cont::ArrayHandle<vtkm::Int32>& GetConnectivityArray() const
{
return this->Connectivity;
}
vtkm::Int32 GetNumberOfPointsPerPlane() const { return this->NumberOfPointsPerPlane; }
const vtkm::cont::ArrayHandle<vtkm::Int32>& GetNextNodeArray() const { return this->NextNode; }
bool GetIsPeriodic() const { return this->IsPeriodic; }
2021-03-12 19:40:27 +00:00
template <vtkm::IdComponent NumIndices>
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::Vec<vtkm::Id, NumIndices>& ids) const;
VTKM_CONT void GetIndices(vtkm::Id index, vtkm::cont::ArrayHandle<vtkm::Id>& ids) const;
template <typename VisitTopology, typename IncidentTopology>
using ExecConnectivityType =
typename detail::CellSetExtrudeConnectivityChooser<VisitTopology,
IncidentTopology>::ExecConnectivityType;
vtkm::exec::ConnectivityExtrude PrepareForInput(vtkm::cont::DeviceAdapterId,
vtkm::TopologyElementTagCell,
vtkm::TopologyElementTagPoint,
vtkm::cont::Token&) const;
vtkm::exec::ReverseConnectivityExtrude PrepareForInput(vtkm::cont::DeviceAdapterId,
vtkm::TopologyElementTagPoint,
vtkm::TopologyElementTagCell,
vtkm::cont::Token&) const;
private:
void BuildReverseConnectivity();
bool IsPeriodic;
vtkm::Int32 NumberOfPointsPerPlane;
vtkm::Int32 NumberOfCellsPerPlane;
vtkm::Int32 NumberOfPlanes;
vtkm::cont::ArrayHandle<vtkm::Int32> Connectivity;
vtkm::cont::ArrayHandle<vtkm::Int32> NextNode;
bool ReverseConnectivityBuilt;
vtkm::cont::ArrayHandle<vtkm::Int32> RConnectivity;
vtkm::cont::ArrayHandle<vtkm::Int32> ROffsets;
vtkm::cont::ArrayHandle<vtkm::Int32> RCounts;
vtkm::cont::ArrayHandle<vtkm::Int32> PrevNode;
};
template <typename T>
CellSetExtrude make_CellSetExtrude(const vtkm::cont::ArrayHandle<vtkm::Int32>& conn,
2020-12-08 19:38:33 +00:00
const vtkm::cont::ArrayHandleXGCCoordinates<T>& coords,
const vtkm::cont::ArrayHandle<vtkm::Int32>& nextNode,
2019-08-13 21:28:37 +00:00
bool periodic = true)
{
return CellSetExtrude{
2019-08-13 21:28:37 +00:00
conn, coords.GetNumberOfPointsPerPlane(), coords.GetNumberOfPlanes(), nextNode, periodic
};
}
template <typename T>
CellSetExtrude make_CellSetExtrude(const std::vector<vtkm::Int32>& conn,
2020-12-08 19:38:33 +00:00
const vtkm::cont::ArrayHandleXGCCoordinates<T>& coords,
const std::vector<vtkm::Int32>& nextNode,
2019-08-13 21:28:37 +00:00
bool periodic = true)
{
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
return CellSetExtrude{ vtkm::cont::make_ArrayHandle(conn, vtkm::CopyFlag::On),
2019-06-25 02:10:32 +00:00
static_cast<vtkm::Int32>(coords.GetNumberOfPointsPerPlane()),
2020-12-08 19:38:33 +00:00
static_cast<vtkm::Int32>(coords.GetNumberOfPlanes()),
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
vtkm::cont::make_ArrayHandle(nextNode, vtkm::CopyFlag::On),
periodic };
}
template <typename T>
CellSetExtrude make_CellSetExtrude(std::vector<vtkm::Int32>&& conn,
2020-12-08 19:38:33 +00:00
const vtkm::cont::ArrayHandleXGCCoordinates<T>& coords,
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
std::vector<vtkm::Int32>&& nextNode,
bool periodic = true)
{
return CellSetExtrude{ vtkm::cont::make_ArrayHandleMove(std::move(conn)),
static_cast<vtkm::Int32>(coords.GetNumberOfPointsPerPlane()),
2020-12-08 19:38:33 +00:00
static_cast<vtkm::Int32>(coords.GetNumberOfPlanes()),
Improvements to moving data into ArrayHandle We have made several improvements to adding data into an `ArrayHandle`. ## Moving data from an `std::vector` For numerous reasons, it is convenient to define data in a `std::vector` and then wrap that into an `ArrayHandle`. It is often the case that an `std::vector` is filled and then becomes unused once it is converted to an `ArrayHandle`. In this case, what we really want is to pass the data off to the `ArrayHandle` so that the `ArrayHandle` is now managing the data and not the `std::vector`. C++11 has a mechanism to do this: move semantics. You can now pass variables to functions as an "rvalue" (right-hand value). When something is passed as an rvalue, it can pull state out of that variable and move it somewhere else. `std::vector` implements this movement so that an rvalue can be moved to another `std::vector` without actually copying the data. `make_ArrayHandle` now also takes advantage of this feature to move rvalue `std::vector`s. There is a special form of `make_ArrayHandle` named `make_ArrayHandleMove` that takes an rvalue. There is also a special overload of `make_ArrayHandle` itself that handles an rvalue `vector`. (However, using the explicit move version is better if you want to make sure the data is actually moved.) ## Make `ArrayHandle` from initalizer list A common use case for using `std::vector` (particularly in our unit tests) is to quickly add an initalizer list into an `ArrayHandle`. Now you can by simply passing an initializer list to `make_ArrayHandle`. ## Deprecated `make_ArrayHandle` with default shallow copy For historical reasons, passing an `std::vector` or a pointer to `make_ArrayHandle` does a shallow copy (i.e. `CopyFlag` defaults to `Off`). Although more efficient, this mode is inherintly unsafe, and making it the default is asking for trouble. To combat this, calling `make_ArrayHandle` without a copy flag is deprecated. In this way, if you wish to do the faster but more unsafe creation of an `ArrayHandle` you should explicitly express that. This requried quite a few changes through the VTK-m source (particularly in the tests). ## Similar changes to `Field` `vtkm::cont::Field` has a `make_Field` helper function that is similar to `make_ArrayHandle`. It also features the ability to create fields from `std::vector`s and C arrays. It also likewise had the same unsafe behavior by default of not copying from the source of the arrays. That behavior has similarly been depreciated. You now have to specify a copy flag. The ability to construct a `Field` from an initializer list of values has also been added.
2020-07-16 16:32:32 +00:00
vtkm::cont::make_ArrayHandleMove(std::move(nextNode)),
2019-08-13 21:28:37 +00:00
periodic };
}
}
} // vtkm::cont
//=============================================================================
// Specializations of serialization related classes
/// @cond SERIALIZATION
namespace vtkm
{
namespace cont
{
template <>
struct SerializableTypeString<vtkm::cont::CellSetExtrude>
{
static VTKM_CONT const std::string& Get()
{
static std::string name = "CS_Extrude";
return name;
}
};
}
} // vtkm::cont
namespace mangled_diy_namespace
{
template <>
struct Serialization<vtkm::cont::CellSetExtrude>
{
private:
using Type = vtkm::cont::CellSetExtrude;
public:
static VTKM_CONT void save(BinaryBuffer& bb, const Type& cs)
{
vtkmdiy::save(bb, cs.GetNumberOfPointsPerPlane());
vtkmdiy::save(bb, cs.GetNumberOfPlanes());
vtkmdiy::save(bb, cs.GetIsPeriodic());
vtkmdiy::save(bb, cs.GetConnectivityArray());
vtkmdiy::save(bb, cs.GetNextNodeArray());
}
static VTKM_CONT void load(BinaryBuffer& bb, Type& cs)
{
vtkm::Int32 numberOfPointsPerPlane;
vtkm::Int32 numberOfPlanes;
bool isPeriodic;
vtkm::cont::ArrayHandle<vtkm::Int32> conn;
vtkm::cont::ArrayHandle<vtkm::Int32> nextNode;
vtkmdiy::load(bb, numberOfPointsPerPlane);
vtkmdiy::load(bb, numberOfPlanes);
vtkmdiy::load(bb, isPeriodic);
vtkmdiy::load(bb, conn);
vtkmdiy::load(bb, nextNode);
2019-08-13 21:28:37 +00:00
cs = Type{ conn, numberOfPointsPerPlane, numberOfPlanes, nextNode, isPeriodic };
}
};
} // diy
/// @endcond SERIALIZATION
#endif // vtk_m_cont_CellSetExtrude.h