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.
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.
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 original implementation use the naive approach of the device adapter
to copy the memory to the dynamic array handle. The issue with this approach
is that it would do a upload to device, and than a copy on device. Instead
we should prefer a copy on host, and than an upload to device.