Re: [ESPResSo-users] langevin gamma not friction coefficient in v3.3.1?

[Edvin Memet]

Dear Joost,

Thank you!

For others' benefit, let me note that indeed in v3.3.1 gamma is not actually a friction coefficient although it is referred to as such in the documentation. This issue is fixed in the development version. This excerpt from the documentation of the development version explains this:

"Warning: The behavior of the Langevin Thermostat has changed in this version of ESPResSo. Before, the term gamma was called the ‘friction coefficient’, but was in fact the inverse relaxation time. The code has been modified such that this value is now a proper friction coefficient."

Best,
Edvin

On 01/15/2017 12:34 PM, Joost de Graaf wrote:

Dear Edvin,

The solution is simple. If you run the thermostat with the new behavior, it will print out a warning message that this behavior has indeed changed, if you do not see this message, you are running the old version.

Kind Regards,

Joost

On 15 January 2017 at 16:59, Edvin Memet <address@hidden> wrote:

According to another thread in this archive - http://lists.nongnu.org/archive/html/espressomd-users/2015-11/msg00019.html - the parameter gamma in the Langevin thermostat represents a friction coefficient, such that F_friction = gamma*v (whereas in earlier versions, it used to be a relaxation time: F_friction = gamma_old *m * v). The thread was posted a few months after the release of the latest Espresso version (3.3.1), so I assumed it refers to that version. 

However, I'm using v3.3.1 and from what I can tell, it seems that gamma is not a friction coefficient here, because the friction force still has a mass term in it. For example, see the attached sample script, where I compare the velocity decay of two particles of different masses. The profiles are identical, which would only happen if the mass term in friction cancels out the mass term in inertia, right?

Moreover, looking at the source code, I think this is the relevant bit for the friction term (in the file thermostat.hpp): p->f.f[j] = langevin_pref1_temp*p->m.v[j]*PMASS(*p)+ ... It seems like there is a mass term in there. This is in contrast to the development code on github, where the equivalent line reads p->f.f[j] = langevin_pref1_temp[j]*velocity[j] + ...

Is this assessment correct? If so, and if I want gamma to be a friction coefficient, is the solution as simple as removing the mass term in thermostat.hpp, or should I just use the development version?

Best, Edvin