Dear LAMMPS groups,
Greetings! Recently when I try to run a DPD system with about 5000 atoms (not too much I suppose), on my personal Macbook of Quad-core CPU, I run into this “killed: 9” problem which terminates my job even before step 0.
I wonder if this is a LAMMPS-input-file-related issue or an issue with my computer itself.
Appreciate any suggestions! Thank you! I have attached the “error” message here.
Hi Grey
Based on the output you have posted, it seems that there are at least three major issues with your simulation setup:
Regards
Evangelos
Στις Πέμ, 30 Ιουλ 2020 στις 2:59 μ.μ., ο/η Grey Geng <greygeng120@…4215…> έγραψε:
there are two observations:
- your system is not charge neutral by a large margin, yet you are
using a long-range coulomb solver. that is a bad idea.
- your memory use for the kspace style is very large and your
(coulomb) cutoff is rather short. that will likely result in
inefficient performance but also may exhaust the available memory on
your computer due to excessive storage required for storing the FFT
grids.
Axel.
Hi Dr.Axel,
Thank you for your kind explanation! I fixed the net charge to make the box neutral. Nonetheless, for the second suggestion you proposed, based on what should I set the cutoff for coul/long pair style? I read the manual and I get that beyond this cutoff distance the Coulombic interaction is to be calculated in the reciprocal space or imaginary space.
I suppose that to set it larger would decrease the accuracy but mitigate the burden to do kspace calculation so that improve overall running speed? Maybe I am wrong, but I am just not sure how to determine this value. Appreciate any suggestions!
Regards,
Grey
Hi Dr.Axel,
Thank you for your kind explanation! I fixed the net charge to make the box neutral. Nonetheless, for the second suggestion you proposed, based on what should I set the cutoff for coul/long pair style? I read the manual and I get that beyond this cutoff distance the Coulombic interaction is to be calculated in the reciprocal space or imaginary space.
that is not quite how long-range solvers work. in broad strokes: you
could theoretically compute the long-range electrostatics either
completely in real space or completely in reciprocal space, but that
would be practically impossible. what you do now conceptually is that
you add a gaussian shaped counter charge in real space and subtract it
in reciprocal space. that will make both sums converge faster and you
can use a cutoff shorter than infinity. how fast this converges is
depending on the width of the gaussian. this leaves 3 adjustable
parameters: real space cutoff, reciprocal space cutoff, width of the
gaussian. if you now set a relative accuracy (like you have to do with
the kspace_style command), you can estimate the reciprocal space
cutoff and the gaussian width from the real space cutoff and the
requested accuracy since those 3 parameters are not independent. at
this point, for a given accuracy, you can redistribute the work done
in real space and reciprocal space by increasing or decreasing the
coulomb cutoff. if you do more work in real space, you need less
storage and thus do less work and spent less time in reciprocal space.
there is an optimum there. in my personal experience, the optimum is
often found with a setting where about 1/3rd of the time spent in Pair
is used for Kspace. but YMMV.
I suppose that to set it larger would decrease the accuracy but mitigate the burden to do kspace calculation so that improve overall running speed? Maybe I am wrong, but I am just not sure how to determine this value. Appreciate any suggestions!
my main suggestion is that you read up on how long-range
electrostatics work and make sure you understand it sufficiently well.
that will pay off in the long run. not always do the estimated
parameters work well. sometimes you need to choose manually (when I
learned running MD, that was the only option) and that requires a
better understanding than what you currently have. also, you will have
more confidence in what parameters you can modify without affecting
accuracy.
axel.