f71f3ed0 Allow the gradient filter to compute Vorticity and QCriterion.
efb119ea Sort the worklet headers, as they should be in alphabetical order.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !638
Literals that are used to represent the bits of certain floating point
numbers (e.g. VTKM_NAN_BITS_64) are placed into unsigned integers before
converted to floating points. We ran into an example where the compiler
complained that a literal (specifically VTKM_NEG_INF_BITS_64) was
declared signed and was negative but then placed in an unsigned (64-bit)
integer. This should fix the problem by making the literal itself
unsigned.
CellSetExplicit had a constructor that took a single argument that is
the number of points in the data and another constructor that had two
arguments of the number of points and the name. The problem was that the
latter constructor had a default argument for the second argument. Thus,
if you tried to construct a CellSetExplicit with just the number of
points, it would fail to compile because the compiler would not know
which constructor to use.
Fix the issue by removing the single argument constructor.
98c8cb86 Do not attempt to execute CUDA kernels with no blocks
fda3ec71 Don't call std functions in math nonfinte functions for CUDA
55c159d6 Check error codes from CUDA functions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !632
While writing a test I noticed that some of the MakeTestDataSet
hexahedrons had improper point ordering. It was close but backwards so
that all the faces pointed in instead of out.
f698a006 Simplify the implementation of the average worklets.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !637
I noticed that when I attempted to execute a CUDA kernel with 0 blocks,
it generated a CUDA error. The error did not really matter since nothing
was really supposed to run anyway. However, once we are careful about
checking CUDA errors, it will cause test failures and likely other
misdiagnoses.
The math nonfinite check functions (like IsNan) were calling the std
equivalent function. This is fine for most architectures, but is not
available for devices under CUDA. Instead, call the CUDA version of
these functions when compiling with CUDA.
This fixes an issue that became apparent once we added CUDA error code
checking.
854e298b CellAverage filter now verifies the field is a point field.
b85cb2dd Add a PointAverage Filter.
daa75d74 Add a PointAverage worklet which is the twin to CellAverage.
839d8e83 CellAverage first control parameter is now the cellset.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !636
eba19df3 Add a filter that handles all the gradient computations.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !635
Most functions in the CUDA runtime API return an error code that must be
checked to determine whether the operation completed successfully. Most
operations in VTK-m just called the function and assumed it completed
correctly, which could lead to further errors. This change wraps most
CUDA calls in a VTKM_CUDA_CALL macro that checks the error code and
throws an exception if the call fails.
8a93ecc4 code alignment tweaks.
6fa448b5 Remove the 1D camera. 1D plots will use a 2D camera.
52aa9b9a Fix some compile errors.
23d8d585 Add explicit 1D rendering. Also added some data model suport.
db522c4c Add GetCanvas calls to the mapper classes.
87b1cdca cleanup. Remove some compiler warnings.
d38e6270 Support for 1D rendering.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !616
2e05c1dd Support derivatives of vectors
dd45b568 Vec of Vec fixes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !630
I forgot to add the VTKM_EXEC_CONT modifier to the make_VecC methods,
and that causes them to fail on CUDA devices.
I wish the compiler would have said something. I was calling one of them
from a VTKM_EXEC method.
The cell derivative/gradient functions were all designed with scalars in
mind. Although the field type is templated and you could pass in a
vector type for the field, many of these classes would perform the
computation incorrectly. These changes specifically support derivatives
of vector types.
Fix a couple of places where having a Vec of a Vec (for example
vtkm::Vec<vtkm::Vec<vtkm::Float32, 3>, 3>) did not work as it should.
One major place was in the test_equal function used in the testing
framework. If given a Vec of Vec, it would try to convert the Vec to
Float64 and fail. Now the comparison decends as many levels as need be.
The second place was in TypeTraits::ZeroInitialization() for all Vec
types. Originally it initialized the Vec using the default constructor
of the component type. This works fine when the component type is a
standard type, but if the component type is itself a Vec, then the
default constructor does not actually set any of the sub components.
Solved the issue by using the result of ZeroInitialization for the
component type, which will work for basic types and Vecs and anything
else supported by TypeTraits.
These structs behave much like Vec except that they work on a short C
array given to them rather than having the statically sized short array
defined within.
I expect to use this in the short term to help implement cell face
classes, but there are probably many other uses.
ec5fd175 Modify test_equal for values close to zero
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !629
b97b4cc7 Allow thrust::reduce to work when iterator and initial value types differ.
64bcc343 Refactor MinAndMax to use vtkm::Vec<T,2> instead of Pair.
8d60ed57 Refactor MinAndMax to be a shared binary operator.
18375b54 Update Bound computations to always use a single Reduce call
2cfc9743 Reduce can support reduce to a T type that isn't the arrayhandles T type.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !614
I noticed the UnitTestTransform3D test failed using the random seed
1480544620. On closer inspection, I found that the issue was with the
comparison of two numbers close to 0. The numbers were just above the
threshold, but their difference was not quite enough to make the ratio
below the threshold.
After reviewing some other floating point comparisons, they seem to be
more forgiving of numbers close to 0. Thus, I changed this comparison to
pass if the difference between the numbers was below the threshold.
Because this makes the comparison a lot more forgiving for small
numbers, I lowered the default threshold by an order of magnitude. So
far it looks like the tests are passing, but we should look out for
occasional failures.
