I was checking the pair_lj_cut_coul_long_cs.cpp file. In the following code,
respa_enable is set to 0 in the function
PairLJCutCoulLongCS::PairLJCutCoulLongCS(LAMMPS *lmp) : PairLJCutCoulLong(lmp). But
void PairLJCutCoulLongCS::compute_middle(), and
void PairLJCutCoulLongCS::compute_outer(int eflag, int vflag) functions are present in subsequent lines.
In the LAMMPS documentation, it says we can see the corresponding doc pages for pair styles without the “cs” suffix to see how rRESPA is handled by theses pair styles. I tried RESPA style and it is running with lj/cut/coul/long/cs without LAMMPS throwing any errors. But is it a bad idea to use RESPA style with this pair style? And does this variable
respa_enable set to 0 really disables anything?
P.S.: I’m checking with lammps-23Jun2022 version.
PairLJCutCoulLongCS::PairLJCutCoulLongCS(LAMMPS *lmp) : PairLJCutCoulLong(lmp)
ewaldflag = pppmflag = 1;
respa_enable = 0; // TODO: r-RESPA handling is inconsistent and thus disabled until fixed
single_enable = 0; // TODO: single function does not match compute
writedata = 1;
ftable = nullptr;
qdist = 0.0;
There are multiple ways how pair styles can be used with r-RESPA.
The standard way of how to use pair styles with r-RESPA uses the “pair” keyword and is compatible with all pair styles since it calls the (polymorph)
However, you can also evaluate the forces from close neighbors more often than those from farther away. I that case you would use the “inner” and “outer” keywords, or for calculations using with very long cutoffs, even “inner”, “middle”, and “outer”. In that case the corresponding alternate compute functions are called and the “respa_enable” flag indicates whether they are functional. As the comments indicate, they are not functioning correctly for the
lj/cut/coul/long/cs pair style, hence those range based RESPA levels may not be used.
This is explained in the
P.S.: Here is a simple “trick” for checking whether the r-RESPA functionality works correctly.
If you use
run_style respa 2 1 [...] or
run_style respa 3 1 1 [...] the trajectory should be initially identical to that from
run_style verlet until the small differences from floating-point math start to become relevant (they will grow exponentially and faster for
fix npt than for
fix nve). The comments you quoted indicate that this specific test did not work for the pair style in question.
Thank you, I understand now