Skip to content

Commit

Permalink
Add spatial options to thresh and cyl option to clip (#1281)
Browse files Browse the repository at this point in the history
* add cyl to clip, working on spatial opts for thresh

* more thresh wiring

* wip

* add geom ext fix patch to spack build

* wire up tests for thresh implicit func cases

* fix typo

* remove unneeded header

* thresh dont support inverted plane

* wire up invert option to field threshold case

* container with patched vtk-m

* update containers
  • Loading branch information
cyrush committed May 11, 2024
1 parent d424e4b commit 73258c5
Show file tree
Hide file tree
Showing 26 changed files with 1,736 additions and 89 deletions.
1 change: 1 addition & 0 deletions CHANGELOG.md
Expand Up @@ -16,6 +16,7 @@ and this project aspires to adhere to [Semantic Versioning](https://semver.org/s
- Added a `vtk` extract that saves each mesh domain to a legacy vtk file grouped, with all domain data grouped by a `.visit` file.
- Added WarpX Streamline filter that uses charged particles.
- Added seed population options for particle advection: point, point list, line, and box
- Added a `cylinder` option to the clip filter.

### Changed
- Changed the Data Binning filter to accept a `reduction_field` parameter (instead of `var`), and similarly the axis parameters to take `field` (instead of `var`). The `var` style parameters are still accepted, but deprecated and will be removed in a future release.
Expand Down
10 changes: 5 additions & 5 deletions azure-pipelines.yml
Expand Up @@ -22,11 +22,11 @@
########################

variables:
ubuntu_20_04_tag: alpinedav/ascent-devel:ubuntu-20.04-x86_64-tpls_2024-04-29-sha3234b3
ubuntu_22_04_tag: alpinedav/ascent-devel:ubuntu-22.04-x86_64-tpls_2024-04-29-sha3234b3
ubuntu_20_04_cuda_11_4_3_tag: alpinedav/ascent-devel:ubuntu-20.04-cuda-11.4.3-x86_64-tpls_2024-04-30-shad5b6a9
ubuntu_20_04_cuda_12_1_1_tag: alpinedav/ascent-devel:ubuntu-20.04-cuda-12.1.1-x86_64-tpls_2024-04-30-shad5b6a9
ubuntu_20_04_rocm_6_0_0_tag: alpinedav/ascent-devel:ubuntu-20.04-rocm-6.0.0--x86_64-build-ascent-tpls_2024-04-19-shaee18b8
ubuntu_20_04_tag: alpinedav/ascent-devel:ubuntu-20.04-x86_64-tpls_2024-05-03-sha29a328
ubuntu_22_04_tag: alpinedav/ascent-devel:ubuntu-22.04-x86_64-tpls_2024-05-09-shaa5bd0a
ubuntu_20_04_cuda_11_4_3_tag: alpinedav/ascent-devel:ubuntu-20.04-cuda-11.4.3-x86_64-tpls_2024-05-10-shaa5bd0a
ubuntu_20_04_cuda_12_1_1_tag: alpinedav/ascent-devel:ubuntu-20.04-cuda-12.1.1-x86_64-tpls_2024-05-10-shaa5bd0a
ubuntu_20_04_rocm_6_0_0_tag: alpinedav/ascent-devel:ubuntu-20.04-rocm-6.0.0--x86_64-build-ascent-tpls_2024-05-09-shaa5bd0a


# only build merge target pr to develop
Expand Down
145 changes: 145 additions & 0 deletions scripts/build_ascent/2024_05_03_vtkm-mr3215-ext-geom-fix.patch
@@ -0,0 +1,145 @@
From 49518e5054c607942f644c82a5289e12b0f50476 Mon Sep 17 00:00:00 2001
From: Kenneth Moreland <morelandkd@ornl.gov>
Date: Fri, 3 May 2024 09:22:56 -0400
Subject: [PATCH] Fix bug with ExtractGeometry filter

The `ExtractGeometry` filter was outputing datasets containing
`CellSetPermutation` as the representation for the cells. Although this is
technically correct and a very fast implementation, it is essentially
useless. The problem is that any downstream processing will have to know
that the data has a `CellSetPermutation`. None do (because the permutation
can be on any other cell set type, which creates an explosion of possible
cell types).

Like was done with `Threshold` a while ago, this problem is fixed by deep
copying the result into a `CellSetExplicit`. This behavior is consistent
with VTK.
---
.../changelog/extract-geometry-permutation.md | 13 +++++++
.../testing/UnitTestExtractGeometryFilter.cxx | 13 ++++++-
.../worklet/ExtractGeometry.h | 34 +++++++------------
3 files changed, 37 insertions(+), 23 deletions(-)
create mode 100644 docs/changelog/extract-geometry-permutation.md

diff --git a/docs/changelog/extract-geometry-permutation.md b/docs/changelog/extract-geometry-permutation.md
new file mode 100644
index 0000000000..8a90495f76
--- /dev/null
+++ b/docs/changelog/extract-geometry-permutation.md
@@ -0,0 +1,13 @@
+# Fix bug with ExtractGeometry filter
+
+The `ExtractGeometry` filter was outputing datasets containing
+`CellSetPermutation` as the representation for the cells. Although this is
+technically correct and a very fast implementation, it is essentially
+useless. The problem is that any downstream processing will have to know
+that the data has a `CellSetPermutation`. None do (because the permutation
+can be on any other cell set type, which creates an explosion of possible
+cell types).
+
+Like was done with `Threshold` a while ago, this problem is fixed by deep
+copying the result into a `CellSetExplicit`. This behavior is consistent
+with VTK.
diff --git a/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx b/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
index 675df8f77c..14de333666 100644
--- a/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
+++ b/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
@@ -11,6 +11,7 @@
#include <vtkm/cont/testing/MakeTestDataSet.h>
#include <vtkm/cont/testing/Testing.h>

+#include <vtkm/filter/clean_grid/CleanGrid.h>
#include <vtkm/filter/entity_extraction/ExtractGeometry.h>

using vtkm::cont::testing::MakeTestDataSet;
@@ -41,11 +42,21 @@ public:
vtkm::cont::DataSet output = extractGeometry.Execute(dataset);
VTKM_TEST_ASSERT(test_equal(output.GetNumberOfCells(), 8), "Wrong result for ExtractGeometry");

+ vtkm::filter::clean_grid::CleanGrid cleanGrid;
+ cleanGrid.SetCompactPointFields(true);
+ cleanGrid.SetMergePoints(false);
+ vtkm::cont::DataSet cleanOutput = cleanGrid.Execute(output);
+
vtkm::cont::ArrayHandle<vtkm::Float32> outCellData;
- output.GetField("cellvar").GetData().AsArrayHandle(outCellData);
+ cleanOutput.GetField("cellvar").GetData().AsArrayHandle(outCellData);

VTKM_TEST_ASSERT(outCellData.ReadPortal().Get(0) == 21.f, "Wrong cell field data");
VTKM_TEST_ASSERT(outCellData.ReadPortal().Get(7) == 42.f, "Wrong cell field data");
+
+ vtkm::cont::ArrayHandle<vtkm::Float32> outPointData;
+ cleanOutput.GetField("pointvar").GetData().AsArrayHandle(outPointData);
+ VTKM_TEST_ASSERT(outPointData.ReadPortal().Get(0) == 99);
+ VTKM_TEST_ASSERT(outPointData.ReadPortal().Get(7) == 90);
}

static void TestUniformByBox1()
diff --git a/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h b/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
index 97521335f2..449d7eae60 100644
--- a/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
+++ b/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
@@ -10,11 +10,13 @@
#ifndef vtkm_m_worklet_ExtractGeometry_h
#define vtkm_m_worklet_ExtractGeometry_h

+#include <vtkm/worklet/CellDeepCopy.h>
#include <vtkm/worklet/WorkletMapTopology.h>

#include <vtkm/cont/Algorithm.h>
#include <vtkm/cont/ArrayCopy.h>
#include <vtkm/cont/ArrayHandle.h>
+#include <vtkm/cont/CellSetExplicit.h>
#include <vtkm/cont/CellSetPermutation.h>
#include <vtkm/cont/CoordinateSystem.h>
#include <vtkm/cont/Invoker.h>
@@ -114,28 +116,13 @@ public:
}
};

