$npx -y skills add jinzhezenggroup/computational-chemistry-agent-skills --skill lammps-reaxffRun reactive molecular dynamics simulations in LAMMPS with the ReaxFF potential, including preparing input scripts (pair_style reaxff + fix qeq/reaxff), mapping LAMMPS atom types to elements via pair_coeff, choosing ensembles (NVE/NVT/NPT), and adding common ReaxFF diagnostics su
| 1 | # LAMMPS + ReaxFF |
| 2 | |
| 3 | Use this skill when the user wants to run molecular dynamics in LAMMPS with a ReaxFF force field, prepare or explain an `input.lammps` file, and set up charge equilibration (QEq) correctly. |
| 4 | |
| 5 | ## Agent responsibilities |
| 6 | |
| 7 | 1. Confirm the **ReaxFF force field file** (e.g. `ffield.reax.*`). Do not guess which file is appropriate. |
| 8 | - If the user does not have a force field yet, point them to known sources (e.g. LAMMPS `potentials/ffield.reax.*` at https://github.com/lammps/lammps/tree/develop/potentials). |
| 9 | 1. Confirm the **structure/data file** (e.g. `data.system`) and the **atom type → element mapping** needed by `pair_coeff`. |
| 10 | 1. Ensure the input includes charge handling: |
| 11 | - Use a charge-capable atom style, such as `atom_style charge` or `atom_style full`, and ensure charges are initialized either from the data file (with a charge column compatible with the chosen `atom_style`) or via explicit commands (e.g. `set` or equal-style variables). Do **not** rely on `fix property/atom q` as a substitute for a real charge field used by ReaxFF/QEq. |
| 12 | - Add **one** charge equilibration fix, typically `fix qeq/reaxff`, unless the user explicitly requests otherwise. |
| 13 | 1. Write the LAMMPS input script yourself; keep examples readable and annotated. |
| 14 | 1. When possible, validate command availability against LAMMPS docs or local `lmp -h` output before execution. |
| 15 | 1. Report clearly which command was run, which files were used, and where outputs were written. |
| 16 | |
| 17 | ## Minimum information to collect |
| 18 | |
| 19 | Ask only for what is missing: |
| 20 | |
| 21 | - LAMMPS data file path (or structure + how to generate a data file) |
| 22 | - ReaxFF force field file path (`ffield.reax...`) |
| 23 | - Atom types present and their element mapping (for `pair_coeff * * ffield ...`) |
| 24 | - Ensemble (NVE / NVT / NPT) |
| 25 | - Temperature, pressure (if NPT), timestep, run length |
| 26 | - Execution mode: online provisioning vs user-specified LAMMPS binary |
| 27 | |
| 28 | ## Execution mode |
| 29 | |
| 30 | ### Online mode (only if internet access + `uv` is available) |
| 31 | |
| 32 | Use: |
| 33 | |
| 34 | ```bash |
| 35 | uvx --from 'lammps[mpi]' lmp -in input.lammps |
| 36 | ``` |
| 37 | |
| 38 | Notes: |
| 39 | |
| 40 | - If you see `error while loading shared libraries: libmpi.so...`, you likely installed an MPI-linked `lmp` without MPI runtime libraries. Prefer `uvx --from 'lammps[mpi]' ...` (bundles MPI runtime), or load/install MPICH/OpenMPI via system packages/conda/HPC module. |
| 41 | |
| 42 | ### Offline mode (common / HPC) |
| 43 | |
| 44 | Do **not** invent the executable. Ask which command should be used, e.g.: |
| 45 | |
| 46 | - `lmp -in input.lammps` |
| 47 | - `mpirun -np 32 lmp_mpi -in input.lammps` |
| 48 | - `srun lmp -in input.lammps` |
| 49 | |
| 50 | ## Example: annotated NVT input (ReaxFF + QEq) |
| 51 | |
| 52 | See also `assets/input.reaxff.nvt.lammps`. |
| 53 | |
| 54 | ```lammps |
| 55 | # --------- user knobs --------- |
| 56 | variable NSTEPS equal 200000 |
| 57 | variable THERMO equal 200 |
| 58 | variable DUMP equal 1000 |
| 59 | |
| 60 | variable TEMP equal 300.0 |
| 61 | variable TAU_T equal 100.0 |
| 62 | |
| 63 | # Timestep (fs for units real). For high-T / reactive runs, 0.1 fs is often safer. |
| 64 | variable DT equal 0.25 |
| 65 | |
| 66 | |
| 67 | # QEq parameters |
| 68 | variable QEQ_EVERY equal 1 |
| 69 | variable QEQ_TOL equal 1.0e-6 |
| 70 | variable QEQ_CUTLO equal 0.0 |
| 71 | variable QEQ_CUTHI equal 10.0 |
| 72 | |
| 73 | units real |
| 74 | boundary p p p |
| 75 | atom_style charge |
| 76 | |
| 77 | read_data data.system |
| 78 | |
| 79 | neighbor 2.0 bin |
| 80 | neigh_modify every 1 delay 0 check yes |
| 81 | |
| 82 | # ReaxFF potential |
| 83 | pair_style reaxff NULL |
| 84 | pair_coeff * * ffield.reax C H O |
| 85 | |
| 86 | # Charge equilibration (required for most ReaxFF parameterizations) |
| 87 | fix fqeq all qeq/reaxff ${QEQ_EVERY} ${QEQ_CUTLO} ${QEQ_CUTHI} ${QEQ_TOL} reaxff |
| 88 | # (`reaxff` here means QEq parameters are extracted from the ReaxFF force field file.) |
| 89 | |
| 90 | # Thermo and trajectory |
| 91 | thermo_style custom step temp pe ke etotal press vol density |
| 92 | thermo ${THERMO} |
| 93 | |
| 94 | dump 1 all custom ${DUMP} traj.lammpstrj id type q x y z |
| 95 | |
| 96 | # Dynamics |
| 97 | velocity all create ${TEMP} 12345 mom yes rot yes dist gaussian |
| 98 | fix fnvt all nvt temp ${TEMP} ${TEMP} ${TAU_T} |
| 99 | |
| 100 | timestep ${DT} |
| 101 | run ${NSTEPS} |
| 102 | ``` |
| 103 | |
| 104 | ### Notes on the example |
| 105 | |
| 106 | - `units real` is a common choice for ReaxFF (time in fs). Many published ReaxFF workflows use `real`, but the correct choice depends on the parameterization and you |