With the major revision 2.0 of VTK-m, many items previously marked as
deprecated were removed. If updating to a new version of VTK-m, it is
recommended to first update to VTK-m 1.9, which will include the deprecated
features but provide warnings (with the right compiler) that will point to
the replacement code. Once the deprecations have been fixed, updating to
2.0 should be smoother.
Previously, `DataSet` managed `CoordinateSystem`s separately from `Field`s.
However, a `CoordinateSystem` is really just a `Field` with some special
attributes. Thus, coordiante systems are now just listed along with the
rest of the fields, and the coordinate systems are simply strings that
point back to the appropriate field. (This was actually the original
concept for `DataSet`, but the coordinate systems were separated from
fields for some now obsolete reasons.)
The `VTKM_LOG_SCOPE` macro was not working as intended. It was supposed
to print a log message immediately and then print a second log message
when leaving the scope along with the number of seconds that elapsed
between the two messages.
This was not what was happening. The second log message was being
printed immediately after the first. This is because the scope was taken
inside of the `LogScope` method. The macro has been rewritten to put the
tracking in the right scope.
The name of the methods were changed from `AddGhostCellField` to
`SetGhostCellField` since only one field can be marked as the cell
ghost. Also automatically select a field that matches
`GetGlobalCellFieldName` if nothing else is set.
54f0ef2a8 Support providing a Token to ReadPortal and WritePortal
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2916
It is possible in a `DataSet` to add a point field (or coordinate system)
that has a different number of points than reported in the cell set.
Likewise for the number of cells in cell fields. This is very bad practice
because it is likely to lead to crashes in worklets that are expecting
arrays of an appropriate length.
Although `DataSet` will still allow this, a warning will be added to the
VTK-m logging to alert users of the inconsistency introduced into the
`DataSet`. Since warnings are by default printed to standard error, users
are likely to see it.
When managing portals in the execution environment, `ArrayHandle` uses the
`Token` object to ensure that the memory associated with a portal exists
for the length of time that it is needed. This is done by creating the
portal with a `Token` object, and the associated portal objects are
guaranteed to be valid while that `Token` object exists. This is supported
by essentially locking the array from further changes.
`Token` objects are typically used when creating a control-side portal with
the `ReadPortal` or `WritePortal`. This is not to say that a `Token` would
not be useful; a control-side portal going out of scope is definitely a
problem. But the creation and distruction of portals in the control
environment is generally too much work for the possible benefits.
However, under certain circumstances it could be useful to use a `Token` to
get a control-side portal. For example, if the `PrepareForExecution` method
of an `ExecutionObjectBase` needs to fill a small `ArrayHandle` on the
control side to pass to the execution side, it would be better to use the
provided `Token` object when doing so. This change allows you to optionally
provide that `Token` when creating these control-side portals.
For several versions, VTK-m has had a `Variant` templated class. This acts
like a templated union where the object will store one of a list of types
specified as the template arguments. (There are actually 2 versions for the
control and execution environments, respectively.)
Because this is a complex class that required several iterations to work
through performance and compiler issues, `Variant` was placed in the
`internal` namespace to avoid complications with backward compatibility.
However, the class has been stable for a while, so let us expose this
helpful tool for wider use.
Several revisions ago, the ability to use virtual methods in the
execution environment was deprecated. Completely remove this
functionality for the VTK-m 2.0 release.
`ExecutionWholeArray` is an archaic class in VTK-m that is a thin wrapper
around an array portal. In the early days of VTK-m, this class was used to
transfer whole arrays to the execution environment. However, now the
supported method is to use `WholeArray*` tags in the `ControlSignature` of
a worklet.
Nevertheless, the `WholeArray*` tags caused the array portal transferred to
the worklet to be wrapped inside of an `ExecutionWholeArray` class. This
is unnecessary and can cause confusion about the types of data being used.
Most code is unaffected by this change. Some code that had to work around
the issue of the portal wrapped in another class used the `GetPortal`
method which is no longer needed (for obvious reasons). One extra feature
that `ExecutionWholeArray` had was that it provided an subscript operator
(somewhat incorrectly). Thus, any use of '[..]' to index the array portal
have to be changed to use the `Get` method.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
When you used the `AddHelp` option to `Initialize`, it added a
`--vtkm-help` option and `-h`, but not `--help`, which was weird. It
also avoided adding `--vtkm-help` when `AddHelp` was not used, but did
print out a usage statement under other circumstances.
This changes the behavior to add `--vtkm-help`, `--help`, and `-h` when
`AddHelp` is on and only `--vtkm-help` when it is off.
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.
770fa2964 Reset flag to previous value on exit.
dd16f738e remove example from cmake..
38714972a remove example for threaded multiblocks.
fc8b750e5 Fix type Set --> Get for CPU/GPU threads.
115db2175 fix compile error for cuda.
baac7e1fb Put sync memory into RuntimeDeviceTracker
8455972a0 Turn on thread-safe-ish mem alloc
9f4b786a7 Add option to thread-efficient mem alloc
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2845
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
