This header is now considered an internal header, and the latest
release commit of Kokkos does not allow you to include it. The
header gets included anyway with Kokkos_Core.hpp, so we can safely
just delete it.
See https://github.com/kokkos/kokkos/pull/5178
Rather than try to collect all `LastCell` types inside of a single
header and make an uber type, have each cell locator define its own cell
locator type and use that.
This is an addition to commit e312c5435651f326f530a976d3faf3752350911e,
which corrects type comparison on OSX for typeids created in different
translation units. That missed the type correction for the
`BaseComponentType` of `UnknownArrayHandle`.
This commit address issue #713 and removes the need to pass information
about the spatial decomposition (block origins, block sizes, block index
and blocks per dimension) to the contour tree filter. Block origin
information is added to CellSetStructured (as GlobalPointSize) and the
distributed contour tree filter will get this information from
CellSetStructured instead of expecting it as parameters to the
constructor. Information about blocks per dimension and block indices
are computed from the information in CellSetStructure albeit requiring
global communication across all ranks. To avoid this communication cost,
the caller of the filter may explicitly specify this information via the
SetBlockIndices() method.
898a3e092 Move StreamSurface into NewFilterField
5ffae6111 Use CastAndCallForTypes with UnknownArray of seeds.
061fe6afb Fix dashboard compile errors.
42fd70d50 Remove virtuals from DataSetIntegrator classes.
2524c16a0 Missed some cuda fixes filters...
e1fbfea30 Remove device compiler dependencies.
2a4430447 tests need to be device compiled.
9b2a257d9 Move include out of .h file.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2777
AddGhostCellField function for Dataset class
setGhostCellName function for GhostCellClassify class
setGhostCellName function for GhostCellClassify class
added default ghost cell name in Dataset class
Default ghost cell field name defined in GhostCellClassify class
Default ghost cell field name for GhostCellClassify class
Unit test for ghost field name check
Unit test for ghost field name check updated
Default ghost field name updated
Get function for GhostCellClassify and default ghost name
UnitTestStreamlineFilter updated with AddGhostCellField
AddGhostCellField and GetGlobalGhostCellFieldName propagated
GhostCellClassify constructor now defined in header file
Assigned default values to dataset class members GhostSet and GhostCellName
default values set for GhostSet and GhostCellName in dataset constructor
Constructor removed from dataset class and noexcept for GetGlobalGhostName
added Dataset constructor with noexcept
additions to make sure default move constructor has not changed
GhostSetName field made as a shared pointer since string class is not noexcept
AddGhostCellField funtion added without field name
hasGhostCellField added and unit tests updated for addGhostCellField
hasGhostCellField added and unit tests updated for addGhostCellField
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
GetGhostCellField and GetGhostCellFieldName functions added to Dataset
debugging UnitTestCellLocatorGerneral for CUDA error
UnitTestCellLocatorGeneral testing for error
UnitTestCellLocatorGeneral testing for cude error
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution
UnitTestCellLocatorGeneral error resolution print statement removed
Minor updates to Dataset class files
GlobalGhostCellFieldName implementation revised to return a static variable
GhostSet member removed, hasGhostCellField, constructor, copystructure updated
GetGhostCellField and GetGhostCellFieldName made cosistent with GetField
Fixes to a few function calls
Now that it is easier to select which unit tests should be compiled by a
device compiler (and run on a device), allow the transport classes to be
tested on actual devices rather than just the serial device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Previously, each device adapter implementation had their own version of
these tests by including a common header. Simplify this by making a
single test in UnitTests_vtkm_cont_testing for each, which can now be
compiled for and tested on a device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Also re-enabled the testing of ranges for Vecs of size 9, which is now
supported.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Previously, each device adapter implementation had their own version of
these tests by including a common header. Simplify this by making a
single test in UnitTests_vtkm_cont_testing for each, which can now be
compiled for and tested on a device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
This header file contained tests for a bunch of fancy array handles so
that they could be compiled for each device. These tests were bunched
together because they were replicated for each device implementation,
which was a hassle. However, having a bunch of tests crammed together is
problematic for a number of reasons.
The new testing no longer has a need to make a separate test for each
device. Thus, the tests for the individual devices are removed, and the
tests are split up and added to the basic vtkm_cont tests. In some
cases, individual tests already existed there as well (probably because
the developer did not see the test).
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
Previously, each device adapter implementation had their own version of
this test by including a common header. Simplify this by making a single
test in UnitTests_vtkm_cont_testing, which can now be compiled for and
tested on a device.
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
We have been noticing occasional failures of UnitTestTimer on the
dashboard for CUDA devices. The timer seems to be recording less time
than is actually elapsed.
The problem might be that the CUDA timer actually inserts fences to the
CUDA stream rather than record the current time. Thus, the actual time
might start after some pending operations complete.
To attempt to match the UnitTestTimer measurements closer to wall-clock
time, add a synchronize before starting the timer.
f598656d5 Enable reallocation of ArrayHandleBasic with moved std::vector
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2811
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.
It is possible to create an `ArrayHandleBasic` from a `std::vector`. It
is possible to move the `vector` into the `ArrayHandle` such that the
`ArrayHandle` takes over the memory. When you do this, the `ArrayHandle`
should be able to resize the data if necessary. However, this was not
working.
There were actually 3 problems that were colluding to lead to this
incorrect behavior.
1. The `Buffer` object was not allowing the reallocation of pinned data.
Pinned data means that the `Buffer`'s memory is pointing to some user
data that should stay where it is. Instead, the `Buffer` should attempt
to reallocate the pinned data using its registered realloc method. This
registered realloc method should be the think to throw the exception if
reallocation is not supported. (Technically, the memory doesn't really
need to be pinned since the data is moved and the user no longer has
direct access to it. But for implementation reasons, moved `vector` data
is pinned.)
2. The `InvalidRealloc` function was not properly throwing an exception.
This was not noticed since `Buffer` was inappropriately throwing an
exception for it.
3. The reallocation method `StdVectorReallocater` had a bad assert that
crashed the program during reallocation.
nvcc is giving me lots of annoying warnings about unused functions.
Typically, this warning is given when a function declared as static or
in an anonymous namespace is never used. The "functions" in question are
not really functions. They are templated methods (in a class in an
anonymous namespace).
Specificaly, I'm getting errors like this:
```
/.../vtkm/cont/testing/UnitTestArrayHandleDecorator.cxx(96): warning #177-D: function "<unnamed>::DecoratorTests::InvertibleDecorImpl::CreateFunctor(PortalTs&&...) const [with PortalTs=<vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleCounting<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandleConstant<signed char>>, vtkm::cont::internal::decor::GetWritePortalType<vtkm::cont::ArrayHandle<vtkm::Int8, vtkm::cont::StorageTagBasic>>>]" was declared but never referenced
```
That said, these warnings appear to be an annoying but harmless bug in
nvcc. This warning is in error because
1. The method in question is _definitely_ being used.
2. I'm pretty sure this warning should not be given for a templated
method even if it was never used. SFINAE alone should be enough
justification to allow this to exist without warning.
The easiest way around the spurious error is to declare these structures
in a namespace with a name.
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 `UnitTestAlgorithm` test was running several device algorithms, but
it was not checking the results of any of them. (In fact, it was not
even setting values in the input arrays.) So, it verified that the
execution did not crash, but did not verify correctness.
Add checks to the results to make sure this executed correctly. (Part of
the reason for this change was a warning that popped up because a result
value was never used.)
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.
9ea11440e Do not require `VecTraits` for `UnknownArrayHandle` components
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Dave Pugmire <dpugmire@gmail.com>
Merge-request: !2778
Originally `MakeTestDataSet.h` was header-only code. This was changed to
put its functionality into a library. The obvious library to put it in
was `vtkm_cont_testing`.
The problem is that there is some external code that is (unadvisably)
adding this header to their own code. This code ends up breaking because
it needed to include `vtkm_cont_testing`, which was not needed before.
As a workaround, there was a CMake interface link that caused external
code linking in `vtkm_cont` to also link in `vtkm_cont_testing`. This
works OK, but creates something of a circular dependency. CMake itself
has no problem with this, because `vtkm_cont` did not itself depend on
`vtkm_cont_testing`; only things that linked to `vtkm_cont` also had to
link to `vtkm_cont_testing`.
Unfortunately, some Ascent CMake script was trying to trace down
dependencies and ran into an infinite loop. So this solution was not so
great for them.
Get around the problem by just adding the `MakeTestDataSet` code
directly to `vtkm_cont` (for now).
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.
The enumerations in `vtkm::cont::Field::Association` were renamed in the
previous commit. The old names still exist, but are deprecated. Change
the rest of the code to use the new names.
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).
Recent changes to VTK-m include changes to MakeDataSet.h that require
the vtkm_cont_testing library to be loaded. This is problematic for
software using an earlier minor revision as they do not expect to need
to include this library.
For now, include vtkm_cont_testing in the interface of vtkm_cont so that
downstream code will load it. This should be a temporary solution. As we
move to new versions of VTK-m, we should break this link and require
downstream components to include it themselves.
This is mostly to support external code that expects deprecated
behavior. UnknownCellSet/UncertainCellSet replace DynamicCellSet. In the
deprecated class, you could use `ResetCellSetList` without having to
include a secondary file. It would be better to support that now so the
minor change does not break things.
In pretty much any practical circumstance, whenusing `ListAll` or
`ListAny`, you have a list of types on which you run some sort of
predicate on each item in the list to determine whether any or all of
the items match the predicate. To make this easier, add a second
argument to `ListAll` and `ListAny` to provide a predicate that will
automatically be added.
If no predicate is given, then the operation is run directly on the
list. This is implemented by just using an identity operation.
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.
5cb9792bd SurfaceNormal -> SurfaceNormals
b2947a1d7 Improve deprecation support of CellMeasures
5b7893a3f Support deprecated MeshQuality features
d22a509b5 Split CoordinateSystemTransform.h
c238cfea5 Improve deprecation support for moved or renamed headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2718
VTK-m has a deprecation method that supports API changes in minor
releases. When an API change is made, the old API is marked with the
VTKM_DEPRECATED macro. If code attempts to use the old API, it still
works, but the compiler issues a warning that the thing is deprecated
and where to find the new API.
We have recently run into an issue when the API changes have a header
file renamed or moved. We still keep the old header file with the old
API, so code including that file will still work. However, sometimes
code expected the contents of that header file without directly
including that header file. In these cases, the code could get an error
about missing classes.
As an example, consider the change from `DynamicCellSet` to
`UnknownCellSet`/`UncertainCellSet`. The deprecated `DynamicCellSet` is
still around. But there is a lot of code that did not directly include
DynamicCellSet.h. This header file was necessarily included by
DataSet.h. Now, when this code uses `vtkm::cont::DynamicCellSet`, you
get a confusing error that the class does not exist. Backward
compatibility broken.
In response to this, we should be more careful about where we put the
deprecated API. Instead of containing the deprecated API, moved headers
should be empty except for a warning and an inclusion of the new header
file. The deprecated API should be moved to the new header file. For
example, in the case of `DynamicCellSet`, the implementation for the
deprecated `DynamicCellSet` is moved to UnknownCellSet.h, which is
included by anything that was including DynamicCellSet.h before.
If you have a really long list, compilers might error out if you have a
recursive operation on it. Such an error can be confusing, so for now
create an error if the list is too long.
To serialize an `UnknownArrayHandle`, a pair of lists were created to
specify all possible value and storage types. These were then used in an
`UncertainArrayHandle::CastAndCall`, which would in turn take the cross
of these two lists. This resulted in a _really_ long list that gave
compilers trouble.
Reduce the size of the list by separating out value types by the number
of components, which can be easily deduced.
The `StorageListEfficientExtract` type is never used in
`UnitTestSerializationArrayHandle`. Although these types are used,
because they all support efficient component extraction from the array,
there is no need to treat them special. As such, this list was never
used.
When calling `ArrayExtractComponent`, some arrays cannot really have a
component extracted. In this case there is a fallback and a warning is
generated.
Of course it is good to test this behavior. The
`UnitTestArrayExtractComponent` does test this and as such generates
this warning (intentionally). Add a note to the output that this warning
is expected.
`ArrayHandleCast` was giving warnings about casting to a type that could
not hold the range to the source even when that was not true. The
problem was it was using `std::numeric_limits::min` for the lower end of
the range. But for floating point values, `min` is not really `min`.
Rather, it is the smallest representable number. (This is probably a C++
bug we are stuck with.) You really need to use `lowest`.
The actually serialization was not doing any inefficient component
extraction, but the array handle comparisons were. This made it hard to
verify that the actual serialization was not being slow. Fixed the
comparison to make sure that it only used efficient paths.
One of the tests was to make sure that the `ArrayHandleMultiplexer` is
working in the exec environment. It was doing this with an `ArrayCopy`.
However, the `ArrayCopy` was falling back to the host, so the test was
not doing what was expected.
Now use `DeviceAdapterAlgorithm::Copy` to force the array to work on the
device.
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.
Before, `ArrayExtractComponent` only worked with `Vec` types. Anything
that was not specifically a `Vec` was assumed to be a basic component
even if it had `VecTraits`. This was changed to extract components out
of anything that has `VecTraits`. The assumption is that all components
of the Vec-like object are packed tightly in the object.
This allows `ArrayExtractComponent` to work with objects like
`vtkm::Range` and `vtkm::Bounds` and extract their parts as expected.
The `ArrayCopy` method has been changed to be precompiled. It handles
most standard array types. But there are some special `ArrayHandle`
types that are not correctly handled, and these go to a slow fallback.
Find places in the code that use that fallback and fix them.
There are also some instances of replacing an `ArrayHandleCounting` with
an `ArrayHandleIndex`. This change is probably not strictly necessary to
make the `ArrayCopy` faster, but when it can be used `ArrayHandleIndex`
is generally better.
Many arrays decorate other arrays but still allow an efficient component
extraction. However, the component can only be extracted if it can be
efficiently extracted from the array being decorated. In this case, the
array reported that it could efficiently extract even though it could
not.
Fixed this by having the `ArrayExtractComponentImpl` classes inherit
from the respective superclass. This will in turn inhert the
`ArrayExtractComponentImplInefficient` if it is the base class.
There are some common uses of `ArrayCopy` that don't use basic arrays.
Rather than move away from `ArrayCopy` for these use cases, compile a
special fast path for these cases.
This required some restructuring of the code to get the template
resolution to work correctly.
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.
There was a precompiled version of mapping permutations in the
filter library. However, there are reasons to be able to copy
a permutation of an array outside of filters. So add the
capability to the more general filter library.
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
The initial implementation of `MergePartitionedDataSet` would grow each
array as it was generated. As each partition was revisited, the arrays
being merged would be reallocated and data appended to the end. Although
this works, it is slower than necessary. Each reallocation has to copy
the previously saved data into the newly allocated memory space.
This new implementation first counts how big each array should be and
then copies data from each partition into the appropriate location of
each dataset.
Also changed the templating of how fields are copied so that all field
types are supported, not just those in the common types.
The `DynamicCellSet` (and the related `DynamicCellSetBase`) are
deprecated and replaced with `UnknownCellSet` (and `UncertainCellSet`).
Thus, `UnknownCellSet` has some methods inherited from `DynamicCellSet`
but replaced with other functionality. These methods are now marked as
deprecated and their use is removed.
The `DynamicCellSet` class is now marked as deprecated (as is the header
that contains it), and all non-deprecated code is moved to its
`UnknownCellSet` replacement.
Also added a deprecation warning for the VariantArrayHandle.h header
file and deleted a couple inappropriate uses of it.
`UnknownCellSet` is an updated replacement for `DynamicCellSet`. The
next step in the replacement is to change `DataSet` to use the new
class.
Also replaced `DynamicCellSet` with `UnknownCellSet` in a few
places where `DynamicCellSet.h` was not directly included (and
therefore now no longer included at all). This change would have
to be made at some point anyway.
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.
We have been doing a better job at hiding device code (and moving code
into libraries). Smoke out source that no longer needs to be compiled by
device compilers.
Previously, all methods in the `vtkm::cont::testing::Testing` class were
inlined in the header file. This makes sense for the methods that are
templated, but not so much for methods that are not templated.
Although this change provides minimal improvements with compile times
and object sizes (maybe). But the real benefit is that some of these
methods declare static objects. When declared in inlined functions, a
different object will be created for each translation unit. This can
lead to unexpected behavior when multiple versions of a supposed
singleton static object exist.
The replacement method, `AsCellSet`, will not support returning a
reference. However, we can continue to allow the deprecated method to
return the reference and correct that later when we move from the
deprecated method.
Before it was a DynamicCellSetBase<VTKM_DEFAULT_CELL_SET_LIST>. This
change causes some calls to templated DynamicCellSetBase arguments to
fail to resolve, but there were only 4 in the code base. In exchange,
DynamicCellSet requires a lot less characters in its symbol.
ArrayGetValues for ArrayHandleCast needs to be handled specially as an
`UnknownArrayHandle::IsBaseComponentType` check inside the implementation
gives unexpected results for ArrayHandleCast.
With this fix, the values are first copied from the source array type and
then casted to the appropriate type before returning.
Under some circumstances, `IsType` can return false for a type that
exactly matches the type used to create the `UnknownArrayHandle`.
This is because types like `ArrayHandleCast` get converted to
the array they contain. Thus, `IsType` will return false when it
is expected to be true. In most cases, you should use
`CanConvert`. The `IsType` documentation now points you there.
ParaView ends up triggering this in its test suite and the "failure"
mention ends up triggering the "failed test" condition in its test
harness. Reword to read more like a warning than an error.
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.
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.
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.
`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.
5191909b5 Fix MeshQuality to work with CellSetSingleType
ecf36ed39 Fix compile errors in CellSetSingleType::CompleteAddingCells
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2556
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
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.
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.
