There was an issue where if VTK-m was compiled with CUDA support but then
run on a computer where no CUDA device was available, an inappropriate
exception was thrown (instead of just disabling the device). The
initialization code should now properly check for the existance of a CUDA
device.
The `ExtractGeometry` filter was outputing datasets containing
`CellSetPermutation` as the representation for the cells. Although this is
technically correct and a very fast implementation, it is essentially
useless. The problem is that any downstream processing will have to know
that the data has a `CellSetPermutation`. None do (because the permutation
can be on any other cell set type, which creates an explosion of possible
cell types).
Like was done with `Threshold` a while ago, this problem is fixed by deep
copying the result into a `CellSetExplicit`. This behavior is consistent
with VTK.
The Intel compiler by default turns on an optimization that assumes that
all floating point values are finite. This breaks any ligitimate uses of
non-finite values including checking values with functions like `isnan`
and `isinf`. Turn off this feature for the intel compiler.
There are some overloads for atomic adds of floating point numbers for
older versions of cuda that do not include them directly. These were
misnamed and thus not properly overloading the generic implementation.
This caused compile errors with older versions of cuda.
The flying edges version of the contouring filter converted the isovalues
provided into the same type as the field. This is fine for a floating point
field, but for an integer field the isovalue was truncated to the nearest
integer.
This is problematic because it is common to provide a fractional isovalue
(usually N + 0.5) for integer fields to avoid degenerate cases of the
contour intersecting vertices. It also means the behavior changes between
an integer type that is directly supported (like a `signed char`) or an
integer type that is not directly supported and converted to a floating
point field (like potentially a `char`).
This change updates the worklets to allow the isovalue to have a different
type than the field and to always use a floating point type for the
isovalue.
The flying edges algorithm (used when contouring uniform structured cell
sets) was not interpolating cell fields correctly. There was an indexing
issue where a shortcut in the stepping was not incrementing the cell index.
There was a bug in `CleanGrid` when removing degenerate polygons where it
would not detect if the first and last point were the same. This has been
fixed.
There was also an error with function overloading that was causing 0D and
3D cells to enter the wrong computation for degenerate cells. This has also
been fixed.
Fixes#796
67b7543a3 Adding documentation for flow filter restructure
dbc873efa Changes to address feedback from MR
67716402b Correct export in class declaration
6d1d4f90a Fixing linking issues for flow Analysis class
adcb42455 Removing unnecessary file
78ca3f301 Fixing linking issues for flow Analysis class
0e1ade83a Fixing linking issues for flow Analysis class
12a3bc94e Adding test dependency of filter_flow on tests
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3087
Previously, the MIR filter ran a check the dimensionality of the cells in
its input data set to make sure they conformed to the algorithm. The only
real reason this was necessary is because the `MeshQuality` filter can only
check the size of either area or volume, and it has to know which one to
check. However, the `CellMeasures` filter can compute the sizes of all
types of cells simultaneously (as well as more cell types). By using this
filter, the MIR filter can skip the cell type checks and support more mesh
types.
The `GhostCellRemove` filter had some methods inconsistent with the naming
convention elsewhere in VTK-m. The class itself was also in need of some
updated documentation. Both of these issues have been fixed.
Additionally, there were some conditions that could lead to unexpected
behavior. For example, if the filter was asked to remove only ghost cells
and a cell was both a ghost cell and blank, it would not be removed. This
has been updated to be more consistent with expectations.
The `ExternalFaces` filter uses hash codes to find duplicate (i.e.
internal) faces. The issue with hash codes is that you have to deal with
unique entries that have identical hashes. The worklet to count how many
unique, unmatched faces were associated with each hash code was correct.
However, the code to then grab the ith unique face in a hash was wrong.
This has been fixed.
Fixes#789
Kokkos 4 switches from their interal library based off of desul to using desul directly.
This removes VTK-m's dependency on the Kokkos internal implementation (Kokkos::Impl) to
using desul directly.
This filter takes a `DataSet` and returns a point cloud representation that
has a vertex cell associated with each point in it. This is useful for
filling in a `CellSet` for data that has points but no cells. It is also
useful for operations in which you want to throw away the cell geometry and
operate on the data as a collection of disparate points.
Although the contour filter was recently divided into 2 filters, flying
edges and marching cubes, the marching cubes version still had many
conditions and was the file that took the longest to compile on Frontier.
To help speed up parallel compiles and prevent a single run of a
compiler from being overwhelmed, the compilation of all the marching
cubes conditions has been split up using instantiations.
There are occasions when you need a worklet to opeate on 2D or 3D
indices. Most worklets operate on 1D indices, which requires recomputing
the 3D index in each worklet instance. A workaround is to use a worklet
that does a 3D scheduling and pull the working index from that.
The problem was that there was no easy way to get this 3D index. To
provide this option, a feature was added to the `BoundaryState` class
that can be provided by `WorkletPointNeighborhood`.
Thus, to get a 3D index in a worklet, use the
`WorkletPointNeighborhood`, add `Boundary` as an argument to the
`ExecutionSignature`, and then call `GetCenterIndex` on the
`BoundaryState` object passed to the worklet operator.
The file `ArrayRangeCompute.cxx` was taking a long time to compile with
some device compilers. This is because it precompiles the range computation
for many types of array structures. It thus compiled the same operation
many times over.
The new implementation compiles just as many cases. However, the
compilation is split into many different translation units using the
instantiations feature of VTK-m's configuration. Although this rarely
reduces the overall CPU time spent during compiling, it prevents parallel
compiles from waiting for this one build to complete. It also avoids
potential issues with compilers running out of resources as it tries to
build a monolithic file.
Previously, the `ComputeMoments` filter only operated on a finite set of
array types as its input field. This included a prescribed list of `Vec`
sizes for the input. The filter has been updated to use more generic
interfaces to the field's array (and float fallback) to enable the
computation of moments on any type of scalar field.
The internal array copy has an optimization to use the device the array
exists on to do the copy. However, if that device is disabled the copy
would fail. This problem has been fixed.
The `FilterField` class provides convenience functions for subclasses to
determine the `ArrayHandle` type for scalar and vector fields. However, you
needed to know the specific size of vectors. For filters that support an
input field of any type, a new form, `CastAndCallVariableVecField` has been
added. This calls the underlying functor with an `ArrayHandleRecombineVec`
of the appropriate component type.
The `CastAndaCallVariableVecField` method also reduces the number of
instances created by having a float fallback for any component type that
does not satisfy the field types.
The legacy VTK file reader previously only supported a specific set of Vec
lengths (i.e., 1, 2, 3, 4, 6, and 9). This is because a basic array
handle has to have the vec length compiled in. However, the new
`ArrayHandleRuntimeVec` feature is capable of reading in any vec-length
and can be leveraged to read in arbitrarily sized vectors in field
arrays.
There was an error in `operator-=` for `IteratorFromArrayPortal` that went
by unnoticed. The operator is fixed and regression tests for the operators
has been added.
`UnknownArrayHandle` is supposed to treat `ArrayHandleRuntimeVec` the
same as `ArrayHandleBasic`. However, the `NewInstance` methods were
failing because they need custom handling of the vec size.
In addition to using uniform coordinates, the ContourFlyingEdges filter can now process any type of coordinate system, making the filter use Flying Edges in more cases
In order to compile the contour filter more efficiently, we split the contour filter into two separate translation units, corresponding to the new filters ContourFlyingEdges and ContourMarchingCells. The API for Contour filter is left totally unchanged, and tries to use flying edges if the dataset is structured and uniform.
All three contour filters inherit from the `AbstractContour` class, providing utility methods used in the implementations.
Previously, tetrahedralize/triangulate would blindly convert all the cells to tetrahedra/triangles, even when they were already. Now, the dataset is directly returned if the CellSet is a CellSetSingleType of tetras/triangles, and no further processing is done in the worklets for CellSetExplicit when all shapes are tetras or triangles.
I've been seeing errors in a nightly build that compiles for CUDA Pascal
using GCC5. The issue is that one of the `ArrayHandleMultiplexer` tests
is failing to copy an implicit array correctly. I think the problem is
that in this test the first and second type of the `Variant` are the same
size, but the first type has some padding in the middle whereas the
second type does not. When using this second type, the values in the
same position of the padding of the first type don't seem to be
initialized properly in the kernel invocation.
My nonexhaustive experiment shows that things work OK as long as the
first type is large enough and has no fillers. Enforce this by adding an
internal entry to the union that is completely full.
This new filtered designed for bi-variate analysis builds the continuous scatterplot of a 3D tetrahedralized mesh for two given scalar point fields. The continuous scatterplot is an extension of the discrete scatterplot for continuous bi-variate analysis.
The clip filter used to copy the input points and point fields as is,
regardless of if they were actually part of the output. With this change,
we track which input points are actually part of the output and copy
only those values.
Address: #112
ac889b500 Implement VecTraits class for all types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3018
