Hi all,
I have a problem about the Langevin dynamics in LAMMPS:
I'm simulating a system with Langevin equation with spatial dependent
damping coefficient gamma(x,y,z), so I cannot use the fix_langevin command
directly since gamma(x,y,z) is not a constant.

I try to solve the problem as follows:
1, use fix_addforce to add the spatial dependent damping force
-gamma(x,y,z)*v and the random force to the atoms;
2, use fix_nve to integrate the equation.

But I'm wondering whether this method will give the correct thermal
dynamics or not. Does anyone have any idea or suggestion about this
problem? Thank you in advance!

Hi Steve,
Thanks for your information! I will check the method carefully.
By the way, I think it’s worth to include the spacially-dependent damping coefficient into the fix langevin in lammps because many people are using this method. Do you think it’s possible?

Hi Steve,
Thanks for your information! I will check the method carefully.
By the way, I think it's worth to include the spacially-dependent damping
coefficient into the fix langevin in lammps because many people are using
this method. Do you think it's possible?

with the current implementation of fix langevin you can define multiple
instances of the fix, each operating on a different group of atoms.
these groups can be dynamic, e.g. based on (adjacent) regions and thus you
can already have spatially dependent damping/friction of some sorts.

Hi Axel,
Thanks for your email. By using your protocol, we can solve some simple problems. But for genaral consideration, I think implement fix langevin including gamma as an atom variable is the best way. Will you consider it as a future plan for the newer version of lammps?
Thank you in advance!

Hi Axel,
Thanks for your email. By using your protocol, we can solve some simple
problems. But for genaral consideration, I think implement fix langevin
including gamma as an atom variable is the best way. Will you consider it
as a future plan for the newer version of lammps?

the typical way this would happen is, that the people who actually *want*
to have the feature implemented in LAMMPS would sit down and do the
implementation and necessary testing themselves. a large part of LAMMPS
has been implemented this way. just look through the source code and see
the many, many different authors, not to mention the many (USER) packages.

also, i would recommend against implementing this in fix langevin directly,
this is already a quite overloaded and complex piece of code and adding
another quite invasive feature like this to it, would increase the
complexity significantly (and reduce maintainability). it seems to me, that
as standalone implementation with a minimal set of langevin features would
be cleaner and easier to add (e.g. to USER-MISC).
there are already several such contributed langevin variants included
(e.g. fixes gld, gle, temp/csld)

Hi Ouyang, if your gamma is non-constant across the system, but is e.g. constant for each atom type, you are already all set with defining multiple fix langevin instances.

However, originally you suggested that your damping parameter is a function of the spatial coordinates, gamma(x, y, z).

The way you define this function (e.g. a 3D grid?) is specific to what you intend to do, and the code to support the associated Langevin equation will also be highly specific to that.

I suggest to do like Axel suggested, and go for an entirely new fix.

Hi Giacomo and axel,
Thanks for your detailed explanations. What I actually want to simulate is a system in which the damping coefficients are depenendent on the configurations of the atoms. That means the spatially-dependent coefficients will envolve with time. Maybe you are right, a new fix is needed for this problem. I will try to implement myself. Thanks very much for your help!

Hi Giacomo and axel,
Thanks for your detailed explanations. What I actually want to simulate is
a system in which the damping coefficients are depenendent on the
configurations of the atoms. That means the spatially-dependent
coefficients will envolve with time. Maybe you are right, a new fix is
needed for this problem. I will try to implement myself. Thanks very much
for your help!

actually, that sounds much more like what is done in the DPD thermostat,
which is implemented as pair style dpd/tstat to be used with pair style
hybrid/overlay. if your configuration dependent term can be decomposed into
pairwise contributions, this may be an alternate approach worth looking
into.