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
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.
Previously, when you requested a CellShape in the ExecutionSignature,
you just got an ID stored in a vtkm::IdComponent. This change returns a
cell shape tag of the appropriate type (or generic if the type is not
known at compile time). This will allow functions called from the
worklet to specialize on the cell type better.
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.
Move ArrayPortalUniformPointCoordinates to the vtkm::internal namespace
since it is going to be actively used in both control and execution
environments.
Replace usage of extent with simple dimensions. We have decided that
there is not a lot of value in supporting extent in VTK-m.
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.
One of the dashboards gave yet another warning in the boost random
library. This time the warning is on unused parameters. Go ahead and add
that to the list of things to not check in boost.
The renar dashboard gave some warnings about shadowed variables in the
boost random library (version 1.57.0). This might be a bug in boost that
is already fixed (I didn't get the same warning on my gcc compile with
boost 1.58.0), but I don't see a problem with disabling the shadow
warning everywhere in boost.
On one of my compile platforms, GCC was giving conversion warnings from
any boost include that was not wrapped in pragmas to disable conversion
warnings. To make things easier and more robust, I created a pair of
macros, VTKM_BOOST_PRE_INCLUDE and VTKM_BOOST_POST_INCLUDE, that should
be wrapped around any #include of a boost header file.
Using enable_if/disable_if as a return type has a negative impact on
binary size compared to use a boost::true/false_type as a method parameter.
For comparison the WorkletTests_TBB sees a 6-7% reduction in binary size when
compiled with O3.
Origin WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2363392 49152 0 4297793536 4300206080 1004ff000
Updated WorkletTests_TBB size details:
__TEXT __DATA __OBJC others dec hex
2215936 49152 0 4297568256 4299833344 1004a4000
They were declared as in both control and execution, but this would
cause problems when the FunctionInterface contained objects that could
only be copied in the control environment. Using these methods probably
only makes sense in the control environment anyway. (They are a bit
heavyweight to use in an inner loop of the execution environment.)
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
The Zip function does not work when compiling with CUDA because it
forces the parameters to be in both the control and execution (host and
device) environments.
When fixing a problem where the disabled test had left some unused
classes, which some compilers picked up on (SHA
eae8921dc714c9bdb12058db365f890425291ea2), I used a preprocessor wrapper
to enable/disable the code (mostly to preserve history). However, I
forgot to leave the code disabled. Disable that here.
A couple of tests were failing with the Intel compiler due to
imprecision in comparing floating point values.
Also snuck in some minor documentation fixes in a comment for
FunctionInterface.
There is a test that tries to determine that the Invoke methods in
FunctionInterface do not add an unreasonable overhead. However, this
test is unreliable. Also, the most critical performance hit would be in
invoking a worklet operation, but that is now done elsewhere anyway.
Also reduced the maximum list size to 15 (which is the current longest
single list we have). Trying to reduce the size of the generated code a
bit, which is getting a little long.
