The intel compiler could not generate code in a timely manner ( 12+ hours ) when
asked to produce a cross product of very long lists. By moving to a lazy
evaluation scheme we now have all compilers product a cross product in a
reasonable amount of time ( 2-4 seconds ).
This resolves Issues:
- https://gitlab.kitware.com/vtk/vtk-m/issues/190
- https://gitlab.kitware.com/vtk/vtk/issues/17196
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.
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.
Class that need to be passed across dynamic library boundaries such as
DynamicArrayHandle need to be properly export. One of 'tricks' of this
is that templated classes such as PolymorphicArrayHandleContainer need
the Type and Storage types to have public visibility.
This makes sure that all vtkm storage tags have public visibility so
in the future we can transfer dynamic array handles across libraries.
For some reason when VTK-m was being compiled as an accelerator in VTK,
Visual Studio 2013 gave a bunch of warnings about not being able to generate
assignment operators for many classes. This happened for classes with a
const ivar that could not be automatically set. (Automatic copy constructors
are fine on this count.) I'm not sure why these warnings did not happen
when just compiling VTK-m, nor am I sure why they were generated at all as
no code actually used the copy constructors.
This commit fixes the problems by adding a private declaration for assignment
operators that cannot be automatically created. No implementation is
provided, nor should any be needed.
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.
Previously, DynamicArrayHandle and DynamicCellSet had slightly different
interfaces to their CastTo feature. It was a bit confusing and not all
that easy to use.
This change simplifies and unifies them by making each class have a single
CopyTo method that takes a reference to a cast object (an ArrayHandle or
CellSet, respectively) and fills that object with the data contained if
the cast is successfull. This interface gets around having to declare
strange types.
Each object also has a Cast method that has to have a template parameter
specified and returns a reference of that type (if possible).
In addition, the old behavior is preserved for DynamicArrayHandle (but
not DynamicCellSet). To avoid confusion, the name of that cast method is
CastToTypeStorage. However, the method was chaned to not take parameters
to make it consistent with the other Cast method.
Also, the IsType methods have been modified to reflect changes in
cast/copy. IsType now no longer takes arguments. However, an alternate
IsSameType does the same thing but does take an argument.
Previously in DynamicArrayHandle the dynamic_cast was contained in a
method that was reimplemented for every different instance of
DynamicArrayHandleBase. Change that to put the dynamic_cast in a
function outside of the class so that there is only one implementation
created per ArrayHandle type.
Similarly, DynamicCellSet had its dynamic_cast in a method plus there
was a second version in the functors used for the CastAndCall method.
Consolidate all of these into a function outside of either much like
DynamicArrayHandle.
vtkm::filter has the use case where we need to reset both the type and
storage of an array handle, by doing both at the same time we can reduce
the number of temporary objects, and invalid conversions of arrays.
The DynamicArrayHandle and DynamicCellSet classes exclusively work in
the control environment. However, CUDA likes to add __device__ to
constructors, destructors, and assignment operators it automatically
adds. This in turn causes warnings about the __device__ function using
host-only classes (like boost::shared_ptr). Solve this problem by adding
explicit methods for all of these.
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.
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.
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.
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.
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.
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.
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 is used with the FunctionInterface::DynamicTransformCont method to
convert a call of arguments using dynamic array handles to a function
templated on concrete types.
Use this mechanism in the dynamic array handle to skip over trying
invalid array handle types (and thereby incurring a compiler error even
though we never intended to use these classes).
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.
