# langevin thermostat versus Nosé-Hoover thermostat

Hello lammps-users,

I am a PhD student and I am working on some atomistic simulations using LAMMPS. I am working on crystallin materials.

I performed some 2D simulations of a crystallin system, which is heated at a certain temperature. The system is kept at constant temperature and the microstructure evolves.The evolution of the system is such that it reduce its volume during the simulation.

I performed in NPT ensemble using the ‘fix npt’ command. I used a lennard jones potential for interactions, with coefficients 8 - 4 ( ‘pair_style nm’ in lammps). I started my simulations from a previously relaxed configuration and assigned velocities at time t=0 with the ‘velocity’ command.
Simulations run well, I kept an eye on the values of temperature and pressure which fluctuates but in a limited range of values.

For some reasons, I was interested in trying to see the system evolution in canonical conditions, NVT ensemble, with a langevin thermostat. Actually, I tried 2 different thermostats:

1. Nosé - Hoover

2. Langevin thermostat

In the NPT case, the system changes its volume, so I was expected to see pressure changing in the NVT case;

I performed some simulations with the NH thermostat, trying different values of the damping term. In all the cases, I get similar profiles for the temperature and the pressure during the simulation. Pressure is oscillating, it is not zero but in any case it is not really high.
In conclusion, choosing a reasonable value for Tdamp I was able to kept the temperature constant and I get similar profiles for the evolution of pressure during the simulations.

Difficulties arised with the langevin thermostat.
First question, I don’t know if it is reasonable to assign velocities to atoms at the begging or just to set all the velocities equal to zero and then let the thermostat acting. What I noticed is that, if i follow this last procedure, I have to set a value of the temperature in the thermostat lower than the one desired. Let’s say: for having a final value of temperature of 0.2 (reduced units) I have to set Tstart=Tstop= 0.13 in the ‘fix langevin’ command.

Moreover, pressure is behaving in a really strange way. It changes its value in a continous way, reaching also important negative values and then it has some “wild jump” and returned to a zero value. Changing the damp parameter implies a change in the changing rate of pressure and in the rate of jumps.

So my question is: what is the meaning of this behaviour == am I choosing some unreasonable values of the damping parameter == there is a physical meaning to associate to this parameter? For a physical system like molecules in a solvent, I will say that the damping parameter is related to the viscosity of the solvent, but for condensed matter (what I am working on) the physical meaning of the damping parameter is less clear to me.

If you need some info about the simulations, just tell me.

Sorry for this long email, thank you in advance and have a nice day

Carolina

Large pressure fluctuations are usually a symptom of a small system. How many particles are there?

It might make sense to compare langevin to fix nvt instead of fix npt to see if they produce similar structures or not.

The thermostat reaching higher temperatures sounds like bad dynamics, but I cannot be sure.

Please post an input script and some log files, that makes it much easier to track down potential problems.

Dear LAMMPS users,

I have an odd problem with LAMMPS. Please find attached a really simple script that I wrote to making some tests after analogous problems with more complex simulations.

If I run the script on one computer (LAMMPS version 08_february_2019, Ubuntu version 18.04.2 LTS) I got the results reported in log_1.

If I run the same script on another computer (LAMMPS version 4_january_2019, Ubuntu version 18.04.1 LTS) I got the results reported in log_2.

As you can see from the two log_files, in log_1 the computation “eatoms” is always equal to zero. I am dumping in a file atoms coordinates and energy but the per/atom energy is perfectly computed. I am printing also another per/atom compute just to check if the per/atom computations are well working.

I really have no idea of the reason of why I have this odd result (that I have with all the LAMMPS script I am running on this pc). I tried to uninstall and reinstall LAMMPS but nothing changed. I am really puzzled because everything was working fine till this morning, when I update the system. However, it would be rather strange that system updates puzzle LAMMPS. With the other computer all the scripts work well.

Carolina Baruffi

ps. please find attached also the potential I am using

log_2.lammps (3.46 KB)

log_1.lammps (3.46 KB)

a0.inp (944 Bytes)

SiC_Erhart-Albe.tersoff (1.73 KB)

This might be due to a bug in compute reduce that was introduced in a recent check-in
on GHub. It has since been retracted. So you could try it with the latest
master version from GHub, or wait for a new patch release. Or revert to your 4Jan version.

Steve

Dear LAMMPS users,

I have an odd problem with LAMMPS. Please find attached a really simple script that I wrote to making some tests after analogous problems with more complex simulations.

If I run the script on one computer (LAMMPS version 08_february_2019, Ubuntu version 18.04.2 LTS) I got the results reported in log_1.

If I run the same script on another computer (LAMMPS version 4_january_2019, Ubuntu version 18.04.1 LTS) I got the results reported in log_2.

it is not really that odd a problem. the *real* problem here is that
you seem to be using a "daily build" version of LAMMPS that gets
compiled from the master development branch.
so your 8 Feb 2019 version is actually 8 Feb 2019 plus X. that that X
makes all the difference. as it happens, there was a new feature added
to LAMMPS, which turned out to be partially incorrect and particularly
would lead to compute reduce reporting 0 instead of the real value. it
was detected by out regression testing tools and acted upon within a
day. if you use the real 8 Feb 2019 version or an updated
"daily/nightly" build it should
be resolved.

this highlights the risk and danger of using daily/nightly LAMMPS
versions. despite all our best efforts to keep bugs out of the LAMMPS
code, and try to test and fix things before they get merged to the
development branch, it cannot be avoided. this is why we also offer
the "unstable" branch, which follows the patch releases (which have to
pass our regression testing before being published) and the "stable"
branch, which follows a period, where only bugfixes or changes with
very low risk of side effects are included and lots of additional,
manual testing is performed.

if you want to follow the changes of the developer branch, you should
also follow the developer discussions on the pull requests and issues
in our github project, so you are aware of issues. e.g. you can see
the testing status for the development branch (aka master) here:

every time you see a red X, that means there were problems with
testing the change. and every time you see a green checkmark, the
state of the branch at this point passed all our automated tests.
if you go there now, you see, that a fix was applied.

axel.

it is important to note, that this bug was *NOT* in the 8 Feb
*release* but was introduced *after*. it was a conscious decision to
merge this pull request after the release, even though it had been
approved in review, since the contained changes were higher risk (2
out of 3 worked out well, though).

axel.

Aaaaah, I see the problem, everything becomes clear now.

Thank you really for your super-quick answer, I wish you both a good weekend!

Carolina