Fix CreateSuperarcsWorklet. Use standard copy to reduce complexity of CreateSuperarcsWorklet.
Fix compile errors in HierarchicalAugmenter.
Some more clean-up and optimization for HierarchicalAugmenter.CreateSuperarcsWorklet.
c62998bd1 Batch line and text annotations for View1D
f7c43960e Update code to follow styling and worklet invoker guidelines
b7470b0af Remove leftover debug statement
8f025a2c5 Batch text and line annotation rendering
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2594
For some reason, GCC is dropping the templated function instances use
for the `UnknownArrayHandle` constructor. Apparently, something in the
compiler or the linker is being over aggressive about removing unused
symbols and is actually dropping symbols that are being used. Maybe it
is because the functions are not directly called but their pointers are
used.
To get around this problem, mark these templated functions in
UnknownArrayHandle.h with the `used` attribute to force the compiler/
linker to keep them. There should be no consequence to that as these
function templates are only instantiated if they are used.
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.
When building the reverse connections (visit points with cells) for
`CellSetSingleType`, the fast path for building these was not built due
to a templating error.
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.
Previously, if you called `Get` on a `Variant` with a type that is not
in the list of types supported by the `Variant`, that would attempt to
look up the type at index `-1` and could spin the compiler into an
endless loop.
Instead, check for the case where you are attempting to get a type from
the `Variant` not listed in its templat arguments. In this case, instead
of producing a compiler error, produce a runtime error. Although this
increases the possibility that a bad compile path is being generated, it
simplifies creating templated code that produces cases we don't care
about.
This commit makes `LineRenderer` and `TextRenderer` to batch line and
text rendering. Batching them has shown a significant speedup,
especially when usin CUDA.
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.
`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.
Previously, the check for visit points with cells for `CellSetExtrude`
only looked at the count of incident cells. This expands the check to
make sure that it actually returns the expected cells.
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`.
The superclass method `CellSetExplicit::GetCellShape()` is marked
deprecated because it is a slow way to access the cell shape. However,
this deprecation is causing a warning with MSVC when implementing the
subclass `CellSetSingleType`'s override of that method (which is not
slow). Suppress this warning.
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.
Make it more clear that ScanExtended increases the array size by
1, what ranges the exclusive and inclusive scan cover, and the
features of the first and last entries.
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.
`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.
4239d13b3 Make triangulate implementation more general
1bd70d9c2 Enable triangulation on CellSetSingleType
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2572
5191909b5 Fix MeshQuality to work with CellSetSingleType
ecf36ed39 Fix compile errors in CellSetSingleType::CompleteAddingCells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2556
The triangulate and tetrahedra worklet implementations were for some
reason grabbing raw arrays out of `CellSetExplicit` and using those for
lookup tables. Rather than do that, simply use a
`WorkletVisitCellsWithPoints` automatically provide the values of these
cells. The advantage of this approach is that it simplifies the code and
also generalize it to cell sets that do not provide this explicit
representation. For example, the new implementation also works with
`CellSetExtrude`.
The code path for doing either tetrahedralization or triangulation on a
CellSetSingleType was not actually doing any work. Changed the worklet
implementation so that these work on CellSetExplicit with any template
parameters (which includes CellSetSingleType).
a2a8dcdfd Allow a `const ArrayHandle` to be reallocated
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2570
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.
Added the following form of `ArrayCopy`:
```cpp
VTKM_CONT_EXPORT void ArrayCopy(
const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination);
```
Note that the destination array is a constant reference. This is
actually OK because you can change the contents of an
`UnknownArrayHandle` (as long as you don't change the array being
referenced). The main motivation for this change is to allow you to call
this form of `ArrayCopy` while passing in a `ArrayHandle` as the second
argument. C++ will automatically make the conversion, but the function
has to accept a const reference for it to be passed correctly.
Note that there is still a form of `ArrayCopy` that accepts a non-const
reference to the destination array. The two arrays behave the same
except for one difference. For the non-const version, if the
`UnknownArrayHandle` does not already point to an array (i.e. is not
valid), a new array will be created and placed in the destination
object. However, because this cannot be done for a const reference, an
exception is thrown instead.
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
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 reason why we did not support shared libraries when CUDA compiles
were on is that virtual methods require a special linking step to pull
together all virtual methods that might be called. I other words, you
cannot call a virtual CUDA method defined inside a library. This
requirement goes away when virtuals are removed.
Also removed the necessity of using seprable compilation with cuda.
Again, this is only needed when a CUDA function is defined in one
translation unit and used in another. Now we can enforce that all
translation units define their own CUDA functions.
Also, suppress warnings in cuda/internal/ExecutionPolicy.h
This is where we call the thrust algorithms. There must be some loop
where it, on some code path, calls back a host function. This must be in
an execution path that never happens. The thrust version has its own
suppress, but that does not seem to actually suppress the warning (it
just means that the warning does not tell you where the actual call is).
Get around the problem by suppressing the warnings in VTK-m.
Co-authored-by: Kenneth Moreland <morelandkd@ornl.gov>
Co-authored-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
Signed-off-by: Vicente Adolfo Bolea Sanchez <vicente.bolea@kitware.com>
0855de1b4 Collect the get methods for `Field` in the header definition
47371bb5e Add ability to convert fields to known types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Vicente Bolea <vicente.bolea@kitware.com>
Merge-request: !2558
`RuntimeDeviceConfiguration` is supposed to log a warning if a specific
device returns a non-success status other than simply an invalid option.
However, the condition was wrong and warnings never happened.
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.
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.
In one of the dashboards, we got a link error about one of the
UnknownArrayHandle internal methods being discarded and then used. Add
an explicit `__attribute__((used))` modifier to prevent this from
happening.
The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from
the `UnknownArrayHandle` was on a device. Seems right, but it is
actually operating on an `ArrayHandleRecombineVec`. This is a special
array that mostly behaves like other `ArrayHandle`s, but because it has
variable vec size, it breaks some `ArrayHandle` conventions.
One of the iffy things it has to do is stick the dependent `Buffer`
objects into the metadata of its own `Buffer` rather than list them in
the `Buffer` list. This means that `ArrayHandle` cannot properly check
them to see where they are located. Instead, it just sees that the one
`Buffer` it has is empty.
A recent change to `IsOnDevice` made it return true for any device if
the `Buffer` is empty. So previously this was broken in that it reported
that the array was not on any device. That changed to report that it was
on all devices, even inactive ones. So the code went from not
efficiently copying to throwing an exception.
This has been fixed by pulling one of the dependent arrays and checking
that one.
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.
3feff3689 Save device choice on spawned control threads
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2543
Having UnknownArrayHandle.h include DefaultTypes.h is problematic,
because that header includes lots of other classes like cell sets.
Keeping these from in turn depending back on UnknownArrayHandle.h is
difficult. So this dependancy is broken.
