Repository navigation
fix(lammps): register built-in KOKKOS styles - #6054
Zhang-pchao wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 4 remain after this review. 📝 WalkthroughWalkthroughThe LAMMPS build configuration conditionally invokes ChangesLAMMPS style integration
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The change exposes the Kokkos pair styles to LAMMPS style discovery while keeping them guarded for KOKKOS builds. No concrete merge-blocking issue is established. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 1🧪 Generate unit tests (beta)
🛠️ Fix failing CI checks 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
njzjz-bot
left a comment
There was a problem hiding this comment.
Agent: dot
Reviewed exact head 7d93082. No blocking findings in the style-registration change.
Checked both header guard layouts against LAMMPS's current StyleHeaderUtils.cmake marker parser and the generated-style source integration in its CMakeLists.txt. PAIR_CLASS remains the registration branch, nested LMP_KOKKOS guards protect all six markers, and the implementation/version checks remain in the non-registration branch. Regenerating the style source files after RegisterStyles updates the same generated translation units already attached to the LAMMPS target; the COMMAND guard retains the older header-generation-only path.
Local validation: preprocessed both exact-head headers with PAIR_CLASS/LMP_KOKKOS enabled and observed the expected three registrations per header. With KOKKOS disabled, both registration and implementation branches preprocess to empty output. I did not rebuild LAMMPS, run pair calculations, or validate CUDA here; the author's Serial build is distinct from these focused checks.
Summary
Fix built-in DeePMD integration with LAMMPS versions that generate style registration source files as well as headers.
PAIR_CLASSbranch before theLMP_KOKKOSguard so LAMMPS style discovery finds both KOKKOS pair styles.Validation
develop(b7ad70cf956c), with MPI and the CPU KOKKOS Serial backend.lmp -hlistsdeepmd/kk,deepmd/kk/device,deepmd/kk/host, and the correspondingdpa4spinstyles.The build used an existing compatible DeePMD C library. This change affects style discovery and registration; it does not modify pair calculations. CUDA execution and a complete new DeePMD backend build were not part of this focused test.
Summary by CodeRabbit
CI follow-up (2026-10-07)
The exact-head Read the Docs build fails while installing
doc/requirements.txt, before Sphinx runs: the selected PyTorch headers require C++20, while the current target baseline selects C++17. The same build-standard mismatch appears on all five related contribution heads (#6051 through #6055). Existing issue #6048 and PR #6049 already address this compatibility problem; this PR leaves that repair in its independent upstream review. The Read the Docs check remains failed until that dependency is resolved and the build is rerun. The exact-head pre-commit.ci check passes; GitHub Actions still require maintainer approval.