Unexpected behaviour at high density

[jan-stevens]

The following input results in no placed molecules, which is unexpected behaviour. However, if I reduce the "number" of molecules I ask bentopy to place by a factor of 10, then all the 10000 ALA are placed correctly.

{
    "space": {
        "size": [20, 20, 20],
        "resolution": 0.5,
        "compartments": [
            {
                "id": "main",
                "shape": "spherical"
            }
        ]
    },
    "output": {
        "title": "test",
        "dir": "outputs",
        "topol_includes": []
    },
    "segments": [
        {
            "name": "ALA",
            "path": "ALA.gro",
            "number": 100000,
            "compartments": ["main"]
        }
    ]
}

I think this problem arises when you ask to place more molecules (in this case single beads) than fit in the 3D voxel space.

[ma3ke]

There is a good chance that the voxelization procedure for structures is not working as expected in single-bead cases. From reading this, and having encountered the problem at some time ago (though I thought it had resolved itself), it may be the case that voxelize(structure) where structure contains only a single bead produces a zero-sized voxelization.

In other words, for single-bead structures, the voxelization may just be ... nothing. Or perhaps a single-voxel space without any filled voxels.

At low densities, this will not be a problem, simply due to the very low probability of two single-bead structures being placed in close-enough proximity to hit each other. But when the density becomes large, there will be instances (perhaps only a few, that would be enough to wreak havoc) where beads are placed in exactly the same location (due to the voxelized discretization of positions).

So, when I come around to this (or somebody else, feel free), I will start out testing this hypothesis by investigating voxelize behavior for single-bead structures. In case that turns out to be correct, we'll have to look further.

[jan-stevens]

In any case, that is something good to check. However, I don't think that is the entire problem.

When I try to pack a larger molecule like FAD in a high density, overlaps still occur in the system.

The curious thing is that for macromolecules like proteins, these overlaps don't appear to happen (even at high concentrations).

[ma3ke]

Right, that really is very strange to me, how larger structures do not seem to cause this problem.

For now, I have added further assertions and checks to voxelize to guarantee that

• the number of points is at least one (empty structures would not make sense and indicate that something else has gone awry, at runtime or more likely in the configuration), and
• there is at least one 'filled' voxel in the voxelization (again, since an empty voxelization should be incorrect).

An assert that was already in place checked against the (0, 0, 0) voxels shape case. So that was not the problem.

When I run this against my test cases, and against a new single-bead test case (ALA.gro), none of these assertions are hit. This shows that my initial hypothesis was incorrect.

Next steps

Since it also occurs for larger molecules, it becomes more likely that the actual voxelization strategy is insufficient. (Beads can be right on the edge of a voxel yet only one voxel is filled in even though filling in 2 or up to 8 would be most appropriate.) To investigate this hypothesis, we could try a very conservative voxelization scheme, that draws 8 voxels around each point. This is not necessary in production, but it can be a useful check. If the problem goes away, that suggests our currect voxelization strategy is in fact at fault.

@jan-stevens, if you have a minute, could you give me the necessary files to replicate this issue:

• input.json (or whatever name).
• FAD.gro and other structures you used.
• Perhaps the mask you pack everything into, if you use one. (Though it seems rather unlikely that has anything to do with it.

You can just drop the files into this issue or send me the path to the file server. Thanks!