Process rank 3 with pid O exited on signal 9(killed)

So whenever I try to run the simulation I am finding this message process rank 3 with pid 0 exited on signal 9 (killed). What’s the probable solution? I am using linux as Os.

Impossible to say with so little information.

following is my input file:

units		real
variable cfac equal 1.01325e-4
variable cunits string GPa

atom_style		full
boundary		p p p



bond_style		harmonic
angle_style		harmonic
dihedral_style	        charmm
improper_style          cvff

read_data		tkx50_supercell_file.dat


pair_style       lj/charmm/coul/long 2000 2200
include                paircoefficient.txt

kspace_style	pppm 1.0e-4


neighbor		2.0 nsq
neigh_modify	delay 0 every 1 check yes one 100000 page 1000000

# Define minimization parameters
variable etol equal 0.0 
variable ftol equal 1.0e-10
variable maxiter equal 1000
variable maxeval equal 1000
variable dmax equal 1.0e-2

# Setup minimization style
min_style	     cg
min_modify	     dmax ${dmax} line quadratic


######################################
# EQUILIBRATION
timestep 0.001
velocity all create 300 12345 mom yes rot no
fix 1 all npt temp 300 300 1 iso 0 0 1 drag 1 

# Set thermo output
thermo 1000
thermo_style custom step lx ly lz press pxx pyy pzz pe temp
dump trj all atom 1000 tkx.lammpstrj
# Run for at least 10 picosecond (assuming 1 fs timestep)
run 1000

as for my pc configuration, it has 16gm Ram, and nvidia rtx3050 gpu

What is the complete console output? What is your command line? Have you tried running with just 1 processor?

the command line was
mpirun -np 4 -in input.in


this was the output

This is not useful since it is missing the top part.
Why can’t you cut-n-paste from the terminal or logfile. Attaching pictures is wasteful and interferes with people using the search function.
Also, what happens with only 1 process?

Why are you using such insanely large cutoffs?

Those are about 150x larger than typical for this pair style in real units.
Since you are using a kspace style (and with rather low accuracy setting), there is no accuracy gain at all from such large cutoffs.

You probably are simply running out of available memory for the neighbor lists due to this.

GI-GO!

Please note that this output is inconsistent with the input you posted.

This is all very frustrating to have to ask for so many things and then not even getting what I am asking for or inconsistent data.

Invalid MIT-MAGIC-COOKIE-1 keyLAMMPS (29 Sep 2021 - Update 2)
Reading data file ...
  triclinic box = (-0.29800000 0.00015000000 3.9000000e-05) to (10.554000 23.319550 12.947885) with tilt (0.0000000 -1.1920200 0.0000000)
  1 by 2 by 2 MPI processor grid
  reading atoms ...
  1152 atoms
  scanning bonds ...
  3 = max bonds/atom
  scanning angles ...
  6 = max angles/atom
  scanning dihedrals ...
  6 = max dihedrals/atom
  scanning impropers ...
  1 = max impropers/atom
  reading bonds ...
  1200 bonds
  reading angles ...
  1664 angles
  reading dihedrals ...
  2016 dihedrals
  reading impropers ...
  320 impropers
Finding 1-2 1-3 1-4 neighbors ...
  special bond factors lj:    0        0        0       
  special bond factors coul:  0        0        0       
     4 = max # of 1-2 neighbors
     5 = max # of 1-3 neighbors
    10 = max # of 1-4 neighbors
    11 = max # of special neighbors
  special bonds CPU = 0.000 seconds
  read_data CPU = 0.006 seconds
PPPM initialization ...
WARNING: System is not charge neutral, net charge = 4.8800000 (../kspace.cpp:325)
  using 12-bit tables for long-range coulomb (../kspace.cpp:340)
  G vector (1/distance) = 0.0020200104
  grid = 4 1 4
  stencil order = 5
  estimated absolute RMS force accuracy = 6.9337893e-06
  estimated relative force accuracy = 2.0880901e-08
  using double precision KISS FFT
  3d grid and FFT values/proc = 378 8
Neighbor list info ...
  update every 1 steps, delay 0 steps, check yes
  max neighbors/atom: 100000, page size: 1000000
  master list distance cutoff = 1602
  ghost atom cutoff = 1602
  1 neighbor lists, perpetual/occasional/extra = 1 0 0
  (1) pair lj/charmm/coul/long, perpetual
      attributes: half, newton on
      pair build: half/nsq/newton
      stencil: none
      bin: none
