05fc1747e Make deprecated tags more descriptive
b92566cdd Convert `std::endl` to `'\n'`
b8b958a98 Get rid of CellSetStructured.hxx
f4bc3002b Fix compiler error with `constexpr` method
4d8f05bae Update CellSetExtrude to not specify exec types by device
3962e73b0 Fix issues with class specialization
c55d15f39 Deprecate ArrayHandle::ExecutionTypes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2401
e4241aa53 Make matrix unit tests less verbose.
bba3d29c2 Remove UB from Matrix.h, and replace by quiet NaNs.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !2402
One of the MSVC builds was giving template resolution problems for one
of the methods declared non-inline for no discernable reason. It sounds
like a compiler bug. Rather than try to work around the issue, just
move the declaration inline.
In fact, all the methods are really small (only 1 or 2 lines). Just
delete the .hxx file and simplify things.
The `GetMaxNumberOfNeighbours` of the `MeshStructure*` classes was
declared `constexpr`. This was causing some compiler errors.
I think the problem is actually a bug with GCC (https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=66297). Whether it is a compiler bug or not,
there does not seem to be a large value to declaring this method
`constexpr`, so I just removed the keyword.
Somewhere during this edit I removed a header file that didn't strictly
need to be there. This caused me to have to add
```cpp
```
in several places in the code.
The newer version of `ArrayHandle` no longer supports different types of
portals for different devices. Thus, the `ReadPortalType` and
`WritePortalType` are sufficient for all types of portals across all
devices.
This significantly simplifies supporting execution objects on devices,
and thus this change also includes many changes to various execution
objects to remove their dependence on the device adapter tag.
Some (but not all) versions of visual studio seem to have a bug that
causes a syntax error when using the deprecated attribute in a templated
constructor.
The actual code for AtomicArrayExecutionObject does not need to be
specialized by the device. The functionality is implemented by calling
the vtkm::Atomic* methods, which are properly implemented on each
device.
Unfortunately, there is no way to specify when copying `RecombineVec`s
whether we wish to allow precision loss in conversions. Because
sometimes we need them, disable the warnings.
It used to be the case where you needed to call `ResetTypes` on a
`VariantArrayHandle` before using `ArrayCopy` to limit the types it gets
compiled for. However, there is now a general form for
`UnknownArrayHandle`, so `ResetTypes` no longer does anything useful in
this case. Remove the use of that.
Rather than copy every type to every other type, only copy for the same
base type or copy to/from FloatDefault. This should reduce the amount of
code generated by a lot.
This reduces the size of the .o for ArrayCopy.cxx on my mac from
21MB to 7.7MB.
Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and
copies them for (almost) any `ArrayHandle` type.
The code uses `CastAndCallWithExtractedArray` to reduce the total number
of copy conditions to about 100, which are all precompiled into the
library. On a debug build on my mac, this creates a .o file of 21MB.
That's not great, but not terrible. Hopefully, this can be used to
consolidate copy implementations elsewhere.
The circular dependency came from UnknownArrayHandle.h needing
VTKmDefaultTypes.h, which needed all the cell set types. Some of those
cell sets used ArrayCopy in templated functions. Changed those functions
to directly deep copy the ArrayHandle.
This provides the ability to convert an array handle of an unknown value
type to an array handle that has `vtkm::FloatDefault` as its base
component type. Thus subsequently lets you pull the components as
`vtkm::FloatDefault` without having to worry about type conflicts.
There was an error that caused deprecation warnings in VTK-m to be
suppressed, which meant that many uses of deprecated features went
unnoticed. This fixes those deprecation warnings.
The majority of the warnings were caused by the use of the deprecated
`Cast`, `CopyTo`, and `ResetTypes` methods of `UnknownArrayHandle` (or
`VariantArrayHandle`). Both `Cast` and `CopyTo` have been subsumed by
`AsArrayHandle` (to make the functionality more clear). `ResetTypes` now
requires a second template argument to define the storage types to try.
Also fixed some issues with `SerializableField` being deprecated.
This class is no longer necessary because `Field` can now be directly
serialized.
Field.h had a runaway deprecation suppression where the pragmas to
suppress deprecation warnings were turned on but not properly turned
off. This caused deprecation warnings to be turned off for anything
including Field.h (directly or indirectly), and consequently lots of use
of deprecated features went unnoticed.
There are several places in the ray casting library that require
operating on a field that we know is a scalar field. Previously, these
were all independently cast to an uncertain array of the limited types.
Rather than have independent calls everywere, make a consolidated
function that does the same operation for everyone.
This fixes an issue with using a deprecated version of a method. It also
makes it possible to quickly change types in the future.
081f8aaea reformat if statements, add comments on the HDF5 macros
31aa46706 Merge branch 'master' into hdf5_image_io
e65c0713b move #include of hdf5.h into .cxx files
ff0b8fd0b changed to CMake files based on Robert's feedback
ca0ce4de7 Merge branch 'master' into hdf5_image_io
23a95f864 exclude header files from install check when it is not enabled
d81f08eed correct copyright mesage
fb6c9afe7 uncomment ubuntu1805_cuda image
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Merge-request: !2371
