Skip to content

[pull] develop from lammps:develop - #180

Merged
pull[bot] merged 120 commits into
comphy-lab:developfrom
lammps:develop
Aug 4, 2026
Merged

[pull] develop from lammps:develop#180
pull[bot] merged 120 commits into
comphy-lab:developfrom
lammps:develop

Conversation

@pull

@pull pull Bot commented Aug 4, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

Copilot AI and others added 30 commits June 10, 2026 23:23
The embedding loop in PairEAMOMP::eval() now uses the shared
embedding_index() helper and the two-sided linear extrapolation
selected by he_flag, exactly as PairEAM::compute(). The new
eam/he/omp style is a constructor-only subclass of PairEAMOMP.

Verified: classic eam/alloy/fs -sf omp runs are byte-identical to
before; eam/he/omp matches plain eam/he bitwise over 50 MD steps
(2 threads, serial + 4 ranks, newton on/off) and in dedicated tests
exercising the linear extrapolation above rhomax and below rhomin.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The three embedding sites in PairEAMKokkos (KernelB, fused KernelAB,
and the HIP team variant) now use a device-side embedding_index_kk()
helper that mirrors PairEAM::embedding_index(), with a new rhomin_kk
member and the two-sided extrapolation selected by he_flag. The
runtime branch is uniform across threads and free on GPUs. The new
eam/he/kk style is a constructor-only template subclass.

Verified: classic eam/alloy/fs -sf kk runs are byte-identical to
before (serial backend); eam/he/kk matches plain eam/he bitwise over
50 MD steps and in extrapolation tests above rhomax / below rhomin.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The gpu library EAM class gains rhomin and he_flag parameters, passed
through to the embedding kernels; the store_energy_fp macro (both the
shuffle and local-memory variants used by k_energy/k_energy_fast)
implements the eam/he table indexing and two-sided extrapolation
behind a uniform runtime branch. A new per-style device instance
(lal_eam_he_ext.cpp) backs the new eam/he/gpu style, which is a
constructor-only subclass of PairEAMGPU binding that instance.

Verified (OpenCL backend): classic eam/alloy/fs -sf gpu runs are
byte-identical to before; eam/he/gpu matches plain eam/he to mixed-
precision accuracy (max 4e-5 relative over 50 MD steps, same scale
as eam/gpu vs eam) including the extrapolation regimes above rhomax
and below rhomin; the eam_he yaml test passes its gpu sub-test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add the Accelerator Variants line and index entries for eam/he/gpu,
eam/he/kk, and eam/he/omp to the pair_eam doc page, the (gko) suffix
letters to the pair style command table, and the new package file
names to src/.gitignore.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The eval() functions of PairEAMOMP and PairEAMOpt gain the table
format as an additional template parameter, dispatched once in
compute(), so the eam/he test is resolved at compile time like the
existing EVFLAG/EFLAG/NEWTON_PAIR parameters. The OPT embedding loop
uses the (templated) shared embedding_index() helper, which also
gives it eam/he support; the new eam/he/opt style is a constructor-
only subclass of PairEAMOpt.

Verified: all previously existing style/suffix combinations remain
byte-identical (plain, -sf opt/omp/kk/gpu, serial and 4-rank MPI,
newton on/off); the new eam/he/opt is bitwise identical to plain
eam/he over 50 MD steps and in the extrapolation tests above rhomax
and below rhomin, and ~10% faster serial; the eam_he yaml test now
exercises and passes its opt sub-test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Reword the dump_modify balance note per reviewer suggestion to clarify
that balancing is per-processor (not per-file) and that files will
naturally differ in length when nfile/fileper do not divide nprocs
evenly. Update the runtime warning text to match this framing and fix a
"correcly" typo.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FHrXNCoWpsuFRFPMZLQ28z
Co-authored-by: Stan Moore <stanmoore1@gmail.com>
Drop the redundant comm.h include and use the Dump class's own me
member for the rank-0 check in the balancing warning.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FHrXNCoWpsuFRFPMZLQ28z
Co-authored-by: Stan Moore <stanmoore1@gmail.com>
…kokkos styles

