A recent change to the DeviceAdapter header includes the TBB device if
available instead of the serial device. Thus, DeviceAdapterTagSerial was
not defined automatically in all cases for the build of
UnitTestDataSetPermutation. Add the header for that explicitly.
This now allows for even more efficient construction of uniform point
coordinates when running under the 3d scheduler, since we don't need to go
from 3d index to flat index to 3d index, instead we stay in 3d index
Previously, all Fetch objects received an Invocation object in their
Load and Store methods. The point of this was that it allowed the Fetch
to get data from any of the execution objects. However, every Fetch
either just got data directly from its associated execution object or
else used a secondary execution object (the input domain) to get indices
into their own execution object.
This left two potential areas for improvement. First, pulling data out
of the Invocation object was unnecessarily complicated. It would be much
nicer to get data directly from the associated execution object. Second,
when getting index information from the input domain, it was often the
case that extra computations were necessary (particularly on structured
cell sets). There was no way to share the index information among
Fetches, and therefore the computations were replicated.
This change removes the Invocation from the Fetch Load and Store.
Instead, it passes the associated execution object and a new object type
called the ThreadIndices. The ThreadIndices are customized for the input
domain and therefore have all the information needed for a redirected
lookup. It is also a thread-local object so it can cache computed
indices and save on computation time.
9a8809f9 Add CellSetPermutation which allows custom iteration over a cell set.
66f6db5a IsWriteableArrayHandle now can tell if an array handle can be written too
20f3fb50 Update VertexClustering to use vtkm::cont::CellSetSingleType.
154896b7 Extend the test for DataSetSingleType.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !228
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.
8bc40880 Add a test for CellSetExplicit::GetIndices
fa81d1de CellSetExplicit always calls methods using "this->"
9e496306 Allow incremental construction of CellSetSingleType.
3e307879 Mark CellSetExplicit::Fill as host side only.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !227
The testing of ArrayHandleGroupVec was just using the == operator to
check values. Even though we are not doing any math, optimizers can
sometimes make float values slightly different anyway, so test_equal
should give the correct comparison.
19cebccf Correct issues that buildbot brought up in the code.
c6dbc0f2 GetNumberOfPointsInCell consistently returns a vtkm::IdComponent
25ff1e94 CellSetExplicit storage tags are now easier to override.
935b3fd6 CellSetExplicit uses UInt8 for shape, and IdComponent for numIndices.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !210
Add new version of DynamicArrayHandle::CastToArrayHandle
This takes a reference to an array handle and fills it. This removes a lot of the pain of determining template arguments.
See merge request !205
fd685210 Always install all device headers even when device isn't enabled.
b1663b24 Add an example of using multiple backends from a single translation unit.
fc0ff69d Methods with try/catch need to be host only.
4d635d64 DeviceAdapter Tags now always exist, and contain if the device is valid.
cf32b430 Teach Configure.h to store if TBB and CUDA are enabled.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !198
Previously it was really hard to verify if a device adapter was valid. Since
you would have to check for the existence of the tag. Now the tag always
exists, but instead you query the traits of the DeviceAdapter to see if
it is a valid adapter.
This makes compiling with multiple backends alot easier.
Modify ArrayHandleCounting so that it supports both a starting value and
a step (increment). This adds a multiplication, but the common case that
does not use it is already in a separate class (ArrayHandleIndex).
adding cell-to-point topology support and worklet
This adds code to support a cell-to-point topological mapping worklet.
For explicit cell set, there is code to calculate a cell-to-point topology from the canonical point-to-cell topology. (It is not parallelized at this point.) Most of the required code for structured grids was already in place.
See merge request !154
514ac54e Add custom operator and initial value support to ExclusiveScan
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !148
These cell types are inherited from VTK, but they are basically the same
as quad and hexahedron, respectively. The only useful difference is that
pixel and voxel are supposed to be axis aligned, but you cannot
determine that by the cell shape alone (at least not just from the cell
set).
A big issue with these is that their indexing is different that of quad
and hex. The development team had a long discussion about the benefits
of the alternate indexing, but after consulting with Berk Geveci and
Will Schroder from the VTK team, that indexing is not really taken
advantage of at the cell level. Thus, it is really just a nuisance in
VTK-m.
When getting cell indices in a cell to point structured connectivity, it
was previously returning a vtkm::Vec of the maximum size and setting
invalid indices to -1. This is changed to vtkm::VecVariable, which will
reflect the actual number of indices.
I thought I made this change a while ago, but I guess I missed it.
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.
The PrintSummary for CoordinateSystem went in an infinite loop. It was
supposed to call PrintSummary of its superclass (Field), but instead it
called itself.
The PrintSummary for Field only worked for fields of type vtkm::Float32.
To make it work for all array types, I added a PrintSummary method to
DynamicArrayHandle, and Field calls that without trying to cast to a
static type.
The idea of the PointCoordinate classes was to make it easier to define
new special types of point coordinate arrays. But ultimately you have to
create an array handle type, and the CoordinateSystem class pretty much
handles everything else for you. Thus, these classes where being used
nowhere.
The point of making CoordinateSystem a special type of Field object
was so that it could handle special array types like implicit regular
point coordinates. Overload the GetData and GetBounds methods to
properly handle this type of array.
Originally, DynamicArrayHandle only automatically handled the default
type and storage lists. There was an internal subclass that expanded
that to user defined lists, but it was a bit inaccessible. This change
makes DynamicArrayHandle match the structure of DynamicCellSet. There is
now a templated base class named DynamicArrayHandleBase that can accept
any pair of lists. DynamicArrayHandle itself is really just a typedef of
DynamicArrayHandleBase with the default lists.
Previously, coordinate systems in a DataSet simply pointed to field data
specifying the coordinate information (although the ability to get that
back out of the DataSet was missing). This makes sense since point
coordinates are in fact just fields with a particular semantic meaning
to them.
However, there is an issue with this approach. It turns out that there
are special representations that are very common for point coordinates
and very uncommon for other types of fields. For example, a uniform
(a.k.a. regular or image) grid has point coordinates that are easily
derived from the point index, but such fields are quite uncommon
elsewhere.
Representing this kind of structure in the Field list of a DataSet is
problematic. Either all fields have to check to see if they are this
type, which will cause an explosion of unnecessary generated code, or
you will have to actually write out the coordinates in memory, which is
really wasteful but what was done previously.
However, by storing fields representing coordinate systems in a separate
batch, we can use these special types without the stated explosion.
