NaNs in dump; Langevin GJF flags compatible with finite-sized angular momentum thermostatting options?

Hello all,

As stated in the subject, I wonder whether the gjf options for fix langevin are compatible with the angular momentum thermostat option for finite-sized particles.
In other words; is the omega yes flag compatible with the gjf vhalf and/or gjf vfull options?

I get NaNs in the dump files for the omegax, omegay, and omegaz values if I use both.

For context:

I’m running CG simulations of a tethered nanoparticle. The tether monomers consist of point-particles, and the larger tethered particle is finite-sized.
The particle is bound to the last tether monomer by harmonic bond and angle potentials, so I use atom_style hybrid angle sphere to add rotational inertia to the larger particle.

Example input and data files are attached (for LJ and si units; at first I thought it might have had something to do with underflowing exponents in calculations under the hood using si units).
A png of one dump entry is also attached.

I hope I’m not overlooking something easy (or maybe I do…). I haven’t been able to google an answer as of yet, and there doesn’t seem to be an answer in the docs yet either.

Thanks in advance for any help!

Joost Bergen
Msc. Student at Eindhoven University of Technology
Netherlands

35030_df_lj.df (1.26 KB)

35030_df_si.df (1.53 KB)

35030_input_lj.in (3.07 KB)

35030_input_si.in (3.85 KB)

single_dump_nan_hybrid_angle_sphere.png

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).

thanks,
axel.

a couple more questions:

are you sure that the model is what you want it to be?
i don’t see any use of fix rigid. the “big” particle is connected to the tethered polymer via its center and the bond will treat it as a point particle, so there is not much of a value in time integrating its rotation. it can spin around, but that has no impact on anything. 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.

are you sure that your time step and neighborlist settings are sufficient to result in a stable, non divergent time integration?
time integration of rotation frequently requires shorter time steps than for translation to not diverge. the NaNs could be an indication of such a divergence.

axel.

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)

Aidan can likely answer your original Q which is
whether the (relatively new) glf option for fix langevin
also works in conjunction with the omega option for
thermostatting rotational DOFs. My guess is no,
or at least no one has probably tried to use it for that.

Steve