- ////////////////////////////////////////////////////////////////////////////////////
- // Extract cells by ids permutes input data
- template <typename CellSetType>
- vtkm::cont::CellSetPermutation<CellSetType> Run(const CellSetType& cellSet,
- const vtkm::cont::ArrayHandle<vtkm::Id>& cellIds)
- {
- using OutputType = vtkm::cont::CellSetPermutation<CellSetType>;
-
- vtkm::cont::ArrayCopy(cellIds, this->ValidCellIds);
-
- return OutputType(this->ValidCellIds, cellSet);
- }
-
- ////////////////////////////////////////////////////////////////////////////////////
- // Extract cells by implicit function permutes input data
template <typename CellSetType, typename ImplicitFunction>
- vtkm::cont::CellSetPermutation<CellSetType> Run(const CellSetType& cellSet,
- const vtkm::cont::CoordinateSystem& coordinates,
- const ImplicitFunction& implicitFunction,
- bool extractInside,
- bool extractBoundaryCells,
- bool extractOnlyBoundaryCells)
+ vtkm::cont::CellSetExplicit<> Run(const CellSetType& cellSet,
+ const vtkm::cont::CoordinateSystem& coordinates,
+ const ImplicitFunction& implicitFunction,
+ bool extractInside,
+ bool extractBoundaryCells,
+ bool extractOnlyBoundaryCells)
{
// Worklet output will be a boolean passFlag array
vtkm::cont::ArrayHandle<bool> passFlags;
@@ -149,7 +136,10 @@ public:
vtkm::cont::Algorithm::CopyIf(indices, passFlags, this->ValidCellIds);

// generate the cellset
- return vtkm::cont::CellSetPermutation<CellSetType>(this->ValidCellIds, cellSet);
+ vtkm::cont::CellSetPermutation<CellSetType> permutedCellSet(this->ValidCellIds, cellSet);
+
+ vtkm::cont::CellSetExplicit<> outputCells;
+ return vtkm::worklet::CellDeepCopy::Run(permutedCellSet);
}

