The fields in a `DataSet` are indexed from `0` to `GetNumberOfFields() - 1`.
It is natural to assume that the fields will be indexed in the order that
they are added, but they are not. Rather, the indexing is arbitrary and can
change any time a field is added to the dataset.
To make this more clear, Doxygen documentation is added to the `DataSet`
methods to inform users to not make any assumptions about the order of
field indexing.
c8cc834b9 gitlab-ci: add missing platform and feature tags to ascent job
23c0eadb8 Merge branch 'ci-arch-tags-1.9' into ci-arch-tags
054661f68 gitlab-ci: use arch-specific tags for OS selection
4dd268c58 Merge branch 'ci-arch-tags-1.8' into ci-arch-tags-1.9
4c010f6c8 Merge branch 'ci-arch-tags-1.7' into ci-arch-tags-1.8
c3f4c924d gitlab-ci: add missing feature tag for doxygen submission
7766bbc3c gitlab-ci: use arch-specific tags for OS selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2952
054661f68 gitlab-ci: use arch-specific tags for OS selection
4dd268c58 Merge branch 'ci-arch-tags-1.8' into ci-arch-tags-1.9
4c010f6c8 Merge branch 'ci-arch-tags-1.7' into ci-arch-tags-1.8
c3f4c924d gitlab-ci: add missing feature tag for doxygen submission
7766bbc3c gitlab-ci: use arch-specific tags for OS selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2952
4c010f6c8 Merge branch 'ci-arch-tags-1.7' into ci-arch-tags-1.8
c3f4c924d gitlab-ci: add missing feature tag for doxygen submission
7766bbc3c gitlab-ci: use arch-specific tags for OS selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2952
c3f4c924d gitlab-ci: add missing feature tag for doxygen submission
7766bbc3c gitlab-ci: use arch-specific tags for OS selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2952
* ci-arch-tags-1.9:
gitlab-ci: use arch-specific tags for OS selection
gitlab-ci: add missing feature tag for doxygen submission
gitlab-ci: use arch-specific tags for OS selection
* origin/master: (76 commits)
PerfTest: Fixes report.json name
README: Updated VTK-m example for vtkm 2.0.0
Hide Particle class members
cmake: namespace vtkm export targets
CI: CUDA build jobs dont need cuda-rt
Change auto seed behavior in PerlinNoise source
Split up the filters benchmark tests
Add performance configuration options
Rename NewFilter base classes to Filter
Handle random seed generation better for PerlinNoise
Make source parameters more clear
Remove Filter::CreateResult that takes a vector of CoordinateSystems
Change wavelet dim to 256 and numPart to 1.
Add header for vtkm::cont::PartitionedDataSet
Update ReleaseRoadmap; add instructions NewRelease
Change default waveletdim back to 256.
Add multiblock benchmarks for filters.
Fix unresolved external symbol __popcnt on win-arm64
Fix unresolved external symbol __popcnt on win-arm64
Update CMakeLists.txt
...
The member variables of the `vtkm::Particle` classes are now hidden. This
means that external code will not be directly able to access member
variables like `Pos`, `Time`, and `ID`. Instead, these need to be retrieved
and changed through accessor methods.
This follows standard C++ principles. It also helps us future-proof the
classes. It means that we can provide subclasses or alternate forms of
`Particle` that operate differently. It also makes it possible to change
interfaces while maintaining a deprecated interface.
049d0cca8 cmake: namespace vtkm export targets
d4fc84f12 CI: CUDA build jobs dont need cuda-rt
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2939
The PerlinNoise source has a mode where if a seed is not set, it will
choose a new seed every time it is executed. It did this by using the
value 0 as an indicator to do this (and initializing the Seed to 0).
However, there was a problem with one of the benchmarks that was
specifically setting the seed to 0 and getting unexpected results.
Fix the problem by adding a separate, hidden member of the PerlinNoise
class that keeps track of whether to generate new seeds or not.
This should help catch regressions that only affect a single filter. It
also allows us to set up a partitioned test that has many small blocks.
It also fixes an issue we were seeing on the dashboard where the
contour benchmark was apparently running out of resources.
Added a name option that allows the same benchmark executable to be used
in multiple benchmark tests. This allows the benchmarks to be separated.
Also added an option to pass customized arguments to the benchmark
executable to overwrite the default values.
aa7b83bb2 Handle random seed generation better for PerlinNoise
84bc72312 Make source parameters more clear
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !2933
During the VTK-m 1.8 and 1.9 development, the filter infrastructure was
overhauled. Part of this created a completely new set of base classes. To
avoid confusion with the original filter base classes and ease transition,
the new filter base classes were named `NewFilter*`. Eventually after all
filters were transitioned, the old filter base classes were deprecated.
With the release of VTK-m 2.0, the old filter base classes are removed. The
"new" filter base classes are no longer new. Thus, they have been renamed
simply `Filter` (and `FilterField`).
Originally, most of the sources used constructor parameters to set the
various options of the source. Although convenient, it was difficult to
keep track of what each parameter meant. To make the code more clear,
source parameters are now set with accessor functions (e.g.
`SetPointDimensions`). Although this makes code more verbose, it helps
prevent mistakes and makes the changes more resilient to future changes.