Repository navigation
Conversation
Adds cuNCorr (submodule Tools/cuNCorr) as a selectable DIC backend. cuNCorr runs
on CUDA when a device is present, else its CPU backend — numerically identical
(shared cores; cuNCorr's cuda_parity_test gates it).
- Tools/cuNCorr submodule; CMake builds the standalone `cuncorr` lib
(tests/apps/its-own-CppNCorr disabled; cppxdic keeps its ncorr target).
Configure -DCUNCORR_BACKEND=CUDA on a GPU node.
- Adapter src/dic/cuncorr_dic.{h,cpp}: runs cuNCorr sequence mode (fixed
reference, warm-started frames) and packages results as ncorr::DIC_analysis_output
(raw Lagrangian/pixel, reduced grid). Grids align exactly with ncorr
((dim-1)/sf+1 == ceil(dim/sf); reduced (r,c) <-> full (r*sf,c*sf)), so the
.bin + StepE reconstruction consume it unchanged.
- Dispatch at both DIC call sites (single_dic_workflow.cpp, step_d_workflow.cpp)
on Config::dic_engine ("cuncorr" default | "ncorr" legacy) + cuncorr_seed_search.
- tests/cuncorr_adapter_test.cpp (opt-in -DBUILD_CUNCORR_ADAPTER_TEST=ON):
synthetic translation recovery through the adapter.
Verified: cppxdic + singledic + adapter test all build & link against cuncorr+ncorr
(CPU). Runtime of OpenCV-linked binaries blocked locally by a broken brew
protobuf dylib (env, not code); runs on the cluster.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CI failures on PR #38: - build/test/coverage: add_subdirectory(Tools/cuNCorr) failed because the CI runner does not check out the private cuNCorr submodule. cuNCorr is now OPTIONAL: guarded on Tools/cuNCorr/CMakeLists.txt existing (+ new option CPPXDIC_USE_CUNCORR, default ON). Absent -> ncorr-only build; the adapter source, its link, and the dispatch branches are gated behind CPPXDIC_HAVE_CUNCORR in single_dic_workflow.cpp and step_d_workflow.cpp. - lint: clang-format (18.1.8) the three added files. Also switch the cuNCorr submodule URL to https (consistent with CppNCorr; works with a token that has org access). Verified locally: builds with cuNCorr ENABLED (adapter compiled) and with -DCPPXDIC_USE_CUNCORR=OFF (ncorr-only, what CI does). clang-format --dry-run --Werror clean on the added files. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… public) cuNCorr is a public repo, so CI can fetch the submodule. - build job: checks out Tools/cuNCorr, compiles cppxdic WITH the cuNCorr engine (CPPXDIC_HAVE_CUNCORR), and runs the adapter synthetic-recovery test (-DBUILD_CUNCORR_ADAPTER_TEST=ON) — validates run_cuncorr_dic end to end on CPU. - test + coverage jobs: pinned ncorr-only (-DCPPXDIC_USE_CUNCORR=OFF) so the ohtcfrp golden regressions keep validating the CppNCorr reference engine (cuNCorr is a different algorithm with different numbers). Verified locally: the build-job commands build cppxdic + cuncorr_adapter_test with the engine ENABLED. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- deploy/cluster/cppxdic_gpu.def: single Apptainer image on nvidia/cuda:12.4.1 building cuNCorr with -DCUNCORR_BACKEND=CUDA for sm 70/75/80/86/89 (all Manneback GPU types) + hdf5-tools (h5diff) and gdb + a RelWithDebInfo cppxdic_dbg for cluster debugging. One image serves GPU and CPU runs (cuNCorr falls back to its CPU backend without --nv), keeping binaries identical for bit-comparisons. - CMakeLists: turn CUDA_SEPARABLE_COMPILATION OFF on the cuncorr target — the non-CUDA executables (cppxdic, singledic) cannot generate the device-link step an rdc static lib requires (and CMake < 3.23 cannot resolve device symbols on static libraries); cuNCorr's kernels are TU-local so rdc was never needed. Without this the link fails with undefined __cudaRegisterLinkedBinary_* symbols. - generate_ncorr_bin: call H5Rdereference2 explicitly behind a version guard — Ubuntu 22.04's hdf5 1.10 maps the H5Rdereference macro to the 3-arg v1.8 signature and the build fails inside the container. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two fixes surfaced by the first end-to-end cuNCorr runs:
1. formatOutput used a "value == 0.0 -> invalid" sentinel when building
myDIC2DpairResults Points/CorCoeffVec. ncorr zero-fills invalid points
so it mostly worked, but a VALID point can hold an exact 0.0 — notably
cuNCorr's whole first frame (self-match returns u=v=0 exactly), which
turned Points{1} (the reference seed grid, stored by MATLAB and ncorr
alike) into all-NaN. Validity now comes from each frame's disp ROI mask
(the set of converged points) in fillDirectFrame, the cam2 interpolation
sampler, and the matching check. Behavior-preserving for ncorr.
2. Inter-camera MATCHING calls were dispatched to cuNCorr like tracking.
Camera disparities (~276 px here) far exceed cuNCorr's local coarse
seed search (cuncorr_seed_search, 15 px) — only ncorr's GLOBAL seed
optimization bridges them — so matching silently produced an all-zero
field with an empty valid ROI, cascading into all-NaN cam-def Points,
all-NaN 3D vertices, and a 0-face stitched mesh. Matching calls
(<= 2 current images, not perf-critical) now stay on ncorr; cuNCorr
keeps the frame-series tracking it was designed for.
Verified end-to-end on S09 trial 7: GPU run completes Steps D+E+F in
32 min with healthy cam-def Points (4% NaN, ROI edges only) and the same
stitched mesh (6726 points / 12071 faces) as the ncorr CPU run.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
deploy/cluster/cpugpu/: SLURM harness for the ncorr-CPU vs cuNCorr-GPU study on S09 trials 7/12/25 — isolated per-run dic_paths, explicit dic_engine (the compiled-in default is cuncorr!), engine/backend verification, axes for threads/GPU/exact_matlab/updates/fixed-step/stages, crash-safe meta on home (globalscratch is purgeable). Plus: - compare_bits.sh: bit-level comparison (h5diff on .mat — never md5, the v7.3 userblock embeds timestamps — and cmp on .bin). - compare_dic.cpp: matio-based semantic comparator for MATLAB (v5 + struct-array layout) vs cppxdic (v7.3 + cells) files — recursive walk, NaN-aware, point-matched trajectory mode, DUMP/LIST probes with deep loading of deferred HDF5 data. - results/REPORT.md + summaries: GPU ~4x faster than 32-core CPU at ~15x less memory; GPU bit-deterministic across reps; cuncorr CPU-vs-GPU differences bounded by 1e-12 (all trials); MATLAB agreement sub-0.1 px for the bulk with the boundary band explained by MATLAB's FFT-bcoef border bias (fixed on our side by CppNCorr 4758ad2); full-pipeline Step-E/F bug chain documented. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ption Wire two ncorr_params.txt options into Step-D tracking (both default to the long-standing behavior): - fixed_step_ref = N (>0): force a reference change every N frames — MATLAB ncorr step analysis semantics (stepanalysis.step / step_ref_change). Bumps Tools/CppNCorr to feat/fixed-step-ref, which caps seed segments at N frames in matlab_compute_seed_segment; the existing segment loop does the seed propagation and the exact_matlab_* path chains segments back to the global reference (ncorr_alg_addanalysis port). Verified on S09 t7 (150 frames, step 10): 60 segments = 150/10 x 4 tracking calls, matching MATLAB's recorded dispinfo.stepanalysis exactly. - no_update = false: KEEP_MOST_POINTS preset (with cutoff_corrcoef=0.5 -> correlation-triggered reference updates); default true keeps NO_UPDATE. The tracking call site previously hardcoded true. Study finding (deploy/cluster/cpugpu/results/REPORT.md): reproducing MATLAB's fixed-step structure is numerically WORSE at the 0.1 px level than direct fixed-reference tracking — per-boundary composition differences compound over 15 boundaries — so the production default stays fixed-reference; fixed_step_ref remains available for data where a fixed reference genuinely decorrelates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.