vtkm::cont::ArrayHandle<vtkm::Id> GetValidCellIds() const { return this->ValidCellIds; }
--
GitLab

1 change: 1 addition & 0 deletions scripts/build_ascent/build_ascent.sh
Expand Up @@ -363,6 +363,7 @@ if [ ! -d ${vtkm_src_dir} ]; then
# apply vtk-m patch
cd ${vtkm_src_dir}
patch -p1 < ${script_dir}/2023_12_06_vtkm-mr3160-rocthrust-fix.patch
patch -p1 < ${script_dir}/2024_05_03_vtkm-mr3215-ext-geom-fix.patch
cd ${root_dir}
fi

Expand Down
@@ -0,0 +1,145 @@
From 49518e5054c607942f644c82a5289e12b0f50476 Mon Sep 17 00:00:00 2001
From: Kenneth Moreland <morelandkd@ornl.gov>
Date: Fri, 3 May 2024 09:22:56 -0400
Subject: [PATCH] Fix bug with ExtractGeometry filter

The `ExtractGeometry` filter was outputing datasets containing
`CellSetPermutation` as the representation for the cells. Although this is
technically correct and a very fast implementation, it is essentially
useless. The problem is that any downstream processing will have to know
that the data has a `CellSetPermutation`. None do (because the permutation
can be on any other cell set type, which creates an explosion of possible
cell types).

Like was done with `Threshold` a while ago, this problem is fixed by deep
copying the result into a `CellSetExplicit`. This behavior is consistent
with VTK.
---
.../changelog/extract-geometry-permutation.md | 13 +++++++
.../testing/UnitTestExtractGeometryFilter.cxx | 13 ++++++-
.../worklet/ExtractGeometry.h | 34 +++++++------------
3 files changed, 37 insertions(+), 23 deletions(-)
create mode 100644 docs/changelog/extract-geometry-permutation.md

diff --git a/docs/changelog/extract-geometry-permutation.md b/docs/changelog/extract-geometry-permutation.md
new file mode 100644
index 0000000000..8a90495f76
--- /dev/null
+++ b/docs/changelog/extract-geometry-permutation.md
@@ -0,0 +1,13 @@
+# Fix bug with ExtractGeometry filter
+
+The `ExtractGeometry` filter was outputing datasets containing
+`CellSetPermutation` as the representation for the cells. Although this is
+technically correct and a very fast implementation, it is essentially
+useless. The problem is that any downstream processing will have to know
+that the data has a `CellSetPermutation`. None do (because the permutation
+can be on any other cell set type, which creates an explosion of possible
+cell types).
+
+Like was done with `Threshold` a while ago, this problem is fixed by deep
+copying the result into a `CellSetExplicit`. This behavior is consistent
+with VTK.
diff --git a/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx b/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
index 675df8f77c..14de333666 100644
--- a/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
+++ b/vtkm/filter/entity_extraction/testing/UnitTestExtractGeometryFilter.cxx
@@ -11,6 +11,7 @@
#include <vtkm/cont/testing/MakeTestDataSet.h>
#include <vtkm/cont/testing/Testing.h>

+#include <vtkm/filter/clean_grid/CleanGrid.h>
#include <vtkm/filter/entity_extraction/ExtractGeometry.h>

using vtkm::cont::testing::MakeTestDataSet;
@@ -41,11 +42,21 @@ public:
vtkm::cont::DataSet output = extractGeometry.Execute(dataset);
VTKM_TEST_ASSERT(test_equal(output.GetNumberOfCells(), 8), "Wrong result for ExtractGeometry");

+ vtkm::filter::clean_grid::CleanGrid cleanGrid;
+ cleanGrid.SetCompactPointFields(true);
+ cleanGrid.SetMergePoints(false);
+ vtkm::cont::DataSet cleanOutput = cleanGrid.Execute(output);
+
vtkm::cont::ArrayHandle<vtkm::Float32> outCellData;
- output.GetField("cellvar").GetData().AsArrayHandle(outCellData);
+ cleanOutput.GetField("cellvar").GetData().AsArrayHandle(outCellData);

