This has the side effect of initialing MPI_Init (and will also
call MPI_Finalize at program exit). However, if the calling
code has already called MPI_Init, then nothing will happen.
Thus, if the calling code wants to manage MPI_Init/Finalize,
it can do so as long as it does before it initializes VTK-m.
There was a bug with Flying Edges checking the boundary conditions in
the z-direction. It was comparing the z index to the size of the y
dimension, not the z dimension. This simple typo was probably missed
because most of the tests use square meshes. To catch the problem, you
need a mesh that has a different number of points in the y and z
directions and the contour has to go past the positive z boundary.
When this error was hit, the indices for the edges on that boundary were
not recorded, and later interpolation used garbage values for edge's
point ids.
The `Variant` class was missing a way to check the type. You could do it
indirectly using `variant.GetIndex() == variant.GetIndexOf<T>()`, but
having this convenience function is more clear.
9855db096 Add test for array and datas that are cleaned up after finalize
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2801
Previously, the number of buffers held by an `ArrayHandle` had to be
determined statically at compile time by the storage. Most of the time
this is fine. However, there are some exceptions where the number of
buffers need to be selected at runtime. For example, the
`ArrayHandleRecombineVec` does not specify the number of components it
uses, and it needed a hack where it stored buffers in the metadata of
another buffer, which is bad.
This change allows the number of buffers to vary at runtime (at least at
construction). The buffers were already managed in a `std::vector`. It
now no longer forces the vector to be a specific size.
`GetNumberOfBuffers` was removed from the `Storage`. Instead, if the
number of buffers was not specified at construction, an allocation of
size 0 is done to create default buffers.
The biggest change is to the interface of the storage object methods,
which now take `std::vector` instead of pointers to `Buffer` objects.
This adds a little hastle in having to copy subsets of this `vector`
when a storage object has multiple sub-arrays. But it does simplify some
of the templating.
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
The legacy VTK file reader for unstructured grids had a bug when reading
cells of type voxel. VTK-m does not support the voxel cell type in
unstructured grids (i.e. explicit cell sets), so it has to convert them to
hexahedron cells. A bug in the reader was mangling the cell array index
during this conversion.
It is the case that arrays might be deallocated from a device after the
device is closed. This can happen, for example, when an `ArrayHandle` is
declared globally. It gets constructed before VTK-m is initialized. This
is OK as long as you do not otherwise use it until VTK-m is initialized.
However, if you use that `ArrayHandle` to move data to a device and that
data is left on the device when the object closes, then the
`ArrayHandle` will be left holding a reference to invalid device memory
once the device is shut down. This can cause problems when the
`ArrayHandle` destructs itself and attempts to release this memory.
The VTK-m devices should gracefully handle deallocations that happen
after device shutdown.
`UnknownArrayHandle` compares `std::type_index` objects to check whether a
requested type is the same as that held in the array handle. However, it is
possible that different translation units can create different but
equivalent `std::type_info`/`std::type_index` objects. In this case, the
`==` operator might return false for two equivalent types. This can happen
on OSX.
To get around this problem, `UnknownArrayHandle` now does a more extensive
check for `std::type_info` object. It first uses the `==` operator to
compare them (as before), which usually works but can possibly return
`false` when the correct result is `true`. To check for this case, it then
compares the name for the two types and returns `true` iff the two names
are the same.
There was a bug where if you attempted to copy a variant that was not
valid (i.e. did not hold an object), a seg fault could happen. This has
been changed to set the target variant to also be invalid.
982e96553 1.8.0 is our 12th official release of VTK-m.
fdd5e04eb Update release notes for 1.8.0
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !2787
For the `Backport: release` command to work on a MR, it needs to be at
the bottom of the description of the MR. However, `ReleaseHotFix.md`
claimed it could be anywhere in the description. Fix that.
Whan an `UnknownArrayHandler` is constructed from an `ArrayHandle`, it uses
the `VecTraits` of the component type to construct its internal functions.
This meant that you could not put an `ArrayHandle` with a component type
that did not have `VecTraits` into an `UnknownArrayHandle`.
`UnknownArrayHandle` now no longer needs the components of its arrays to
have `VecTraits`. If the component type of the array does not have
`VecTraits`, it treats the components as if they are a scalar type.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.
97f5ed640 Remove testing include from ZFP worklet headers
8d5e636ac Enable ci that compiles without testing
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2738
Several of the ZFP worklet headers included `vtkm/cont/testing/
MakeTestDataSet.h`. This is a problem because if testing is turned off,
then `MakeTestDataSet.h` attempts to include a file that is not
generated, so the compile just fails if testing is off (and the testing
library is not on). This include must be a remanent of some old testing
code during development. It can be safely removed.
The cell classifications were using an unscoped enum to define them. The
problem was that the symbols of the enum littered the `vtkm` namespace
without qualification. For example, it defined `vtkm::NORMAL`, which
could easily collide with some other meaning of normal.
Change the cell classification flags to be scoped within
`vtkm::CellClassification`. This thing behaves mostly like a scoped
enum. You can use the values declared within and reference
`vtkm::CellClassification` as a type itself. However, unlike a scoped
enum, `vtkm::CellClassification` items can automatically be cast to and
from `vtkm::UInt8`.
The symbols in `vtkm::cont::Field::Association` have been changed from
`ANY`, `WHOLE_MESH`, `POINTS`, and `CELL_SET` to `Any`, `WholeMesh`,
`Points`, and `Cells`, respectively. The reason for this change is twofold:
* The general standard that VTK-m follows for `enum struct` enumerators
is to use camel case (with the first character capitalized), not all
upper case.
* The use of `CELL_SET` for fields associated with cells is obsolete. A
`DataSet` used to support having more than one `CellSet`, and so a
field association on cells was actually bound to a particular
`CellSet`. However, that is no longer the case. A `DataSet` has exactly
one `CellSet`, so a cell field no longer has to point to a `CellSet`.
Thus the enumeration symbol for `Cells` should match the one for
`Points`.
For backward compatibility, the old enumerations still exist. They are
aliases for the new names, and they are marked as deprecated, so using them
will result in a compiler warning (on some systems).
GCC 11 is having trouble compiling brigand.hpp at all, even before we
instantiate any templates. Since we no longer need it, let's get rid of
it. It was always placed in an internal namespace.
Add deprecation warnings to the code whenever someone uses brigand.hpp.
We are no longer supporting this header file, but we'll give code a
chance to transition off of it.
Also added some other deprecation warnings to other header files that
are themselves deprecated but only issued warnings if you used something
in it.
These new features to VTK-m lists allow you to compute a single value
from a list. `ListReduce` allows you to compute a value based on a
predicate. `ListAll` and `ListAny` use this feature to determine if all
or any of a list of `true_type` or `false_type` objects are true.
ca032801a Allow ArrayExtractComponent to work with Vec-like value types
f48b4b761 Add implementation of VecTraits for Range and Bounds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Gunther Weber <ghweber@lbl.gov>
Merge-request: !2683
The original version of `Filter` classes had a helper header file named
`CreateResult.h` that had several forms of a `CreateResult` function that
helped correctly create the `DataSet` to be returned from a filter's
`DoExecute`. With the move to the `NewFilter` structure, these functions
did not line up very well with how `DataSet`s should actually be created.
A replacement for these functions have been added as protected helper
methods to `NewFilter` and `NewFilterField`. In addition to moving them
into the filter themselves, the behavior of `CreateResult` has been merged
with the map field to output functionality. The original implementation of
`Filter` did this mapping internally in a different step. The first design
of `NewFilter` required the filter implementer to call a
`MapFieldsOntoOutput` themselves. This new implementation wraps the
functionality of `CreateResult` and `MapFieldsOntoOutput` together so that
the `DataSet` will be created correctly with a single call to
`CreateResult`. This makes it easier to correctly create the output.
Added specializations of `vtkm::VecTraits` for the simple structures of
`vtkm::Range` and `vtkm::Bounds`. This expands the support for using
these structures in things like `ArrayHandle` and `UnknownArrayHandle`.
