Thank you for your help dr. Kohlmeyer,
are you sure that the model is what you want it to be? ... normally the tether point for the polymer would be taken as an extra point particle on or near the surface of that "big" particle and then the extended particle formed with fix rigid from the central particles and the tether point. and then there would be no point in using atom style sphere. the rotation to be monitored would be that of the rigid object.
I’d better use your proposed solution indeed. Thanks for pointing that out.
when asking this kind of question, please always include exactly which LAMMPS version you are using and on what platform and whether in parallel or not (and with MPI/OpenMP/GPU or a what combination of those
I completely forgot. My problem will likely be solved by your suggestion, but for future reference (assuming it is not caused by user error, which it usually is):
-
LAMMPS 3 Mar 2020
-
Running lmp_serial
-
MPI/OMP/GPU off
-
Ubuntu 20.04 (Linux 5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
-
Cmake configuration log, cmake build log, and detailed hardware info are attached if required
-
g++ version 9.3.0-10ubuntu2, gcc version 9.30-10ubuntu2
-
The cmake presets file referenced in the cmake options below is also attached.
Cmake command ran for configuration:
cmake -D BUILD_MPI=no -D BUILD_OMP=no -D LAMMPS_MACHINE=serial -D WITH_GZIP=yes -D LAMMPS_MEMALIGN=64 -D LAMMPS_EXCEPTIONS=yes -D PKG_USER-INTEL=yes -D BUILD_DOC=yes -D BUILD_TOOLS=yes -C …/cmake/presets/custom2020_04_28serial.cmake -D PKG_PYTHON=on -D BUILD_SHARED_LIBS=on -D CMAKE_INSTALL_PREFIX=$VIRTUAL_ENV -D PKG_MPIIO=no -D PKG_USER-LB=no -D KOKKOS=no -D PKG_USER-NETCDF=no -D PYTHON_EXECUTABLE=…/…/…/pythonvenvs/py38lammps/bin/python3 …/cmake
are you sure that your time step and neighborlist settings are sufficient to result in a stable, non divergent time integration?
Quite sure. The RMS angular displacement should be on the order of microseconds/rad to ms/rad, whilst the shortest timescale arises from the bond vibrational periods which are ~ ps. The integrator should be stable below 180fs, and if I understood this paper by Toxvaerd correctly (also assuming the conclusions are correct), with a thermostat enabled the limit could be increased up to twice the usual limit for integrator stability (for velocity-verlet). It would not be strictly stable but higher-order modes are damped such that their impact should be negligible and ensemble observables should be valid.
I currently use a timestep of 330fs (=0.017 in reduced units) with the langevin thermostat enabled. With the thermostat disabled at dt = 180fs, the ratio of RMSF total energy to RMSF kinetic energy remains < 2e-3 and the ratio of RMSF total energy to mean total energy < 1e-4 for 1e6 timesteps at 300K.
Regarding the neighbor settings; there are no dangerous builds reported, and because I’m performing short test runs I build every step. I use a large skin distance (multi style), effectively annulling the use of a neighbor list altogether, which is fine for now considering the low particle count and short runs.
Joost
cmake_build_output.log (261 KB)
cmake_config_output.log (7.8 KB)
cmake_config_output.log (7.8 KB)
custom2020_04_28serial.cmake (897 Bytes)
hardware_info.txt (27.7 KB)