Gmx editconf -pbc not removing periodicity

GROMACS version: 2023
GROMACS modification: No


I used gmx editconf -pbc to remove the periodicity of a slab of liquid water. However, it seems to only remove the periodicity of single molecules.

As you can see, there’s a layer of water outside the pbc box that doesn’t get mapped inside the pbc box.

Is the command supposed to work like that? Is there a way to remove the periodicity for the whole system and not just single molecules?

The -pbc option of editconf only makes molecules whole. trjconv has a lot more pbc options and some of them do what you want.


I was wondering if you eventually resolved the issue you’re facing. I’ve noticed that the behavior of water in my system is similar to what you described in your system.

I’m concerned because, starting the minimisation step, it abruptly stops with the following error:

“There are inconsistent shifts over periodic boundaries in a molecule type consisting of 4 atoms. The longest distance involved in such interactions is 1.601 nm, which is above half the box length. This molecule type consists of multiple parts, such as monomers, connected by interactions that are not chemical bonds, for example, restraints. Such systems cannot be treated. The only solution is increasing the box size.”

I’ve read through all the discussions on this error, but I don’t understand why it’s happening. I suspect that the “molecule consisting of 4 atoms” is the tip4 water model that I’m using. Perhaps solving the issue of the water layer may address this larger problem.

If there are any other suggestions, please help me in resolving this issue. If needed, I’ll send all the files used to generate the system.

Thank you very much.


It was some time ago, but if I remeber correctly I used ´trjconv´ with ´-pbc nojump´ to remove periodicity.
However, I never got the type of message you are reporting, at least not for this system. Usually I “just” get a bunch of LINCS warnings when trying to minimize systems with “untreated periodiciy” or with free interfaces.

Does this happen at minimization step 0? In that case it could be that you have (near) overlapping atoms and one jumps away very far. If that’s the case, lowering the step size should help.