Setting up Verlet run ...
  Unit style    : real
  Current step  : 0
  Time step     : 1e-05
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 0 on node rifat127-GF63-Thin-11UC exited on signal 9 (Killed).

the output console

This will also produce problems down the line, even with a corrected choice of cutoff. This is almost certainly showing a problem with the assignment of force field settings and partial atom charges.

LAMMPS (29 Sep 2021 - Update 2)
Reading data file …
triclinic box = (-0.29800000 0.00015000000 3.9000000e-05) to (10.554000 23.319550 12.947885) with tilt (0.0000000 -1.1920200 0.0000000)
1 by 1 by 1 MPI processor grid
reading atoms …
1152 atoms
scanning bonds …
3 = max bonds/atom
scanning angles …
6 = max angles/atom
scanning dihedrals …
6 = max dihedrals/atom
scanning impropers …
1 = max impropers/atom
reading bonds …
1200 bonds
reading angles …
1664 angles
reading dihedrals …
2016 dihedrals
reading impropers …
320 impropers
Finding 1-2 1-3 1-4 neighbors …
special bond factors lj: 0 0 0
special bond factors coul: 0 0 0
4 = max # of 1-2 neighbors
5 = max # of 1-3 neighbors
10 = max # of 1-4 neighbors
11 = max # of special neighbors
special bonds CPU = 0.001 seconds
read_data CPU = 0.009 seconds
PPPM initialization …
WARNING: System is not charge neutral, net charge = 4.8800000 (…/kspace.cpp:325)
using 12-bit tables for long-range coulomb (…/kspace.cpp:340)
G vector (1/distance) = 0.092756088
grid = 4 4 4
stencil order = 5
estimated absolute RMS force accuracy = 0.0010615685
estimated relative force accuracy = 3.1968821e-06
using double precision KISS FFT
3d grid and FFT values/proc = 729 64
Neighbor list info …
update every 1 steps, delay 0 steps, check yes
max neighbors/atom: 100000, page size: 1000000
master list distance cutoff = 32
ghost atom cutoff = 32
1 neighbor lists, perpetual/occasional/extra = 1 0 0
(1) pair lj/charmm/coul/long, perpetual
attributes: half, newton on
pair build: half/nsq/newton
stencil: none
bin: none
Setting up Verlet run …
Unit style : real
Current step : 0
Time step : 1e-05
WARNING: Communication cutoff 32 is shorter than a bond length based estimate of 1369.390925. This may lead to errors. (…/comm.cpp:730)
ERROR: Non-numeric pressure - simulation unstable (…/fix_nh.cpp:1069)
Last command: run 1000

this is the output for single processor and shorter cut-off length of 30

This suggests that you have bogus bond coeff values somewhere.

If you had done proper literature research on your force field, you should have found that typical cutoffs for CHARMM style interactions are in the range 12-14 angstrom.

This is just a consequence of bad input.

Sorry, my bad. I found the mistake I did while making the forcefield parameters file (input energy and distance in wrong places). However, upon the correction I reran the simulation and still the nonnumeric pressure -similation unstable error appearing.
I am rechecking the charges.
Thanks

One more thing, the cif file I used (which I collected from CCDC) provided me the unit cell with uneven cations and anions, so I think the system will still remain not charge neutral

There are probably other issues with your data file or other input.

You probably have partially occupied positions or something else is not complete or correct. A non-neutral unit cell is not stable and would explode instantly. LAMMPS can avoid this with a mathematical trick, but you need to check what the real physical situation is.

Overall, it looks to me that you are putting too much trust into tools you are using and do too little checking on the physical meaning of what you do.

My suggestion is to take a step back and practice simulations with something simpler and also start with an orthogonal box. There are many more little details that I saw that are not good practice but would be to laborious to point out and explain. You need to find a person that is willing to properly tutor you. There is more to MD simulations to just silence all warnings.

Thanks for your suggestions and help. I will try to follow accordingly and recheck everything from the scratch

As Axel said, signal 9 on Linux is usually OOM Killer (out of memory). Linux Out of Memory killer - Knowledge Base.

1 Like