Packing in a spherical shell gives empty pole regions

[fgrunewald]

I'm trying to pack proteins within in a spherical shell of a given diameter. It sort of works by defining two spherical shells and an intersection combination. For reasons I don't understand the pole regions appear to be empty though. See the lower left corner in the image that it is much less densely packed. On the opposite side the region is also rather empty (hence pole). It could be that the coordinates are not randomly sampled. Otherwise bentopy works brilliantly.

"space": {
    "size": [110, 110, 110],
    "resolution": 0.5,
    "compartments": [
      {"id": "a",
       "analytical": {
       "shape": "spherical",
       "radius": 38,
       "center": [55, 55, 55.0]
       }},
      {"id": "b",
       "analytical": {
       "shape": "spherical",
       "radius": 46,
       "center": [55, 55, 55.0]
      }},
      {
        "id": "c",
        "combination": "intersect(!a b)"
      }
    ]
  },

[ma3ke]

Thanks for reporting this strange issue.

My first thought is that the way the analytical spherical masks are set up causes uneven distances between the inside and outside boundary. In other words, if you were to stand in the center of the spheres and you would point outward in a random direction, the distance from the start of the compartment to the end of the compartment in that direction would not be entirely even across all possible directions.

Though I have not (yet) proven that this is causing your issue, I think it is very likely. What follows is some of my reasoning. Maybe not so interesting but I include it for posterity.

1. The phenomenon I describe here is necessarily true for the way in which the spheres are generated (a simple 'does this voxel fall inside the radius from the provided center or not' question).
2. Due to this, there simply is more accessible volume in some areas (notably, the principal-axis directions) than in others (the low-density poles you point out). Lower accessible volume multiplied by the same probability for placement results in lower placement probability in those areas. In other words, the probability distribution is very likely perfectly uniform, but the accessible volume is not. Not good!
3. The lime green structure in your visualization (thanks, it's very helpful!) does not seem as affected, right? That would track with the above explanation, as it is relatively unbothered by slight differences in the accessible volume, compared to the larger structures. In fact, they more likely occupy the low-density poles because these are not occupied by the larger structures.

Suggestions that may help for this model

Here are some thoughts on how to proceed.

• First a bad idea: Making the inner sphere a smaller and/or outer sphere b larger by a small amount could improve the available space. This is not a great idea, because clearly you would like your structures to sit within some shell. We should be able to do that well!
• A better idea: Try a finer voxel resolution. Usually, the 0.5 nm default resolution (the voxel side length) works great because it strikes a good quality/speed balance for larger systems. This is a relatively modestly sized system with rather tight tolerances (the larger structures appear to somewhat tightly fit in the 8 nm shell). Taking that resolution to 0.25 nm or even lower may provide better results with the analytical sphere masks.

For bentopy development

On the bentopy development side, this raises the following points.

• More sophisticated voxel circle/sphere cutting algorithms exist, for instance to produce graphically appealing results. These may be more appropriate if they produce more uniformly separated concentric spheres, for example.
• This issue also underscores the utility of debug outputs for the masks constructed during packing.

Next steps

I expect lowering the resolution will help. Curious to see your results. I'm setting up some tests myself as well, so if you don't come around to testing my suggestions that is no problem at all.

As part of this investigation I will likely implement debug output for masks. I'll leave this issue open until we're clear on the cause of your issue, have a good solution for it, and believe that solution to be user-friendly and properly documented.