The names of the cell shapes and header files changed superficially. The
check in missed the clip and external faces. Update that code.
There are also some less superficial changes that allow you to manage
cell shapes with tags. It might be worthwhile to update this code to use
that new infrastructure.
514ac54e Add custom operator and initial value support to ExclusiveScan
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !148
Add external faces
A working implementation of the External Faces algorithm, along with a unit test to verify correctness on a simple mesh of tetrahedron cells.
See merge request !131
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.
When getting cell indices in a cell to point structured connectivity, it
was previously returning a vtkm::Vec of the maximum size and setting
invalid indices to -1. This is changed to vtkm::VecVariable, which will
reflect the actual number of indices.
I thought I made this change a while ago, but I guess I missed it.
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 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.
Suppress deprecation warnings about glut as we investigate our options.
Starting in OSX 10.9, apple has deprecated the glut.h provided header
so we need to figure out how we want to do window management on OSX. I expect
the way forward is to require the developer to install openGLUT.
See merge request !142
Starting in OSX 10.9, apple has deprecated the glut.h provided header
so we need to figure out how we want to do window management on OSX. I expect
the way forward is to require the developer to install openGLUT.
templating topology worklet to support mappings other than point-to-cell
This adds a FromTopology and ToTopology template type to the topology worklet, removing hard-coded types.
This is a precursor step necessary before we can add other mappings (like cell-to-point, etc.).
See merge request !140
Coordinate systems separate from fields
Fields for coordinate systems have some common patterns that are not common for other fields. To allow us to specialize and optimize for point coordinate fields, store them in a separate field list.
See merge request !137
The idea of the PointCoordinate classes was to make it easier to define
new special types of point coordinate arrays. But ultimately you have to
create an array handle type, and the CoordinateSystem class pretty much
handles everything else for you. Thus, these classes where being used
nowhere.
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.
