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`.
Rather than require `ArrayCopy` to create special versions of copy for
all arrays, use a precompiled versions. This should speed up compiles,
reduce the amount of code being generated, and require the device
compiler on fewer source files.
There are some cases where you still need to copy arrays that are not
well supported by the precompiled versions in `ArrayCopy`. (It will
always work, but the fallback is very slow.) In this case, you will want
to switch over to `ArrayCopyDevice`, which has the old behavior.
d7b4390d1 Specify end position when filling values in Buffer
7a4cbaf10 Suggestions during review by Gunther Weber
8e4fb7ebd Suppress unhelpful nvcc warning
bacca0693 Add Fill method for non-standard Storage
9da66ff32 Prefer ArrayHandle::Fill over Algorithm::Fill
f79cf1d5f Add BitField::Fill and BitField::AllocateAndFill
926164049 Add Fill and AllocateAndFill to ArrayHandle
0cf996f41 Add ability to fill values in a Buffer
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2660
To avoid having to use a device compiler every time you wish to use
`ArrayGetValue`, the actual implementation is compiled into the `vtkm_cont`
library. To allow this to work for all the templated versions of
`ArrayHandle`, the implementation uses the extract component features of
`UnknownArrayHandle`. This works for most common arrays, but not all
arrays.
For arrays that cannot be directly represented by an `ArrayHandleStride`,
the fallback is bad. The entire array has to be pulled to the host and then
copied serially to a basic array.
For `ArrayGetValue`, this is just silly. So, for arrays that cannot be
simply represented by `ArrayHandleStride`, make a fallback that just uses
`ReadPortal` to get the data. Often this is not the most efficient method,
but it is better than the current alternative.
The `test_equal_images` function has been expanded to supply the
generated image in a `Canvas` or a `DataSet` in addition to a `View`.
Much of the templating code has been removed from `test_equal_images`
and most of the code has moved into the `vtkm_rendering_testing`
library.
The previous functions that enabled the render regression tests were
heavily templated, which required every test using rendering to
recompile the entire rendering system being used. Changed the interface
to not rely on templating so that the RenderTest method can be moved
into a library.
Also moved the options into a struct where they can be better managed.
The render testing functions tended to have lots of arguments that were
difficult to manage. Instead, created a single `struct` that holds all
the potential options. That way when someone specifies on option, it is
clear what option is being set.
The legacy VTK file writer writes out in ASCII. This is helpful when a
human is trying to read the file. However, if you have more than a
trivial amount of data, the file can get impractically large. To get
around this, `VTKDataSetWriter` now has a flag that allows you to write
the data in binary format.
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 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.
`vtkm::cont::UnknownArrayHandle` now provides a set of method that
allows you to copy data from one `UnknownArrayHandle` to another. The
first method, `DeepCopyFrom`, takes a source `UnknownArrayHandle` and
deep copies the data to the called one. If the `UnknownArrayHandle`
already points to a real `ArrayHandle`, the data is copied into that
`ArrayHandle`. If the `UnknownArrayHandle` does not point to an existing
`ArrayHandle`, then a new `ArrayHandleBasic` with the same value type as
the source is created and copied into.
The second method, `CopyShallowIfPossibleFrom` behaves similarly to
`DeepCopyFrom` except that it will perform a shallow copy if possible.
That is, if the target `UnknownArrayHandle` points to an `ArrayHandle`
of the same type as the source `UnknownArrayHandle`, then a shallow copy
occurs and the underlying `ArrayHandle` will point to the source. If the
types differ, then a deep copy is performed. If the target
`UnknownArrayHandle` does not point to an `ArrayHandle`, then the
behavior is the same as the `=` operator.
One of the intentions of these new methods is to allow you to copy
arrays without using a device compiler (e.g. `nvcc`). Calling
`ArrayCopy` requires you to include the `ArrayCopy.h` header file, and
that in turn requires device adapter algorithms. These methods insulate
you from these.
Scheduling topology map workets for `CellSetExtrude` always worked, but
the there were indexing problems when a `Scatter` or a `Mask` was used.
This has been corrected, and now `Scatter`s and `Mask`s are supported on
topology maps on `CellSetExtrude`.
Because `CellSetExplicit` is a templated class, the implementation of
most of its features is part of the header files. One of the things that
was included was the code to build the reverse connectivity links. That
is, it figured out which cells were incident on each point using the
standard connections of which points comprise which cells.
Of course, building these links is non-trivial, and it used multiple
DPPs to engage the device. It meant that header had to include the
device adapter algorithms and therefore required a device compiler. We
want to minimize this where possible.
To get around this issue, a non-templated function was added to find the
reverse connections of a `CellSetExplicit`. It does this by passing in
`UnknownArrayHandle`s for the input arrays. (The output visit-points-
with-cells arrays are standard across all template instances.) The
implementation first iterates over all `CellSetExplicit` versions in
`VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types.
In the unlikely event that none of these arrays work, it copies the data
to `ArrayHandle<vtkm::Id>` and uses those.
`ConvertNumComponentsToOffsets` has been changed to provide a pre-
compiled version for common arrays. This helps with the dual goals of
compiling less device code and allowing data set builders to not have to
use the device compiler. For cases where you need to compile
`ConvertNumComponentsToOffsets` for a different kind of array, you can
use the internal `ConvertNumComponentsToOffsetsTemplate`.
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.
Previously, the `Allocate` method of `ArrayHandle` was _not_ declared as
`const`. Likewise, the methods that depended on `Allocate`, namely
`ReleaseResources` and `PrepareForOutput` were also not declared `const`.
The main consequence of this was that if an `ArrayHandle` were passed as a
constant reference argument to a method (e.g. `const ArrayHandle<T>& arg`),
then the array could not be reallocated.
This seems right at first blush. However, we have changed these methods to
be `const` so that you can in fact reallocate the `ArrayHandle`. This is
because the `ArrayHandle` is in principle a pointer to an array pointer.
Such a structure in C will allow you to change the pointer to the array,
and so in this context it makes sense for `ArrayHandle` to support that as
well.
Although this distinction will certainly be confusing to users, we think
this change is correct for a variety of reasons.
1. This change makes the behavior of `ArrayHandle` consistent with the
behavior of `UnknownArrayHandle`. The latter needed this behavior to
allow `ArrayHandle`s to be passed as output arguments to methods that
get automatically converted to `UnknownArrayHandle`.
2. Before this change, a `const ArrayHandle&` was still multible is many
way. In particular, it was possible to change the data in the array
even if the array could not be resized. You could still call things
like `WritePortal` and `PrepareForInOut`. The fact that you could
change it for some things and not others was confusing. The fact that
you could call `PrepareForInOut` but not `PrepareForOutput` was doubly
confusing.
3. Passing a value by constant reference should be the same, from the
calling code's perspective, as passing by value. Although the function
can change an argument passed by value, that change is not propogated
back to the calling code. However, in the case of `ArrayHandle`,
calling by value would allow the array to be reallocated from the
calling side whereas a constant reference would prevent that. This
change makes the two behaviors consistent.
4. The supposed assurance that the `ArrayHandle` would not be reallocated
was easy to break even accidentally. If the `ArrayHandle` was assigned
to another `ArrayHandle` (for example as a class' member or wrapped
inside of an `UnknownArrayHandle`), then the array was free to be
reallocated.
835467753 Fix link issue with discarded section
42acb9a66 Properly check whether ArrayHandleRecombineVec is on device
c17a5569f Do not try to use ArrayGetValue on arrays of non-basic types
9ca0cd1f6 Report array type when UnknownArrayHandle::ExtractComponent fails
e1ac918bc Compile ArrayGetValues implementation in library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2551
In VTK-m we have a constant tension between minimizing the number of
types we have to compile for (to reduce compile times and library size)
and maximizing the number of types that our filters support.
Unfortunately, if you don't compile a filter for a specific array type
(value type and storage), trying to run that filter will simply fail.
To compromise between the two, added methods to `DataSet` and `Field`
that will automatically convert the data in the `Field` arrays to a type
that VTK-m will understand. Although this will cause an extra data copy,
it will at least prevent the program from failing, and thus make it more
feasible to reduce types.
Previously, all of the `ArrayGetValues` implementations were templated
functions that had to be built. That meant that any code using them had
to be compiled with a device compiler and create special code for it.
This change uses an `UnknownArrayHandle` to encapsulate the
`ArrayHandle` and call a per-compiled library function. This means that
the code only has to be compiled once.
Added features with reporting types with `UnknownArrayHandle`. First,
added a method named `GetArrayTypeName` that returns a string containing
the type of the contained array. There were already methods
`GetValueType` and `GetStorageType`, but this provides a convenience to
get the whole name in one go.
Also improved the reporting when an `AsArrayHandle` call failed. Before,
the thrown method just reported that the `UnknownArrayHandle` could not
be converted to the given type. Now, it also reports the type actually
held by the `UnknownArrayHandle` so the user can better understand why
the conversion failed.
VTK-m contains a helpful method named `vtkm::cont::TypeToString` that
either takes a type as a template argument or a `std::type_info` object
and returns a human-readable string for that type.
The standard C++ library has an alternate for `std::type_info` named
`std::type_index`, which has the added ability to be used in a container
like `set` or `map`. The `TypeToString` overloads have been extended to
also accept a `std::type_info` and report the name of the type stored in
it (rather than the name of `type_info` itself).
These were previously suppressed because they are unavoidable when
calling virtual methods. But we no longer support virtual methods on
devices (it is deprecated).
These warnings can still happen if you have unbounded recursion. But we
would like to avoid unbounded recursion, so we would like to see these
warnings.
Also turned on other nvlink warnings, which include when a recursive
function call means that the compiler cannot figure out the full
stack depth.
Often times you have an array of an unknown type (likely from a data set),
and you need it to be of a particular type (or can make a reasonable but
uncertain assumption about it being a particular type). You really just
want a shallow copy (a reference in a concrete `ArrayHandle`) if that is
possible.
`ArrayCopyShallowIfPossible` pulls an array of a specific type from an
`UnknownArrayHandle`. If the type is compatible, it will perform a shallow
copy. If it is not possible, a deep copy is performed to get it to the
correct type.
Fixes#572.
It updates the ReleaseProcess.md document to describe our bi-branchial
workflow composed by a release branch and master branch
It also adds ReleaseHotFix.md which describes how to perform a HotFix
onto master/release branch.
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>