Skip to content

Fixes from the 0.7 rounds on the Mac and jura - #370

Merged
berkgeveci merged 4 commits into
Kitware:mainfrom
berkgeveci:fix/round07-mac
Nov 6, 2026
Merged

berkgeveci merged 4 commits into
Kitware:mainfrom
berkgeveci:fix/round07-mac

Conversation

@berkgeveci

@berkgeveci berkgeveci commented Nov 6, 2026 •

Copy link
Copy Markdown
Collaborator

These are the Tack fixes from the 0.7 rounds on the Mac (CPU and Metal) and on jura (CUDA). Tack itself had no other failures: every other failure was in a test script or an example port.

The commits

  1. test_arrays_protocol: the permutation's ids first. This was found on both machines.
    • test_implicit_arrays_index_from_the_host_as_arrays_do (from f312f1c) built Permutation(stored, ids), but the signature is (ids, base). So float values became ids, read past the three-element id array.
    • In plain mode the test passed, because the host and the kernel read the same garbage. The suite under TACK_DEBUG=1 caught it. CI never runs debug mode.
    • The fix puts the ids first and checks the permutation's values. Permutation takes float ids without complaint; that's unchanged here.
  2. Examples 51 and 52 fetch the OpenFOAM case's directory, not its .foam. This is jura's 87b3a01.
    • Asking _vtk_data.path for OpenFOAM/<case>/<case>.foam fetched only that empty file. On a machine without VTK's data, the reader then had no case.
    • Example 53 already asked for the directory. On jura, both examples pass from an empty cache with this fix.
  3. Device arrays go to VTK only where VTK holds that device's memory. This is jura's 0a040d9, with a changelog entry added.
    • VTK's nightly wheels have DLPack, but their Viskores runs on the CPU alone. They still list CUDA in dlpack_support.supported_device_types(), and refuse CUDA memory only when asked.
    • So on VTK master, every Tack VTK algorithm on a GPU failed handing its output back.
    • The interop now tries a four-value array once per type of device (_vtk_holds), and copies to the host where VTK can't hold the memory. The two interop tests that assumed device memory skip on such a VTK.
    • On jura, VTK master went from 2 failed test_vtk_*.py tests and failures of examples 50-53 on CUDA to all passing. The local CUDA VTK with Viskores' device arrays still shares without a copy (212 passed).

The rounds

The Mac (main at dc4ca7a):

CPU Result
Suite 6768 passed
64-bit ids 3547 passed
L2 cell-fastest 3548 passed
TACK_DEBUG=1 commit 1's failure only
timing 3 passed
Examples 39 passed
Docs' 163 Markdown examples, mkdocs build --strict, lint clean
Metal Result
Suite, one process 9390 passed
Examples 33 passed
round07.py on all 11 real datasets, CPU against Metal 113 rows agree, with the script's own fixes

jura: CUDA, every dataset. The details are in the vault's jura ticket.

On this branch: test_vtk_interop.py and test_arrays_protocol.py pass (44 passed), examples 51 and 52 pass, and lint and the changelog check are clean.

🤖 Generated with Claude Code

Permutation takes (ids, base); the test gave (base, ids), so the six float
values were ids into the three ids, read out of bounds alike by the host
and the kernel. It passed in plain mode on the garbage both read; the suite
under TACK_DEBUG=1 caught it. Now the ids come first, and the permutation's
values are checked.
@berkgeveci berkgeveci added this to the 0.7 milestone Nov 6, 2026
_vtk_data.path fetches what it is given: the empty .foam alone left the
case's other files unfetched and the reader without a case.
The nightly wheels have DLPack and Viskores on the CPU alone: they list
CUDA among supported_device_types() but refuse its memory when asked, so
every VTK algorithm on a GPU failed handing its output back. Try a small
array once per type of device, and copy to the host where VTK cannot hold it.
@berkgeveci berkgeveci changed the title test_arrays_protocol: the permutation's ids first Fixes from the 0.7 rounds on the Mac and jura Nov 6, 2026
@berkgeveci
berkgeveci merged commit 45ccdd3 into Kitware:main Nov 6, 2026
31 checks passed
berkgeveci added a commit that referenced this pull request Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant