fcd0986c5 Merge branch 'parallel_pathline2' of https://gitlab.kitware.com/dpugmire/vtk-m into parallel_pathline2
ed7358ed2 Kick the dashboard.
6367e4680 Bug fix when pathline rank has 0 ds.
6608a38ee Debugging the dashboard
b4768f06b Bug fix. Must copy particles.
4773b51ca Debug test fail...
982b693ab Forgot to add hxx file.
aa713b565 Support for dist-memory pathlines.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2399
85a7e6ffe gitlab-ci: Use a stable path between build and test jobs on Windows
c612b86dd gitlab-ci: Refactor vcvars settings on Windows jobs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !2400
4d5e829c5 gitlab-ci: Add 'concurrent' tag to Windows jobs
469d57b41 gitlab-ci: Use a specific MSVC version on Windows
2861513ab gitlab-ci: Clarify role of vtkm tag on Windows jobs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !2398
Teach jobs to load the environment for a specific MSVC version, and tag
them accordingly. This allows runners to have multiple versions of MSVC
installed without requiring us to compile on the newer ones right away.
The runners provide the VS 2019 location in a `VS160COMNTOOLS`
environment variable. Use it to avoid requiring a specific VS edition.
Issue: #595
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.
99e613d37 Avoid conversion warnings in `RecombineVec` copy
4c524de62 Fix inverted `ArrayCopy` arguments
fa4da95eb Add changelog for copying UnknownArrayHandle
1faed3712 Remove the use of ResetTypes for ArrayCopy
ad7033684 Change ArrayCopy of UnknownArrayHandle to limit types
916a01d7b Add general `ArrayCopy` between `UnknownArrayHandle`s
26ea2ab42 Break circular dependency of ArrayCopy.h and UnknownArrayHandle.h
990cc9ece Test copying UnknownArrayHandle
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Sujin Philip <sujin.philip@kitware.com>
Merge-request: !2396
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.
