[BUG] DeepMD LAMMPS pair styles misinterpret comm_style tiled as CommBrick #5995

Activity

1. dosubot

   added

   bug

   on Aug 23, 2026
2. dosubot commented on Aug 23, 2026

   

   dosubotBot

   on Aug 23, 2026 – with DosuBot

   More actions

   @njzjz-bot the bug report is accurate for the deepmd and deepspin pair styles. Here's confirmation from the current source:

   PairDeepMD::compute() unconditionally casts comm to CommBrickDeepMD* at line 144, then passes the brick-only protected fields (nswap, sendnum, recvnum, firstrecv, sendlist, sendproc, recvproc) into the InputNlist constructor [1]. The CommBrickDeepMD friend class in pair_deepmd.h exists solely to expose those protected CommBrick members. CommTiled stores the same concepts with different pointer ranks (int **sendnum, int ***sendlist, etc.), so the C-style cast reinterprets a CommTiled object's memory as CommBrick layout — producing garbage pointers.

   PairDeepBaseModel::init_style() has no check for comm_style; it only sets up the neighbor list request.

   pair_deepspin.cpp is present in the tree and uses the same pattern [2]. However, pair_dpa4spin.cpp and the Kokkos pair file deepmd/kk do not appear under source/lmp/ [2], so those references in the report may be forward-looking or from a different branch. The source/lmp/plugin/ subdirectory could contain additional pair styles not listed in the top-level directory.

   The suggested fix — checking comm->style early in init_style() — is straightforward:

   if (comm->style != Comm::BRICK) {
     error->all(FLERR,
       "Pair style 'deepmd' requires comm_style brick; "
       "comm_style tiled is not supported.");
   }

   This would surface a clear error instead of a crash or silent corruption when running with comm_style tiled on multiple ranks.

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
3. LOGO127 commented on Sep 8, 2026

   

   LOGO127

   on Sep 8, 2026

   Last edited by LOGO127

   Contributor

   More actions

   Thanks for the diagnosis. I investigated a fail-fast candidate against master 28b7d06: a comm->style != Comm::BRICK guard in both PairDeepBaseModel::init_style() (deepmd/deepspin) and the independent PairDPA4Spin::init_style(). The corresponding Kokkos initializers call these host initializers; I have not validated Kokkos execution.

   Local evidence with LAMMPS stable_22Jul2025_update6, MPICH 5.0.1 and PyTorch 2.11 CPU:

   • Real deepmd/deepspin initialization, 1/2 ranks × brick/tiled: the same diagnostic assertions give 4 failures/4 passes before the guards and 8 passes after them.
   • Exported a genuine nonparametric DPA4C native-spin graph model from the upstream fixture configuration, with nonzero forces/magnetic forces. A LAMMPS embedding then performs ordinary model loading, pair_coeff, and run 0. On 1/2 ranks, guarded brick runs match Python reference energy, forces and magnetic forces; guarded tiled runs reject with the intended diagnostic (4 cases pass). The embedding only supplies the host factory registration separately addressed by fix(lammps): register native-spin host pair style in plugin #6012; it does not mock the model or initializer.
   • Against the unguarded host implementation, brick controls still pass and both tiled cases run instead of rejecting (2 failures/2 passes against the same assertions). This does not reproduce the with-communication artifact crash: this DPA4C artifact has no intermediate feature exchange. I am not claiming runtime corruption from that control.

   Follow-up validation: I also generated the unmodified upstream DPA4 native-spin fixture (has_comm_artifact=true, has_message_passing=true) and exercised pair_style deepspin through the same loaded-model runner. The unguarded 2-rank tiled run fails inside AOTI: the two ranks attempt allocations of 1,019,529,252,864 and 1,150,136,174,592 bytes before propagating backend errors. The matched 1/2-rank brick runs pass energy/force/magnetic-force comparisons. With the guard, both tiled cases reject at initialization and all 8 loaded-model cases across DPA4C/DPA4 pass. The single-rank unguarded DPA4 tiled case completes; I am not claiming every tiled configuration crashes. No Kokkos/GPU runtime validation yet.

   Before polishing an upstream PR, is a nonparametric native-spin fixture plus MPI regression the preferred test location, or should the host integration test wait for #6012? Also happy to coordinate if someone is already implementing this. The candidate is local and unpublished; this investigation and patch were developed with AI assistance, with the original diagnosis credited to this issue.
4. njzjz-bot commented on Sep 29, 2026

   

   njzjz-bot

   on Sep 29, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   Thanks for the careful validation. The DPA4 message-passing MPI reproducer is enough evidence to proceed with a fail-fast fix; I would not wait for #6012.

   Please keep #6012 separate. For this issue, the preferred shape is:

   • add the comm->style == Comm::BRICK guard in the common DeepMD/DeepSpin initialization path and in the independent PairDPA4Spin::init_style() path;
   • keep the diagnostic explicit that comm_style tiled is unsupported;
   • add a built-in-package/integration regression that does not depend on runtime plugin registration if possible;
   • include the real 2-rank message-passing DPA4/DeepSpin case you already validated, because it demonstrates that the unchecked cast is not just theoretical;
   • keep brick controls to show the guard does not change supported behavior.

   Because the Kokkos initializers flow through the corresponding host/base initialization, this PR does not need to claim GPU runtime validation merely to enforce the communicator precondition. A separate Kokkos runtime test can be added where GPU CI is available.

   Please go ahead and open the PR with the focused guard + regressions.

   Agent: ChatGPT
   Model: GPT-5.6 Sol