1. Add option to copy user supplied array in make_ArrayHandle.
2. Replace Field constructors that take user supplied arrays with make_Field.
3. Replace CoordinateSystem constructors that take user supplied arrays with
make_CoordinateSystem.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
Following what was done with ArrayRangeCompute, the GetRange and
GetBounds methods are embedded into the vtkm_cont library for the most
common type lists.
Also, and probably more importantly, the device adapter is no longer one
of the arguments for either of these methods. It is no longer needed as
ArrayRangeCompute no longer needs it.
Most uses of ArrayRangeCompute just want to get the range of the data
and probably don't have a particular device in mind. Thus, it is better
to use a TryExecute internally use whatever devices are available.
Note that when using TryExecute, the calling code is expected to be able
to support all devices. That might not always be the case. Thus, I am
experimenting a bit with how we incorporate this in a library. The
advantage of having the code compiled in a library is that you only have
to compile it once and the calling code does not need to worry about
CUDA, etc.
However, because ArrayRangeCompute is templated, we can only pre-compile
some subset of array handle types. The most common are compiled into the
code (matching all the predefined ArrayHandles as well as some special
cases). If the code wants to use some other type, it has to include
ArrayRangeCompute.hxx. The only place where this is necessary is a test
that intentially trys to find the range on an uncommon type.
If array portals were to support virtual methods, then we should be able
to modify this code so that we could precompile for all array handle
types.
This reduces the number of weak vtables vtkm generates, resulting in
a reduction of binary sizes for projects that include vtkm classes in
multiple translation units.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
First, be more explicit when we mean a range of values in a field or a
spacial bounds. Use the Range and Bounds structs in Field and
CoordinateSystem to make all of this more clear (and reduce a bit of
code as well).
The previous version of the bounds code required once less pass across
the data, but significantly increase the size of the resulting library:
Data for VTK-VTK-m interop:
- 7k more symbol table entries
- 1.5MB larger library
Because of the significant savings we need to use a less efficient
implementation that minimized the code size.
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.
I ran into a few minor issues with the constructors to the Field class.
The big change I made was that I removed the Field constructors that
take an example type and create an empty field of that type. The problem
was that the example type was easily confused with some other type that
was supposed to describe an array. This lead to some odd behavior in the
compiler and resulted in errors in unexpected places.
The use case for this constructor is dubious. There were several tests
in the code that would create an empty field, add it to a data set, then
get it back out to pass to the worklet. The code is much simpler if you
just make an ArrayHandle of the right type and use that in the worklet
invoke directly. It is also faster to compile with smaller code because
the type is known statically (whereas it is lost the other way).
The other change was to declare references to ArrayHandle and
DynamicArrayHandle as const. There is nothing in the behavior that
invalidates the const, and it accepts arrays constructed in the
parameter.
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 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.
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.