The KOKKOS version of pair style buck6d/coul/gauss/dsf scaled the entire
damped Coulomb term with the special_bonds factor instead of subtracting
only the bare 1/r Coulomb part like the CPU version does.  With the
default special_bonds settings this zeroed out the Coulomb interaction
of all bonded pairs (up to 100% force error on molecular systems).

Both KOKKOS variants also used the low-accuracy Abramowitz-Stegun
polynomial for erf() where their CPU counterparts use the high-accuracy
MathSpecial::my_erfcx() based expression, limiting agreement with the
CPU reference to about 1e-5.  Use Kokkos::erf() instead, which agrees
with the CPU expression to double precision accuracy (verified to
9e-16 absolute).  Also apply the Coulomb smoothing before the special
bonds correction in the long variant's energy path to match the CPU
implementation, and drop the now unused ewald_const.h include.

Found by the new buck6d force-style tests: the suffix runs of
mol-pair-buck6d_coul_gauss_{dsf,long}.yaml now agree with the CPU
reference to 1e-12.
…yles

New YAML references for previously untested styles:
- pair buck6d/coul/gauss/dsf and buck6d/coul/gauss/long (MOFFF)
- angle cosine/buck6d (MOFFF); requires a buck6d pair style, uses
  pair style zero in nocoeff mode during the data file round trip
- pair lj/cut/soft/gapsys (FEP)
- pair hbond/dreiding/lj/angleoffset and hbond/dreiding/morse/angleoffset
  (EXTRA-MOLECULE); reference energies differ from the base styles so
  the offset code path is exercised
…sity

- bond style special (MISC): needs special_bonds 0 1 1 and a real pair
  style with single() support; uses lj/cut via post_commands and the
  zero nocoeff placeholder during the data file round trip
- pair agni (MISC): force-only ML potential, energies are zero by
  design; the regression kernel sum amplifies last-ulp differences in
  exp() by several orders of magnitude (e.g. from the OPENMP variant
  using fm_exp), so the epsilon is intentionally loose at 1e-4
- pair local/density (MANYBODY): single-type LD table taken from the
  methanol_implicit_water example
The spin variants of the dipole kspace solvers never initialize the
charge-channel accumulators (qsum, qsqsum, q2) since spin-only systems
have no charge array and qsum_qsq() is never called.  The inherited
grid-size estimator and accuracy checks read q2, making the chosen PPPM
grid (and thus all results) depend on uninitialized memory.  Zero the
charge channel explicitly in spsum_spsq()/spsum_musq().

PPPMDipoleSpin::compute() also used wrong per-grid-point counts for the
inherited pack/unpack methods (3 instead of 4 for REVERSE_MU, 9 instead
of 12 for FORWARD_MU, 18 instead of 25 for FORWARD_MU_PERATOM) and
called the per-atom forward comm on the never-allocated base class gc
grid instead of gc_dipole, which segfaulted any run with per-atom
energy or virial accumulation.  In parallel runs the undersized counts
silently corrupted the communicated ghost grid data.

make_rho_spin() now also clears density_brick like make_rho_dipole()
does: brick2fft_dipole() and poisson_ik_dipole() process the charge
density unconditionally, so spin runs fed uninitialized grid data into
the charge structure factor (nondeterministic forces, up to NaN).

Also call error->all() on all ranks instead of only rank 0 when a
dipole/spin solver is used on a system without dipoles/spins (a rank-0
only call to a collective error would hang parallel runs).

Found by the new kspace-{ewald,pppm}_dipole_spin.yaml force-style
tests; verified with valgrind and repeated runs.
… solvers

- spin-pair-dipole_long.yaml: real-space part with the kspace solver
  present but disabled (kspace_modify compute no), mirroring the
  existing spin/dipole/cut test; reference magnetic forces differ from
  the cut variant so the long-range damping path is exercised
- kspace-ewald_dipole_spin.yaml, kspace-pppm_dipole_spin.yaml: same
  system with the solver active and randomized spin directions (fixed
  seed) to break the bcc lattice symmetry; the two solvers agree on the
  reference forces to the requested accuracy

