When serializing fields, you have to select what underlying data types
of the field you want to support serializing. With recent changes in the
default policy, attempts to serialize a field often resulted in trying
to use the `vtkm::ListUniversal` type list, which is infinite.
Obviously, this cannot be compiled.
Instead, when the `vtkm::ListUniversal` list is encountered, use
`vtkm::TypeListAll` instead.
Previously, the policy specified which field types the filter should
operate on. The filter could remove some types, but it was not able to
add any types.
This is backward. Instead, the filter should specify what types its
supports and the policy may cull out some of those.
A new header named TypeList.h and the type lists have been redefined in
this new file. All the types have been renamed from `TypeListTag*` to
`TypeList*`. TypeListTag.h has been gutted to provide deprecated
versions of the old type list names.
There were also some other type lists that were changed from using the
old `ListTagBase` to the new `List`.
The newer List operations should still work on the old ListTags, so make
those changes first to ensure that everything still works as expected if
given an old ListTag.
Next step is to deprecate ListTagBase itself and move all the lists to
the new types.
By removing the ability to have multiple CellSets in a DataSet
we can simplify the following things:
- Cell Fields now don't require a CellSet name when being constructed
- Filters don't need to manage what the active cellset is
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.