Timestep in FIRE 2.0

Dear all,

I have a question about an appropriate timestep to be used in FIRE 2.0. In the paper “https://www.sciencedirect.com/science/article/pii/S0927025620300756#bi005”, the authors mention that:

“In any case, we recommend to set the simulation timestep (command timestep in lammps ) to the same value as in MD at low temperature.”

However, I couldn’t find any definition for the low temperature in their paper. I appreciate it if anyone can give me some hints about this issue. Although I was not sure about the “low temperature”, I ran myself an NVT and then NVE for a MEAM potential that I have at 1K to check the conservation energy with 10 fs timestep at 1K, and I saw that the energy is conserved with 10 fs at 1K using the potential that I have. Can I say that I am safe with choosing 0.01 or 10 fs if I want to use it in FIRE 2.0 or even in an NEB calculation?

Many thanks in advance for your time and stay safe,



For a minimizer algorithm, any timestep that results in a non-diverging propagation of particles is “safe”.
Beyond that, the choice is merely a question of computational efficiency. I wouldn’t even worry about tweaking the time step unless you have serious issues with finding sufficient computational resources to run your calculations.

Since you say you want to do NEB calculations, then I would consider it more important to sure your endpoints are properly prepared and the overall NEB settings are suitable rather than worrying about the minimizer.


So the doc page for minimize has a Note that for FIRE (and other damped
dynamic minimizers) you can (and should) use a timestep about
10x larger than you would for dynamics. Which has little dependence
on temperature. FIRE was recently upgraded in LAMMPS (by
the FIRE experts), so I don’t know if they agree with that
recommendation (it pre-dates their upgrade).

I’m CCing Julien so he can comment …


Thanks Steve for pointing me this message!

This recommandation for using a timestep 10x larger than for dynamics does not exactly stand for FIRE/FIRE2. Also, what we implied by the very non-precise “low temperature” timestep was several 110s of K, rather than 1K. Sorry for missing that part: I should have suggested a correction of the documentation!

As opposite to Quickmin, FIRE has a variable timestep that will accelerate te mimimization. In our tests, we noticed that a good trade-off was to start with a “relatively small” tilmestep (i.e. similar to MD, typically of the order of 1fs in solid materials with manybody potentials) but to allow FIRE to vary it up to 10x, which is the default parameter.

But Axel is right: at the end, if your system effectively minimizes below the threshold you defined, your calculation should be correct whatever tilmestep you chose. As opposite to dynamics, you cannot do anything wrong besides spending some time/computing ressources: either your system diverge and that will be pretty obvious to discard such simulation, either you converge to your thresholds and all will be fine.


Thanks Julien, this makes more sense. We should
update the minimize doc page with this advice.


Actually, I realised that the information is already in the min_style doc page.
Should we still update the minimise doc page, or just remove the “note" from it as the user needs anyway to use the min_style option to activate any of the damped dynamic minimizer ?