There are several switch statements in ParametricCoordinates.h that have
a default clause that is an error condition. The code was simply calling
the RaiseError method on the worklet before quiting. Although the
behavior is supposed to be similar to throwing an exception, flow
actually does still continue. These error default clauses kept going
without breaking from the switch or initializing the variables the
method is supposed to set. Although the values should not matter once
the error is raised, I was getting compiler warnings about it. It's also
bad practice as certain NaN values can cause the program to signal out,
so it is best to set the data to something.
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.
The original way was overconstrained with respect to the number of
parametric coordinates.
Also implemented WorldCoordinatesToParametricCoordinates for polygons.
The general polygon version is not implemented yet because I need to
change the way it is interpolated.
To get wedge to work correctly, I had to change the interpolation
slightly there. Previously the interpolation had a singularity at
the tip.
The functions for doing interpolations and derivatives were called
CellInterpolate and CellDerivative, but the file names were
Interpolate.h and Derivative. Now the files are CellInterpolate.h and
CellDerivative.h so they are more consistent and a bit easier to find.
The interpolate and derivative functions has the shape tag at end of the
function arguments (just before the "worklet" parameter, which is just
the error handling mechanism). However, the parametric coordinate
functions had the shape tag at the beginning. Moved the shape tag to the
end to be more consistent within these functions and also in other uses
throughtout VTK-m.
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 constructor for execution whole array was wrong and would result in compilation error if used. This fixes that and adds a test path for testing ExecutionWholeArray with ExecutionWholeArrayConst.
Variable topology fields
Changes to fetching in topology maps that lets you properly deal with cases where you do not know how many values are being fetched at compile time. For example, explicit cell sets can have any number of cell shapes that have different numbers of nodes.
This change should resolve issue #26.
See merge request !128
Workaround thrust 1.8 inclusive scan issue.
Starting in thrust 1.8 the implementation of scan inclusive inside
thrust became highly optimized by using parallel task groups. This
new implementation has a bug that only exists when using custom
binary operators, large size arrays, release mode, and no
debugger or mem-checker attached.
While I have submitted the issue to thrust, we need to be able
to work around the existing issue. The solution I have chosen is
to mark all vtkm::exec::cuda::interal::WrappedBinaryOperators
as being commutative as far as thrust is concerened. To make
sure we don't get any unexpected behavior I have also had
to create WrappedBinaryPredicate so that we don't mark any
predicate as commutative.
See merge request !129
Starting in thrust 1.8 the implementation of scan inclusive inside
thrust became highly optimized by using parallel task groups. This
new implementation has a bug that only exists when using custom
binary operators, large size arrays, release mode, and no
debugger or mem-checker attached.
While I have submitted the issue to thrust, we need to be able
to work around the existing issue. The solution I have chosen is
to mark all vtkm::exec::cuda::interal::WrappedBinaryOperators
as being commutative as far as thrust is concerened. To make
sure we don't get any unexpected behavior I have also had
to create WrappedBinaryPredicate so that we don't mark any
predicate as commutative.
BOOST_MPL_ASSERT is causing warnings in the PGI compiler. Apparently,
when BOOST_MPL_ASSERT succeeds it declares a static object with a unqiue
name scoped to the file. The problem is that the PGI compiler is pretty
picky about things being declared without being used, so it was emitting
useless warnings about successful BOOST_MPL_ASSERTs. However,
BOOST_STATIC_ASSERT does not seem to have this problem, so for the benefit
of PGI change the compile-time assert method.
The PGI compiler is fussy about finding declared variables and methods
that have limited scope and are never used. Thus, it is complaining about
some internal test classes that are properly implementing the ArrayPortal
interface even though not all of it is being accessed.
To get around the problem, put them in a non-anonymous namespace with a
name unlikely to conflict with anything. The compiler will recognize that
it is possible to access these classes outside the scope of the file and
shut up about items not being used.
This class was used to store a group of from field data in a topology
map. However, the fetching has been changed to use a customized class
for each type of fetch that can be optimized for the fetch type and does
not require to know the number of items in the fetch at compile time.
Thus, this class is no longer needed, so it is being removed.
This change removes the requirement to specify some maximum cell length
in each of the worklets, which is basically impossible. It also makes
some of the loading more lazy, which might help reduce the number of
registers required in a worklet.
Previously when you fetched the indices from an explicit cell set, you
would get back a Vec of a fixed length an expected to use a subset of
it. Now you get back a Vec-like object that reports the exact length.
This Vec-like is implemented with VecFromPortal, so that the data does
not need to be copied to the stack. Rather, it is pulled from memory as
requested.
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.
Previously, all arrays passed to worklets were designated as either
input or output. No in-place operation was permitted. This change adds
the FieldInOut tag for ControlSignature in both WorkletMapField and
WorkletMapTopology that allows you to read and write from the same
array.
(Re-) Add a helper structure that holds the connectivity information for
a particular topology connection (e.g. from points to cells) to make it
easier to manage connections in multiple different directions in
CellSetExplicit.
Unlike the previous version of connectivity, this structure is
considered "internal" and not exposed through the API so that
CellSetExplicit can better manage the data. Also, many of the helper
methods remain in CellSetExplicit since they were specific for point-to-
Also, CellSetExplicit has a mechanism to take an arbitrary pair of
TopologyElementTags and get the appropriate connectivity. This should
simplify adding connections in the future.
In the CellSet and related classes, a connection was referred to by a
"from" topology element and a "to" topology element. However, in the
worklet control signature tags the elements were referred to by "src"
and "dest." To make things consistent, use "from" and "to" everywhere.
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.
C and C++ has a funny feature where operations on small integers (char
and short) actually promote the result to a 32 bit integer. Most often
in our code the result is pushed back to the same type, and picky compilers
can then give a warning about an implicit type conversion (that we
inevitably don't care about). Here are a lot of changes to suppress
the warnings.
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.
Some fixes to VertexClustering
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
See merge request !64
VertexClustering previously only worked with data of a specific floating
point type (32 bit for point coordinates). Add some templates to accept
either 32 bit or 64 bit floating points for point coordintes and be a
bit more careful about implicit type conversions.
I also made some changes to conform better with the VTK-m coding
standards. The most common changes are using 2 space indentation for all
block levels, capitolizing and using camel case for all class members,
and prefixing "this->" to all use of internal class members.
This is built ontop of the ExecutionObjectBase work, and is designed to show
other developers how they can create custom objects that are shared among
all worklets, but are passed as parameters to the worklet.
By mistake the cuda texture memory load code was not being used, so correct
that issue and allow loading of vtkm::Vec and primitive types. Currently
the only issue is loading int8/int16 uint8/uint16 through texture memory.
