These asserts are consolidated into the unified Assert.h. Also made some
minor edits to add asserts where appropriate and a little bit of
reconfiguring as found.
There was an inconsistency in naming classes where axes-aligned grids
with even spacing were sometimes called "uniform" and sometimes called
"regular". Maintain consistency by always calling them uniform.
f86382f0 Fix support for CoordinateSystems using ArrayHandleCartesianProduct.
d6a2a142 Add toleranced compare for values. Add tests for vtkm::Float32,Float64,Id typed arrays.
5d438353 Add toleranced comparisions for bounds validation. Also, add vtkm::Float32 and vtkm::Float64 to the testing for rectilinear and regular datasets.
b225ae97 Rectilinear coordinates (created with DataSetBuilderRectilinear) are now converted to vtkm::FloatDefault. This reduces the number of types to consider when casting inside CoordinateSystem, and was felt by all to be a reasonable restriction.
d755e43d Use ArrayHandleCompositeVector to represent separated point arrays for DataSetBuilderExplicit.h.
c7b0ffb8 Add tests for DataSetBuilderExplicit. Added cont/testing/ExplicitTestData.h which includes several explicit datasets. These datasets come from VTK data generated in VisIt. The new unit tests build datasets in several different ways and do some basic validation.
b4d04fff Add specialization of printSummary_ArrayHandle for UInt8. It prints them as characters, which are a little hard to understand to this computer scientist.
bd929c20 Fix compiler warnings.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !262
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.
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
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.
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.
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.
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.
Also found a problem with ArrayHandle that manifests itself with derived
types when you first do a PrepareForInput and then a PrepareForInPlace.
The ArrayHandle assumes the data is already moved to the device and
skips the in place call to the array transfer. However, this means the
transfer of the derived array handle does not have a chance to set up
for in place.
I think the appropriate solution may be to move the appropriate logic
from ArrayHandle to ArrayTransfer. I will look into that next.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
The Transport class is responsible for moving data from the control
environment to the execution environment. (Actually, it might be more
accurate to say it gets the execution environment associated with a
given control object.) The Transport class is templated with a tag that
controls the mechanism used for the transport.
This moves the ability to get an iterator from an array portal out of
the portal itself. The next step is to move the GetIteratorBegin/End out
of ArrayPortal. This should make the implemenation a bit cleaner.
After a talk with Robert Maynard, we decided to change the name
ArrayContainerControl to Storage. There are several reasons for this
change.
1. The name ArrayContainerControl is unwieldy. It is long, hard for
humans to parse, and makes for long lines and wraparound. It is also
hard to distinguish from other names like ArrayHandleFoo and
ArrayExecutionManager.
2. The word container is getting overloaded. For example, there is a
SimplePolymorphicContainer. Container is being used for an object that
literally acts like a container for data. This class really manages
data.
3. The data does not necessarily have to be on the control side.
Implicit containers store the data nowhere. Derivative containers might
have all the real data on the execution side. It is possible in the
future to have storage on the execution environment instead of the
control (think interfacing with a simulator on the GPU).
Storage is not a perfect word (what does implicit storage really mean?),
but its the best English word we came up with.
Each type of point coordinates has its own class with the name
PointCoordinates*. Currently there is a PointCoordiantesArray that contains
an ArrayHandle holding the point coordinates and a PointCoordinatesUniform
that takes the standard extent, origin, and spacing for a uniform rectilinear
grid and defines point coordiantes for that. Creating new PointCoordinates
arrays is pretty easy, and we will almost definitely add more. For example,
we should have an elevation version that takes uniform coordinates for
a 2D grid and then an elevation in the third dimension. We can probably
also use a basic composite point coordinates that can build them from
other coordinates.
There is also a DynamicPointCoordinates class that polymorphically stores
an instance of a PointCoordinates class. It has a CastAndCall method that
behaves like DynamicArrayHandle; it can call a functor with an array handle
(possible implicit) that holds the point coordinates.
This derived array handle creates an array of vectors whose components come
from other arrays of vectors. In either case ArrayHandleCompositeVector
handles scalars as vectors of size 1.
The dynamic array handle holds a reference to an array handle of an
unknown type. It contains the ability to try to cast it to an instance
of array handle or to try lists of types and containers.
There is currently an issue that is causing the test code not to
compile. It is the case that some combinations of types and containers
are not compatible. For example, an implict container is bound to a
certain type, and the container is undefined if they do not agree. There
needs to be a mechanism to detect these invalid combinations and skip
over them in the MTP for each.
Provies a list of types in a template like boost::mpl::vector and a
method to call a functor on each type. However, rather than explicitly
list each type, uses tags to identify the list. This provides the
following main advantages:
1. Can use these type lists without creating horrendously long class
names based on them, making compiler errors easier to read. For example,
you would have a typename like MyClass<TypeListTagVectors> instead of
MyClass<TypeList<Id3,Vector2,Vector3,Vector4> > (or worse if variadic
templates are not supported). This is the main motivation for this
implementation.
2. Do not require variadic templates and usually few constructions. That
should speed compile times.
There is one main disadvantage to this approach: It is difficult to get
a printed list of items in a list during an error. If necessary, it
probably would not be too hard to make a template to convert a tag to a
boost mpl vector.
