Triclinic/Cubic liftable molecule ends up broken

[BartBruininks]

There is a test system for a small ligand in a triclinic box. The ligand is broken after MDVWhole even though it is absolutely liftable. It appears that for some reason the bead placement is of by a voxel or so. We need to inspect this further. For now be very careful with triclinic boxes (not sure yet if this is also true for cubic systems).

This is a serious bug and needs to be looked into and fixed!
broken_triclinic_liftable.zip

[BartBruininks]

I feel like this has to do with the difference between floor/round/fix in numpy. I think we want to round towards the closest integer towards 0 but we use floor. For negative values this is wrong and we should use fix instead. I did not take a closer look, but it seems to go wrong when we cross over a negative border.

[BartBruininks]

Here is the raw input XTC of the molecule.
LIG.zip

[BartBruininks]

I feel like we had this problem before, maybe I made an error with a git merge somewhere and undid the fix we had in the past? Or the fix in the past did not completeley resolve the issue.

[BartBruininks]

I also added a single PDB of a single molecule where it fails.
broken_LIG_anonymous.zip

[BartBruininks]

I am running tests on a cubic box with water and a single lipid and a triclinic box with a single lipid (+/- 4 nm in size) to see if we can reproduce this error. Just to be sure nothing weird is going on in this specific simulation.

[BartBruininks]

The artifact also happens in a cubic box, it is pretty rare but it occurs. I will add some of the problematic frames in my test system to this issue tomorrow.

[BartBruininks]

The frame before is still behaving well in which the displacement is only over one PBC plane, then in frame 716 (after removing the initial frame) it goes wrong and in the next frame it is ok again. Below are the renders of 716 (top) and 717 (bottom). Both are the raw frames i.e. not completed, 717 gets completed without any problems.

[BartBruininks]

In the triclinic box the errors also appear to be around the double/triple crossings. IMO the origin for this bug is either in the calculation of the bridges, or in how we handle the pathfinding towards the center segment. I will take a look in the latter.