We want to be able to get topological connections where it is difficult
to know how many values you get each time. In this change, the type of
the vector holding the from indices is determined from the connectivity
object, and the worklet does not know the type (it must be templated).
Although you do not need to specify the max number for this value set
(you still currently do for field values), we still need to change the
type for explicit sets that uses something that does not rely on the Vec
class. The cell-to-point method also needs a Vec wrapper that allows it
to shorten the vector dynamically.
Clean up CellSet
Underneath the CellSet implementation is a set of supporting classes that manage the actual structure in both the control and execution environments. However, the implementation of these classes was a bit confusing and inconsistent. The following changes are made:
* Most significantly, there is no longer any Connectivity classes in the control environment. This functionality has been wrapped up into the CellSet classes, which is more consistent and easier to understand. (There was a definite distinction between CellSet and Connectivity, but it was subtle and difficult to understand.) This also means that edits to CellSets happen to CellSets directly.
* The set of classes for structured and explicit cell sets match. There is different functionality within, but the class naming and meaning are consistent.
* Make the class names more consistent with the rest of VTK-m class names. Specifically classes like ExplicitConnectivity become ConnectivityExplicit. Also, the words regular and structured were being used interchangeably. Now, always use structured except when dealing specifically with grids of regular spacing.
* The connectivity classes were using the nomenclature "From" and "To" to specify topological elements of links. The same concept in worklet classes were using the nomenclature "Src" and "Dest." For consistency, all references are changed to "From" and "To".
* Unlike explicit cell sets, structured cell sets have functionality shared between control and execution environments. Rather than duplicate it or create unique exposed classes, have a shared internal implementation in vtkm::internal.
See merge request !117
The storage used will now be aligned to `VTKM_CACHE_LINE_SIZE bytes,
resulting in slightly better cache usage and load/store performance.
This define is set in `StorageBasic.h We also now detect if Posix is
available in Configure.h and will define VTKM_POSIX with _POSIX_VERSION
if it's available.
The AlignedAllocator used by StorageBasic is also STL compatible
and can be used in STL containers so user's can use it in their
std::vector and pass aligned user memory to the storage.
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.
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.
Also moved from vtkm namespace to vtkm::internal namespace. This change
is to then move the structured connectivity classes to the cont and exec
namespaces.
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.
C and C++ has a funny feature where operations on small integers (char
and short) actually promote the result to a 32 bit integer. Most often
in our code the result is pushed back to the same type, and picky compilers
can then give a warning about an implicit type conversion (that we
inevitably don't care about). Here are a lot of changes to suppress
the warnings.
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.)
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.
MSVC ArrayHandle fail
Fix the fact that UnitTestArrayHandle is failing on the Windows dashboards. Also fix some of the MSVC warnings.
See merge request !101
The test was creating a large array on the stack, and this caused a
problem on Windows for some reason. Instead of putting the array on
the stack, use an std::vector. Also reduced the size of the array
used. It seemed unnecessarily large.
Also re-enabled the tests where VTK-m allocates its own ArrayHandle
data.
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.
The CMake flag and define differ in their capitalization of the 'm' in
VTKm so I've made CMake variables that match those used in Configure.h.in,
thereby keeping the original naming of VTKm in CMake code, and VTKM in the
C++ code.
This fix also revealed some areas in CellSet and CellSetExplicit where ints
where used instead of vtkm::Ids which caused errors with child classes who
override the methods and returned a vtkm::Id instead of an int.
Also fixed issues that appeared in TestOutOfMemory which got out of date due
to not being compiled since the `VTKM_USE_64BIT_IDS` flag would never be set.
The test now runs and passes when 64bit ids are enabled.
Add data size introspection to DynamicArrayHandle.
Sometimes it is useful to know how big an array held in a
DynamicArrayHandle is. This adds two methods to DynamicArrayHandle:
GetNumberOfValues and GetNumberOfComponents. They allow you to query the
size of the array without having to statically cast to the array itself.
See merge request !76
Sometimes it is useful to know how big an array held in a
DynamicArrayHandle is. This adds two methods to DynamicArrayHandle:
GetNumberOfValues and GetNumberOfComponents. They allow you to query the
size of the array without having to statically cast to the array itself.
Specifically a conversion operator was not being used in the StringInt
class of UnitTestArrayHandleCounting. Because it was in an anonymous
namespace that could not be used outside of the file, ICC warned about
it. Rather than remove the method, which could cause confusion later,
gave the namespace a name so the compiler assumes that the class could
potentially be used somewhere else.
The previous implementation assumed the identity value to be zero, which does
not work for multiplication. Changed the interface to require an initial value
for Exclusive Scan with custom operator (TBB Device only, for now).
We have increased the ARRAY_SIZE for the TestingDeviceAdapter to work
around issues with backends not using parallel algorithms for arrays of length
500 or less.
The driving desire for this change was to make vtk-m ArrayHandle behave more
like the standard vector. The canonical example of what we want to support is:
```
std::vector<vtkm::Id> values;
values.resize(100);
vtkm::cont::ArrayHandle<vtkm::Id> array = vtkm::cont::make_ArrayHandle(values);
vtkm::cont::DeviceAdapterAlgorithm<DeviceAdapter>::Sort(array);
```
And with-out the ability to modify user provided memory, this was impossible.
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.
ExplicitConnectivity 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.
THe IncrementBy2 test type previously allowed any subtype including
floating point numbers. The meaning of this is actually a little unclear
and the feature was causing implicit type conversion warnings that were
hard to template out. The utility of of templating this class is dubious
in the first place, so class is now a fixed type.
I'm a little unsure whether we should keep this test class at all. It's
math operations are ad hoc and it could be difficult to determine if a
problem is caused by an actual problem or just bad math operators.
Fix compile warnings that come up with the flags
-Wconversion -Wno-sign-conversion
This catches several instances (mostly in the testing framework) where
types are implicitly converted. I expect these changes to fix some of
the warnings we are seeing in MSVC.
I was going to add these flags to the list of extra warning flags, but
unfortunately the Thrust library has several warnings of these types,
and I don't know a good way to turn on the warnings for our code but
turn them off for Thrust.
The UnitTestArrayHandlePermutation test was failing when compiled with
icc. I believe the issue is that the icc optimization takes some
liberties when computing literal floating point values versus computing
them at run time that makes the two slightly different. I changed all
the applicable comparisons in this test from using the == operator to
using the test_equal function, which adds a tolerance to the comparison.
I expect this to fix the test failure.
Previously ArrayTransfer and ArrayManagerExecution received a reference
to a Storage class in their constructor and held the reference as an
ivar. In retrospect, this is just asking for trouble. First, it is way
too easy to pass by value when you mean to pass by reference. Second, if
there ever is a bug where the Storage goes out of scope before the
classes holding a reference, it is that much harder to debug.
This includes changing methods like LoadDataForInput to PrepareForInput.
It also changed the interface a bit to save a reference to the storage
object. (Maybe it would be better to save a pointer?) These changes also
extend up to the ArrayManagerExecution class, so it can effect device
adapter implementations.
This API change effects both ArrayTransfer and ArrayManagerExecution.
This is in preparation for a future change to make the API more
consistent with ArrayHandle.
The UserPortal in ArrayHandle was used to copy a pointer the user
created into an ArrayHandle to use in VTK-m algorithms. However, this is
only really valid for a basic storage, so the functionality has been
moved there, and you have to construct an ArrayHandle with a storage
instead of an array portal.
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.
The number of values in the array handle portal was screwy and the
GetNumberOfValues method was flat out wrong (thanks to Rob Maynard for
pointing that out). This is fixed.
Also fixed a subtle but nasty typing problem in the Storage's
GetPortalConst method.
Add an Allocate method in ArrayHandle that basically forwards the
alllocate request to the storage object. This allows some measure of
control of the array from the control side. You can allocate the array
and set values (by getting the control array portal) if you so desire.
Fixed a problem where ArrayHandle would cause a crash if you tried to
get the control portal on an uninitialized array (it was supposed to
throw an exception).
Also changed some methods in ArrayHandle so that they work resonably
without error when used with an uninitialized array. Specifically, the
aforementioned behavior was changed to "allocate" an array of size 0
(that is, call Allocate(0) on the storage object) to return an empty
array portal rather than throw an error. Although this use of
ArrayHandle can be considered erroneous, it is convenient the get an
empty array portal when dealing with a potentially unallocated array
rather than create a special condition.
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 unit test for StorageBasic tested the StealArray feature and then
used the delete[] operator on the stolen array to deallocate it. For
many standard libraries the default implementation for delete[] is
the same as (or at least compatible with) std::allocator, but for
the PGI compiler they were not compatible and this resulted in a
run-time error. This change fixes the problem with the test by using
the same allocator as the StorageBasic test.
Lots of tests have to move values in and out of arrays and check them
against expected values. It is also often the case that these tests are
run on lots of different types. There is some repeated code for
generating known values for particular indices. This change unifies some
of that. This can probably also encourage making more generic tests.
Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
Since we want our code to generally handle data of different precision
(for example either float or double) expand the types in our list types
to include multiple precision.
Previously we just hand coded base lists up to 4 entries, which was fine
for what we were using it for. However, now that we want to support base
types of different sizes, we are going to need much longer lists.
There are multiple reasons for this name change:
* The name Tuple conflicts with the boost::Tuple class, which as a
different interface and feature set. This gets confusing, especially
since VTK-m uses boost quite a bit.
* The use of this class is usually (although not always) as a
mathematical vector.
* The vtkm::Scalar and vtkm::Vector* classes are going to go away soon
to better support multiple base data type widths. Having this
abbriviated name will hopefully make the code a bit nicer when these
types have to be explicitly specified.
Also modified the implementation a bit to consolidate some of the code.
In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).
Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
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.
MSVC likes to warn about using raw pointers as iterators in generic
algorithms because they have been known to lead to problems. When
compiling with that compiler, wrap raw pointers in
stdext::checked_array_pointer to suppress the error and also add a bit
more checking.
I wanted to test ArrayHandleCounting with some non-standard data type.
I was using a class that looked like a number that counts by two, but
the operator behavior was not a proper group and that was causing issues.
Replaced that with a class that inefficiently represents an unsigned
integer as a string with that many characters. The inefficiency does not
matter because it is just a test.
It appears that when the Intel compiler is optimizing, constant floating
point values can be slightly different than the same value stored in memory
and never changed. This change uses the test_equal method to compare
these floating point values that might have a slight numeric error.
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.
It was originally put there to support CopyInto in ArrayHandle, but that
has already been removed. It really only makes sense for trivial
examples and testing code, and it sometimes causes complications with
coding.
There is a special version of the testing methods for use in the control
environment that handles execeptions that can be thrown there. There are
tests to make sure you are using the correct version of the testing
framework, but it was broken until the last commit. Now that it's fixed,
here are two places where the wrong testing method was used.
We made this change a while ago to help with completion in IDEs.
(Completion was matching a bunch of wrapper macros that were almost
never used anywhere.) Most of the changes are in comments, but there are
a few bad macro definitions.
Getting the type right for ArrayHandleCompositeVector can be a bit
tricky. It is expressed in a somewhat strange function signature format
and you have to extract the right component type for the return. This
adds an ArrayHandleCompositeVectorType that makes it easier (although no
less verbose).
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.
