03a4750a3 Change Oscillator output field name to oscillating
a3462b41c Change Wavelet output field name to RTData
ea1a55359 Name tangle source fields appropriately
a68422d45 Add GenerateIds filter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2595
This matches the output field name in VTK and ParaView for the
equivalent source. This change allows this source to be used as a drop-
in replacement for the VTK source (which could be very useful).
The `Tangle` source would create a point field generically named
`nodevar`. This name was not indicitive of the data or its source. Thus,
the output point field has been renamed `tangle`.
The `Tangle` source was also creating a cell field (named `cellvar`).
This field was really just a mirror of the cell indices (counting from 0
on up). This field has been removed from the input. If you want such a
field, you can now use the `GenerateIds` filter to add it to any data
set.
This filter adds a pair of fields to a `DataSet` which mirror the
indices of the points and cells, respectively. These fields are useful
for tracking the provenance of the elements of a `DataSet` as it gets
manipulated by the filters. It is also convenient for adding indices to
operations designed for fields and for testing purposes.
Some of the unit tests for serial and kokkos are disable for hipcc to
properly compile.
VTKM_MATH_ASSERT and VTKM_TEST_ASSERT fail to compile with HIP in
execution environment so they are disabled with building with HIP.
Kokkos::finalize is causing error so it is temporarily disabled.
There was a case where a VTK-m exception was caught and then used in a
logging message. That is fine, but if VTK-m logging is turned off, that
code is removed and the exception variable goes unused.
There was a time when it was common to have logging turned off in VTK-m,
but now it is almost always on. There is one old-style dashboard that
has logging turned off and is giving a warning about this variable not
being used. It went unnoticed because the dashboard was down at the
time. This should fix the issue.
For no particularly good reason, there were two functions that converted
and array of counts to an array of offsets: `ConvertNumComponentsToOffsets`
and `ConvertNumIndicesToOffsets`. These functions were identical, except
one was defined in `ArrayHandleGroupVecVariable.h` and the other was
defined in `CellSetExplicit.h`.
These two functions have been consolidated into one (which is now called
`ConvertNumComponentsToOffsets`). The consolidated function has also been
put in its own header file: `ConvertNumComponentsToOffsets.h`.
Normally, backward compatibility would be established using deprecated
features. However, one of the things being worked on is the removal of
device-specific code (e.g. `vtkm::cont::Algorithm`) from core classes like
`CellSetExplicit` so that less code needs to use the device compiler
(especially downstream code).
Part of this change removed unnecessary includes of `Algorithm.h` in
`ArrayHandleGroupVecVariable.h` and `CellSetExplicit.h`. This header had to
be added to some classes that were not including it themselves.
5191909b5 Fix MeshQuality to work with CellSetSingleType
ecf36ed39 Fix compile errors in CellSetSingleType::CompleteAddingCells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2556
By default, the `FilterDataSet` class will iterate over all fields and
use `CastAndCall` on each one to call the subclass' mapping function
with the appropriate array type.
This only works if the array is of a known type. If it is not
`CastAndCall` throws an exception. However, having the entire filter
exception out just because one field cannot be converted does not make
sense. Instead, catch the exception, log a warning, and drop the field.
The `MeshQuality` filter only worked with `CellSetExplicit<>`. However,
`MeshQuality` should also work with `CellSetSingleType`. Fix
`MeshQuality` to work with both.
The handling of cell sets was actually worse than that. After forcing
the type to `CellSetExplicit<>`, it then applied a policy that converted
the types back to all possible cell sets. Thus, the filter made lots of
code paths that were impossible to follow.
39054e644 Add corner case unit test.
0a3fd2629 Add test file for corner case.
4b0896bd8 Fix for corner case in particle advection.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Abhishek Yenpure <abhishek@uoregon.edu>
Merge-request: !2545
Since we have (hopefully) gotten rid of all unbounded recursion and
calls to function pointers or virtual methods, the CUDA compiler should
be able to statically determine the size of the stack needed. Thus, we
shouldn't need `ScopedCudaStackSize` at all.
However, there is one odd case where using it seems to be necessary. It
is unclear why, but that is an issue for another day.
There were several places in the code that had to check the type of an
`UnknownArrayHandle` and conditionally get or copy that array. This code
is simplified by using `ArrayCopyShallowIfPossible`.
