Note: This response was drafted with the assistance of an AI tool (Claude) after this thread sat without a reply for a few days. While every effort has been made to reason carefully from the available information (and from the LAMMPS EFF package source code), AI-assisted answers carry a real risk of error — please treat the points below as a starting point rather than authoritative guidance. For authoritative guidance if the text below is not resolving your issues, you should probably contact the author of the EFF package, Andres Jaramillo-Botero at CalTech.
@jakes
There are a couple of things going on here, and they compound each other. I’ll split them into (1) the most likely practical cause of the heating you see, and (2) a more subtle conceptual point about what “temperature” even means in your frozen-nuclei eFF setup. The second part explains why the number from compute temp/eff will generally not equal your Langevin set point no matter how you tune the thermostat.
1. Your timestep is very likely too large
In units electron, time is measured in femtoseconds and the default timestep is 0.001. eFF electrons are light and fast (and the radial “breathing” coordinate is stiff), so the integration needs a small step. For comparison, the timesteps used in the bundled examples/PACKAGES/eff/ dynamics inputs are:
0.0001 (H atom, Auger-Adamantane, fixed-core CH4 spe)0.0005 – 0.001 (most fixed-core / ECP / plasma runs)0.005 (CH4, Li-solid, Li-dendritic — the largest used anywhere)
You are running at timestep 0.05, which is 10x–500x larger than any of those, and 50x the LAMMPS default for electron units. At that step the velocity-Verlet integrator no longer conserves energy for the electronic motion: it pumps energy in numerically, and a (relatively weak) thermostat cannot drain it fast enough. The result is exactly what you describe — the measured temperature sits well above the set point.
Quick diagnostic: turn the thermostat off (just fix nve/eff, no langevin/eff) and run a few hundred steps watching etotal. If the total energy climbs steadily, the timestep is too large. Drop it to 0.001 (or smaller) and the drift should largely disappear.
2. Your damping is weak for 300 K
You are using damp = 10.0 fs. The 300 K langevin/eff line in the eFF examples uses damp = 0.1:
fix 0 all langevin/eff 300.0 300.0 0.1 <seed>
The only example that uses damp = 10.0 is the Li-solid run at 3000 K. Larger damp means weaker coupling to the bath, i.e. slower thermalization. On its own that is not wrong, but combined with the oversized timestep it means the thermostat has no chance of keeping up with the numerical heating. I’d fix the timestep first, then use a stronger coupling (e.g. 0.1–1.0) for a 300 K target.
3. Why temp/eff won’t read your set point with all nuclei frozen
This is the part that I think is causing the most confusion, and it is independent of the two issues above.
In the eFF model, temperature is defined per nucleus, not per particle. If you look at the source:
compute temp/eff (compute_temp_eff.cpp, dof_compute()) sets the degrees of freedom to dof = 3*N_nuclei - 3 — the code literally comments “Assume 3/2 k T per nucleus” — while the kinetic-energy numerator still includes the full electron motion (both translational v and the radial ervel).fix langevin/eff does the matching thing internally: it builds a partitioning factor gfactor3 = (dof + nelectrons)/dof_nuclei to split the thermostat action between nuclei and electrons, again assuming the nuclei are a live thermal bath.
Now the key detail: fix setforce 0.0 0.0 0.0 zeroes the forces on your ions, but it does not remove their degrees of freedom. (There is no DOF bookkeeping in fix setforce.) So with every nucleus frozen:
- The thermostat still computes
gfactor3 as if 3*N_nuclei - 3 nuclear DOF were thermally active, and partitions energy on that basis — but those DOF are dead, so the calibration is off.
compute temp/eff still divides by 3*N_nuclei - 3, while the only kinetic energy in the numerator is the electrons’. The number it prints is therefore “electron kinetic energy expressed per nuclear DOF” — not an electron temperature, and not something that is expected to equal the Langevin set point.
In other words, even after you fix the timestep and damping, temp/eff is the wrong yardstick for a run in which only the electrons move. It is built around mobile nuclei.
What I’d actually recommend
It sounds like your real goal is to relax/anneal the electrons (positions and radii) at a fixed ionic geometry — a 300 K → 0 K ramp is essentially a quench of the electronic structure. For that, eFF’s standard tool is energy minimization, not a Langevin cool:
# ions held fixed, electrons relaxed
fix freeze ions setforce 0.0 0.0 0.0 # setforce zeroes the gradient on the ions
min_style cg
minimize 0.0 1.0e-6 2000 4000
fix setforce behaves correctly under minimize — it zeroes the force/gradient components on the ions, so the minimizer leaves them in place while optimizing the electron coordinates and sizes. This is exactly what the CH4, Li-solid, and Li-dendritic examples do to get the electronic ground state. It will get you to the 0 K end point far more cleanly than fighting numerical heating with a thermostat.
If you specifically need finite-temperature electron dynamics at fixed nuclei, then:
- Reduce the timestep to
~0.001 fs (or smaller) and verify energy conservation in a plain nve/eff run first.
- Use stronger damping (
0.1–1.0) for a 300 K target.
- Don’t rely on
temp/eff as a thermometer in this frozen-nuclei configuration — monitor the eFF energy components instead (the compute pair eff/cut outputs eke/epauli/ecoul/erres, as in the example inputs) and watch them settle, rather than expecting the temperature column to land on the set point.
- If your electrons are a separate atom type (or can otherwise be put in their own group), it is cleaner to integrate and thermostat only the electron group with
nve/eff + langevin/eff and leave the ions out of the integration entirely, rather than integrating everything and then zeroing the ion forces. (Also double-check the ions have zero initial velocity — setforce does not zero velocities, so any initial momentum would persist.)