[lammps-users] Segmentation fault using fix rigid/nvt/small

LAMMPS LAMMPS Mailing List Mirror
1

Hi,

I am getting a runtime segmentation fault with my simulation using the command “fix rigid/nvt/small”. The output is shown below (Item #1).

If I comment the “run” command at the end, the lammps script generates the log file (Item #2) such that everything appears to be working i.e. no illegal commands.
However, a segmentation fault is generated with the uncommented “run” command and the log file is empty.

I am using the pair style "lj/long/dipole/long " and the “molecule” command to read off the molecular configuration from a file.
The input script (Item #3) and the data file (Item #4) are also included.

I was unable to find an example with the exact same pair style and modeled my input script on the example script “/examples/gcmc/in.gcmc.co2”.

I am using LAMMPS version from March 03, 2020.

Any guidance in understanding or resolving the issue causing the segmentation fault shall be of great help.

Thanks.

Warm regards,
Vaibhav.

2

always test with the most current version of LAMMPS.

that would give you an error, since your input is not correct.

Axel.
p.s.: why do you set charges and use that pair style, if you turn off both long range handling and coulomb interactions??? given the parameters, that input has bogus force field data.

LAMMPS (24 Dec 2020)
using 1 OpenMP thread(s) per MPI task
Lattice spacing in x,y,z = 3.0000000 3.0000000 3.0000000
Created triclinic box = (-6.0000000 -6.0000000 -6.0000000) to (6.0000000 6.0000000 6.0000000) with tilt (0.0000000 0.0000000 0.0000000)
1 by 1 by 1 MPI processor grid
Read molecule template ethylene2:
1 molecules
5 atoms with max type 3
0 bonds with max type 0
0 angles with max type 0
0 dihedrals with max type 0
0 impropers with max type 0
Created 320 atoms
create_atoms CPU = 0.003 seconds
Setting atom values …
128 settings made for charge
Setting atom values …
64 settings made for charge
320 atoms in group c2h4
create bodies CPU = 0.001 seconds
64 rigid bodies with 320 atoms
0.62655000 = max distance from body owner to body atom
ERROR: Pair lj/long/dipole/long requires atom attributes mu, torque (src/DIPOLE/pair_lj_long_dipole_long.cpp:237)
Last command: run 2

3

Hi Axel,

Thanks very much for your input, I could have never figured the error on my own since it doesn’t show up on either my console output or the logfile.
I guess this is because I was not using the latest version.

I am now using the latest stable release and I got the same error as you.

I have a follow-up question related to the error:

ERROR: Pair lj/long/dipole/long requires atom attributes mu, torque (src/DIPOLE/pair_lj_long_dipole_long.cpp:237)

I understand “mu” is the dipole that is associated with point particles.
How does one specify this for the extended rigid molecules?
For spheres, one can of course use:
set group group-ID dipole/random seed value

The error also mentions the “torque” for the atom attributes.
However, I do not see torque attribute for any of the atom styles or the molecules.
Albeit, the molecules do have the Moment of Inertia attribute that can be specified.
So, isn’t the “fix rigid/nvt/small” supposed to compute the torques internally based on the forces acting on the rigid particles/molecules?
I could not find anything relevant from the documentation, but it is very much possible I have missed it.

As regards the use of the options for the pair style “lj/long/dipole/long off off $$”, I had the same question.
The molecule actually has a linear quadrupole moment (i.e. two antiparallel dipoles).

However, I am merely trying to be consistent with the prescribed force-field given below that is taken from the MolMod database.

http://molmod.boltzmann-zuse.de/

https://www.tandfonline.com/doi/abs/10.1080/08927022.2019.1601191?journalCode=gmos20

I have now written to them to see what they have to say about this.

Thanks once again for your prompt responses.

Warm regards,
Vaibhav.

4

Hi Axel,

Thanks very much for your input, I could have never figured the error on my own since it doesn’t show up on either my console output or the logfile.
I guess this is because I was not using the latest version.

…and because you didn’t follow the LAMMPS manual about debugging crashes:
https://docs.lammps.org/Errors_debug.html

I am now using the latest stable release and I got the same error as you.

I have a follow-up question related to the error:

ERROR: Pair lj/long/dipole/long requires atom attributes mu, torque (src/DIPOLE/pair_lj_long_dipole_long.cpp:237)

I understand “mu” is the dipole that is associated with point particles.
How does one specify this for the extended rigid molecules?

mu and torque are properties of atoms and thus as enabled by using a suitable atom style.

For spheres, one can of course use:
set group group-ID dipole/random seed value

The error also mentions the “torque” for the atom attributes.
However, I do not see torque attribute for any of the atom styles or the molecules.

torque is not a static property that you set with the set command, but computed (like forces) during the computation of the interactions.

Albeit, the molecules do have the Moment of Inertia attribute that can be specified.
So, isn’t the “fix rigid/nvt/small” supposed to compute the torques internally based on the forces acting on the rigid particles/molecules?
I could not find anything relevant from the documentation, but it is very much possible I have missed it.

there is a difference between torque on rigid bodies and torque on atoms.

As regards the use of the options for the pair style “lj/long/dipole/long off off $$”, I had the same question.
The molecule actually has a linear quadrupole moment (i.e. two antiparallel dipoles).

which you are modeling through 4 point charges. so there is no need to include explicit dipoles and to use a pair style that uses such dipoles.
it looks to me that this is a file with errors.
a correct pair style would be lj/cut/coul/cut or any variant with a damped or long-range coulomb or lj variant, if needed.

However, I am merely trying to be consistent with the prescribed force-field given below that is taken from the MolMod database.

there are some items that look inconsistent:

  • the length of the time step. you have metal units to the unit of time is 1 picosecond and thus a timestep or 0.1ps is quite unrealistic.

  • the mass for the hydrogen atom seems to be missing

  • the time constant for the thermostat with 10ps is quite large

http://molmod.boltzmann-zuse.de/

i’ve tried accessing this website, but since it doesn’t support https there are serious problems accessing it with an up-to-date webbrowser. :frowning:

axel.

5

Hi Axel,

Thanks for your response.

I did start to think of using gdb as I was installing the latest release. Valgrind is useful too…
I will follow your suggestions for debugging this point onwards.

The masses for the hydrogens are subsumed within those for the carbon in the atom-type 1 (mass --> 14.027, corresponding to -CH2)

I kept the timestep deliberately large to begin with.
First step anyways is to get the Lammps input script to work and then everything else follows when one starts to critically examine the output results and the impact of the simulation parameters on them.
At least that’s the iterative approach I follow when working with a new problem/system.

I agree that there are errors in the force-field files from the MolMod database.
However, I also do not want to change things and not be using the correct force-field parameters as they were intended to be.
So, it’s better to ask.

These guys have published results on the vapor-liquid equilibria and transport properties using the 2-Center-Lennard-Jones + Point-Quadrupole (2CLJQ) fields.
I will let you know if I hear back from them.

Sorry about the unsecured website…
The following link is secured:
https://enrico.mv.uni-kl.de/publications/molmod-database.html

but the database itself is not…
However, the entire database can be downloaded in one zipped file, if there’s any interest.

Many thanks…

Warm regards,
Vaibhav.

6

Hi Axel,

Thanks for your response.

[…]

I kept the timestep deliberately large to begin with.

it is too large by multiple orders of magnitude. it cannot work at all.

[…]

I agree that there are errors in the force-field files from the MolMod database.
However, I also do not want to change things and not be using the correct force-field parameters as they were intended to be.
So, it’s better to ask.

The database provides the original publications describing the parameters and force fields. I would consider that a much more reliable and complete source of information and would consult that first. Perhaps it would explain better under what circumstances and with which settings those examples would work well.

Unlike other databases of that kind it doesn’t seem to provide any information about validation of the parameters and inputs from the database (see openkim.org as an example for a cross-MD code database of potentials and implementation and database or reference results). I am always a bit hesitant to put too much trust in such databases, because they are often just a gimmick to secure funding as funding agencies seem to get easily excited about research programs that result in databases for collecting/sharing results. Few of them have shown staying power, e.g. ones at NIST and are structured and maintained to provide sufficiently comprehensive information. It is straightforward to collect stuff, but giving it context and validation is hard work (and frequently the funding runs out when the latter step is due).

Axel.

7

Thanks for pointing that out, I am more used to the coarse-grained simulations using USER-LB in Lammps where the time steps are sub-picoseconds. For atomistic simulations the timescales need to be on the order of femtoseconds, so yes a few of orders of magnitude off.

Checking their published papers and examining the parameters for the force fields closely is the next on my list of things to do.

Yes, having spent some time in academia, I am all too familiar with the fickle nature of funding and the different ploys employed to secure it.

However, I fervently do hope and wish that the funding for Lammps and its support continues in perpetuity. :blush:

In gratitude, :pray:

Warm regards,

Vaibahv.

8

[…]

However, I fervently do hope and wish that the funding for Lammps and its support continues in perpetuity. :blush:

The situation is not as good as you might think it is. We mostly get by because we have figured out ways to do a lot with very little.

LAMMPS currently survives primarily because it is deemed a crucial project for the success of researchers at Sandia and the DOE in general.

Plus over the last 10 months we have benefited a lot from the pandemic as that freed up extra time especially for the LAMMPS developers at Temple that would otherwise be spent on commuting and sitting in meetings and other distractions. Instead we could work for a significant amount of time on some internal refactoring and modernizing the code base, as well as working on long overdue projects like a programmer guide and a unit test infrastructure.

If it wasn’t for adopting git and GitHub some time ago and thus being able to offload more work to contributors and simplifying the task of integrating contribution, we would probably be overwhelmed by now and unable to keep up. There are lots of things we are unable to work on due to lack of manpower.

Axel.

9

That’s some upside to the pandemic… :slightly_smiling_face:
I personally think we have all become Zoombies including even the kids (2-3 year olds too) …

Your work certainly helps a multitude of researchers across the world!
I hope the funding agencies see the value in supporting Lammps development and provide you with the resources that you need to keep this good work going long into the future…

Warm regards,
Vaibhav.