The `From` and `To` nomenclature for topology mapping has been confusing for
both users and developers, especially at lower levels where the intention of
mapping attributes from one element to another is easily conflated with the
concept of mapping indices (which maps in the exact opposite direction).
These identifiers have been renamed to `VisitTopology` and `IncidentTopology`
to clarify the direction of the mapping. The order in which these template
parameters are specified for `WorkletMapTopology` have also been reversed,
since eventually there may be more than one `IncidentTopology`, and having
`IncidentTopology` at the end will allow us to replace it with a variadic
template parameter pack in the future.
Other implementation details supporting these worklets, include `Fetch` tags,
`Connectivity` classes, and methods on the various `CellSet` classes (such as
`PrepareForInput` have also reversed their template arguments. These will need
to be cautiously updated.
The convenience implementations of `WorkletMapTopology` have been renamed for
clarity as follows:
```
WorkletMapPointToCell --> WorkletVisitCellsWithPoints
WorkletMapCellToPoint --> WorkletVisitPointsWithCells
```
The `ControlSignature` tags have been renamed as follows:
```
FieldInTo --> FieldInVisit
FieldInFrom --> FieldInMap
FromCount --> IncidentElementCount
FromIndices --> IncidentElementIndices
```
Mask objects allow you to specify which output values should be
generated when a worklet is run. That is, the Mask allows you to skip
the invocation of a worklet for any number of outputs.
Did a bit of renaming of the support classes used for
WorkletPointNeighborhood. First, the OnBoundary tag is changed to
Boundary to match other tags and reflect some changes in the resulting
methods. Also moved the BoundaryState and Neighborhood classes from
vtkm::exec::arg to vtkm::exec to be more accessible. Finally, the
Neighborhood class name was changed to FieldNeighborhood to be more
specific on what role this class plays with neighborhood.
Previously, WorkletPointNeighborhood had a template argument to select
the size of the neighborhood. This change removes that template
argument. Instead, the vtkm::exec::arg::BoundaryState methods now take
in a size parameter when determining when it overlaps the boundary.
If in the future we want to add the ability to select the neighborhood
size at compile-time (for performance reasons), I suggest adding this
template argument to the OnBoundary tag for ExecutionSignature.
Rather than force all dispatchers to be templated on a device adapter,
instead use a TryExecute internally within the invoke to select a device
adapter.
Because this removes the need to declare a device when invoking a
worklet, this commit also removes the need to declare a device in
several other areas of the code.
While making changes to how execution objects work, we had agreed to
name the base object ExecutionObjectBase instead of its original name of
ExecutionObjectFactoryBase. Somehow that change did not make it through.
In order to make the change from the current way execution obejcts are utilized to the new proposed executionObjectFactory process type checks now has to look for the new execution object factory class to check against.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
VTK expects that the tensor fields generated by the gradient of a vector field
to have FORTRAN ordering instead of C ordering.
Discovering this actually uncovered bugs in the Vorticity and QCriterion
implementation where they presumed FORTRAN ordering, and would generate
incorrect results.
Basically we can run the gradient worklet and compute the Divergence, Vorticity,
and QCriterion without ever having to store the gradient tensor in global memory