pppm/rk from the stage 1 list cannot be tested with this harness: it
requires the multi-partition verlet/split/rk integrator.
The per-pair long-range pressure correction was added to the variable
holding the EOS pressure term of atom i INSIDE the neighbor loop, so it
accumulated once per neighbor list entry.  The resulting forces depended
on the number and order of neighbors (and thus differed completely
between newton on and off even on a single processor).  Apply both
halves of the pair correction to the pair-local j term instead, so the
per-atom value stays intact.  The GPU kernels replicated the same defect
and are fixed identically.  With this change newton on and off produce
bit-identical forces.

Found by the new sph-pair-lj.yaml force-style test.
…and order

The RNG seed included atom->nlocal at pair_style time, so the random
stream differed depending on whether the pair style is defined before
or after the atoms are created.  comm->me already decorrelates the
per-rank streams; drop the nlocal term.

Also add a "nofdotr" token for the skip_tests list of the pair style
tester: styles whose dissipative or random pair forces are not central
(like sdpd) cannot reproduce the fdotr virial through ev_tally() and
need to opt out of that comparison.
New in.sph template and data.sph file: a small perturbed simple cubic
block of 64 sph particles with two types, nonuniform density, internal
energy, and heat capacity, and nonzero velocities so that the viscous
force terms contribute at the first evaluation.

Covers sph/heatconduction, sph/idealgas, sph/lj, sph/rhosum,
sph/taitwater, sph/taitwater/morris (SPH package), and
sdpd/taitwater/isothermal (DPD-SMOOTH, using the same fixed-seed
conventions as the existing dpd tests: newton on pinned, ghost
velocities enabled, nofdotr comparison skipped).
All three styles set writedata = 1, but edpd and tdpd did not implement
write_data()/write_data_all(), so write_data produced an empty Pair
Coeffs section that read_data cannot parse.  The mdpd per-type variant
omitted the mandatory cut and cut_r columns, making its output
unreadable as well (its coeff() requires all five parameters).

Reading an edpd restart crashed or misbehaved: power_flag and
kappa_flag were never initialized in the constructor and not stored in
the restart file, so read_restart() consulted garbage values to decide
whether the optional sc/kc tables follow in the file, and those tables
(only allocated in coeff) were written to without allocation.  Store
the two flags in the restart settings, initialize them in the
constructor, and allocate the tables when needed.  Note this changes
the on-disk restart format for edpd, which is version-specific anyway.

Found by the new meso-pair-{edpd,mdpd,tdpd}.yaml force-style tests.
New in.edpd/in.mdpd/in.tdpd templates and matching small data files
(64 particles, 2 types, perturbed lattice, nonzero velocities and
nonuniform per-atom temperature/density/concentration).  Covers pair
styles edpd, tdpd, and mdpd together with mdpd/rhosum via
hybrid/overlay as in its documented usage.  All three use fixed RNG
seeds and pin newton on, following the existing dpd test conventions.
akohlmey added 27 commits July 26, 2026 15:58
Two new dump_modify keywords render objects as metal rather than as
colored plastic.  A metal reflects nearly all light directly and tints
it with its own color, instead of scattering it diffusely and reflecting
it unchanged.  The "metal" keyword blends between those two limits, the
"metalfinish" keyword picks among a satin, polished, or mirror surface.

Since a metal shows its surroundings rather than a color of its own, the
surroundings are approximated by a bright sky above a dark ground, with
a brightened band at the horizon.  Those are deliberately not adjustable:
the effect is an imitation, and a scene where the material appearance
matters is better rendered with a ray tracer.  The default "metal 0.0"
reproduces the previous rendering pixel for pixel.

Also adjust the pre-defined colors of 15 metals, most of which shared a
single generic gray, so they resemble the metals they stand for.  Among
them chromium, which was green, the color of chromium oxide rather than
of the metal.
Remove too conservative error check in dump file code
Add eam/he pair style variants for the OPENMP, KOKKOS, and GPU packages
Rendering enhancements for dump image: depth cueing, depth of focus, outlines, specular, metallic effect, and gamma controls
Force-style test additions: MOFFF, FEP, SPH, DPD-MESO, SPIN packages
The emulation of the bundled fmtlib via std::format only exposes the
functions that LAMMPS uses; the VTKWriter class now builds file output
in memory with fmt::format_to(), so add it to that list.
Previously only the point coordinates honored the precision setting,
while data arrays were always written as double.  Now the default
single precision applies to all floating point data, which is what
visualization programs work with and roughly halves the file sizes,
and selecting DOUBLE precision switches all of it to full precision.

