fene command resulting in a lot of printing


When I run the following commands (at end of post), I get an endless stream of:

“r = 0.xxxxxxxx r0=1.6 rlogarg=0.xxxxxxx”

It doesn’t seem that “rlogarg” is related to the r value, as it should be less then 0 then, whereas here it seems to always be (so far as I’ve observed) between 1 and 0, as well as r. the r0 value appears to be a parameter set in the in. file. I believe here that “r” is a bond distance, but otherwise, I can’t tell why the program is printing off this stream of information, and how to control or stop it.


in.chrom file:

units lj
dimension 3
processors * * *
boundary f f f

neighbor 5.0 bin
neigh_modify every 1 delay 0
timestep 0.00001

atom_style hybrid angle ellipsoid

read_data data.chrom
special_bonds fene

pair_style soft 1.12246
pair_coeff * * 1.0 1.12246

bond_style fene
bond_coeff 1 30 1.6 0 0

comm_modify cutoff 6.5

angle_style cosine/periodic
angle_coeff 1 3 -1 1

velocity all create 1.0 2349852

thermo 250
dump 2 all custom 100 md.lammpstrj id type x y z
fix 1 all nve/dotc/langevin 1.0 1.0 100.0 100 angmom 10
run 8750

please always report which specific LAMMPS version you have.
when using development code, also the git hash, i.e. something like first two lines from ./lmp -h:

Large-scale Atomic/Molecular Massively Parallel Simulator - 30 Jun 2020
Git info (write-bonus-data / patch_30Jun2020-134-g5cef86d7b7-modified)

what you see is output from debug code that was only briefly included in the development tree and has been removed before the 30 June 2020 patch release.

please do not use the development version if you are not doing development or don’t know how to address such issues.

if you want to download LAMMPS via git, please check out the “unstable” or “stable” branches which correspond to the patch or stable releases, respectively.
those are checked against our test suites before being updated.

the LAMMPS developers do NOT recommend to use “nightly” builds or development code for any kind of production simulations.
it is the nature of development that things may get (temporarily) broken, only to get better afterwards.

over the last 3-4 months the LAMMPS development has been particularly active and we are doing and have done several significant refactoring projects to modernize the core code base. so breakage is more common than at other times and thus the risk of having issues in the development version is higher.



Thank you for your swift reply, that makes sense, I will look more into it - I was having issues building LAMMPS from the downloadable files at the site (the stable version from March 3 2020, https://lammps.sandia.gov/download.html), so currently I am using the pre-built Ubuntu Linux executable found here: https://lammps.sandia.gov/doc/Install_linux.html

I believe I downloaded it two weeks ago.