VTKM_TEST_ASSERT(outCellData.ReadPortal().Get(0) == 21.f, "Wrong cell field data");
VTKM_TEST_ASSERT(outCellData.ReadPortal().Get(7) == 42.f, "Wrong cell field data");
+
+ vtkm::cont::ArrayHandle<vtkm::Float32> outPointData;
+ cleanOutput.GetField("pointvar").GetData().AsArrayHandle(outPointData);
+ VTKM_TEST_ASSERT(outPointData.ReadPortal().Get(0) == 99);
+ VTKM_TEST_ASSERT(outPointData.ReadPortal().Get(7) == 90);
}

static void TestUniformByBox1()
diff --git a/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h b/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
index 97521335f2..449d7eae60 100644
--- a/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
+++ b/vtkm/filter/entity_extraction/worklet/ExtractGeometry.h
@@ -10,11 +10,13 @@
#ifndef vtkm_m_worklet_ExtractGeometry_h
#define vtkm_m_worklet_ExtractGeometry_h

+#include <vtkm/worklet/CellDeepCopy.h>
#include <vtkm/worklet/WorkletMapTopology.h>

#include <vtkm/cont/Algorithm.h>
#include <vtkm/cont/ArrayCopy.h>
#include <vtkm/cont/ArrayHandle.h>
+#include <vtkm/cont/CellSetExplicit.h>
#include <vtkm/cont/CellSetPermutation.h>
#include <vtkm/cont/CoordinateSystem.h>
#include <vtkm/cont/Invoker.h>
@@ -114,28 +116,13 @@ public:
}
};

- ////////////////////////////////////////////////////////////////////////////////////
- // Extract cells by ids permutes input data
- template <typename CellSetType>
- vtkm::cont::CellSetPermutation<CellSetType> Run(const CellSetType& cellSet,
- const vtkm::cont::ArrayHandle<vtkm::Id>& cellIds)
- {
- using OutputType = vtkm::cont::CellSetPermutation<CellSetType>;
-
- vtkm::cont::ArrayCopy(cellIds, this->ValidCellIds);
-
- return OutputType(this->ValidCellIds, cellSet);
- }
-
- ////////////////////////////////////////////////////////////////////////////////////
- // Extract cells by implicit function permutes input data
template <typename CellSetType, typename ImplicitFunction>
- vtkm::cont::CellSetPermutation<CellSetType> Run(const CellSetType& cellSet,
- const vtkm::cont::CoordinateSystem& coordinates,
- const ImplicitFunction& implicitFunction,
- bool extractInside,
- bool extractBoundaryCells,
- bool extractOnlyBoundaryCells)
+ vtkm::cont::CellSetExplicit<> Run(const CellSetType& cellSet,
+ const vtkm::cont::CoordinateSystem& coordinates,
+ const ImplicitFunction& implicitFunction,
+ bool extractInside,
+ bool extractBoundaryCells,
+ bool extractOnlyBoundaryCells)
{
// Worklet output will be a boolean passFlag array
vtkm::cont::ArrayHandle<bool> passFlags;
@@ -149,7 +136,10 @@ public:
vtkm::cont::Algorithm::CopyIf(indices, passFlags, this->ValidCellIds);

// generate the cellset
- return vtkm::cont::CellSetPermutation<CellSetType>(this->ValidCellIds, cellSet);
+ vtkm::cont::CellSetPermutation<CellSetType> permutedCellSet(this->ValidCellIds, cellSet);
+
+ vtkm::cont::CellSetExplicit<> outputCells;
+ return vtkm::worklet::CellDeepCopy::Run(permutedCellSet);
}

vtkm::cont::ArrayHandle<vtkm::Id> GetValidCellIds() const { return this->ValidCellIds; }
--
GitLab

4 changes: 4 additions & 0 deletions scripts/uberenv_configs/packages/vtk-m/package.py
Expand Up @@ -152,6 +152,10 @@ class VtkM(CMakePackage, CudaPackage, ROCmPackage):
# Patch
patch("diy-include-cstddef.patch", when="@1.5.3:1.8.0")

# VTK-m PR #3215
# https://gitlab.kitware.com/vtk/vtk-m/-/merge_requests/3215
patch("2024_05_03_vtkm-mr3215-ext-geom-fix.patch", when="@2.1:")

# VTK-M PR#2972
# https://gitlab.kitware.com/vtk/vtk-m/-/merge_requests/2972
patch("vtkm-cuda-swap-conflict-pr2972.patch", when="@1.9 +cuda ^cuda@12:")
Expand Down

0 comments on commit 73258c5

Please sign in to comment.