Text mode output now uses the shortest representation that reads back
as the identical number instead of the fixed 11 significant digits the
VTK library writes, so double precision text files really round-trip.
Only coordinates are tracked for the single precision warning: data
arrays need only relative resolution, which single precision always
provides, while coordinates lose absolute resolution as the simulation
box grows.

Interface and performance cleanup from a code review pass:
- take coordinate and data vectors by value so that callers can
  std::move() their data into the writer instead of copying it
- write large text payloads in chunks instead of two stdio calls per
  value, reserve the XML payload string, and bound the byte-swap
  buffer for legacy binary data to a fixed chunk size
- replace the five per-type formatting wrappers with one template
- expose xml_real_type(), xml_byte_order(), and
  single_precision_resolution() as static methods so that callers no
  longer hardcode facts the writer owns

Update the unit tests for the new default types and add coverage for
the round-trip property and the dataset size accessors.
The new keyword switches all floating point data in the dump file, the
bounding box file, and the parallel summary file from the default
single precision to double precision, with the same keyword and
semantics as dump netcdf.  The warning about large coordinates now
recommends the keyword instead of asking users to contact the LAMMPS
developers, and is skipped automatically in double precision mode.

Remove leftovers from the conversion away from the VTK library and
from the original LIGGGHTS implementation:
- delete add_vtk_compute/fix/variable/custom() and memory_usage(),
  which were byte-identical copies of inherited DumpCustom methods
- delete the never invoked header_choice dispatch machinery, an
  MPI_Allreduce that computed the header size for a header that is
  never written, and the boxcorners copy of the domain->corners
  pointer
- merge the nearly identical write_vtp() and write_vtu() into a
  common write_xml_snapshot()
- build the derived file names with std::string helpers instead of
  sprintf() into manually sized buffers, and drop a build-and-discard
  round trip for the per-processor file name in the constructor
- declare the data types in the .pvtp/.pvtu summary files through the
  new VTKWriter static methods so they cannot drift from what the
  piece files contain
- move the collected data into the writer instead of copying it and
  reserve the vector capacity while collecting
- use utils::missing_cmd_args() and SafeFilePtr where applicable

Update the tests for the new default types and error messages and add
coverage for double precision output including the summary file.
Same keyword and behavior as for dump vtk: all floating point data is
written in single precision by default and in double precision on
request, and the warning about large grid coordinates recommends the
keyword and shares its threshold logic with dump vtk through the
writer.  Skip allocating and filling the cell boundary coordinates for
the image data format, which describes the grid by origin and spacing
alone, and move the collected grid data into the writer instead of
copying it.

Update the tests for the new default types and the shortest round-trip
representation of the grid spacing, and add double precision coverage.
Remove the unused nsum and KnSlice members, the declared but never
defined invoke_scalar(), the never called reset_timestep(), an unused
enum, and pointer initializations that repeated the initializer list.
Use utils::missing_cmd_args() for missing keyword arguments and move
the collected intensities into the VTK writer instead of copying them.
Describe the new keyword in dump_modify.rst for the vtk and grid/vtk
styles and update the precision discussions on the dump vtk, dump
grid/vtk, and fix saed/vtk pages, which no longer need to ask users to
contact the developers for a double precision option.  Bring the
VTKWriter section of the programmer guide up to date with the
writer-wide precision setting, the pass-by-value interface, and the
single precision warning helper.
Add VTKWriter class for unified VTK output without requiring the VTK libraries
@pull pull Bot locked and limited conversation to collaborators Aug 4, 2026
@pull pull Bot added the ⤵️ pull label Aug 4, 2026
@pull
pull Bot merged commit f0342f1 into comphy-lab:develop Aug 4, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants