Memory scaling estimate does not work well for non-periodic systems

[orionarcher]

As pointed out by @CompRhys in #412, the bounding box solution for non-periodic fails badly for some kinds of systems. Two distant molecules or one highly curved molecule are both examples of this.

would using [a bounding box] as the general case fail? for example if we had a 2d system or surface with a lot of vacuum the cell is not useful for determining the density?
guess the limiting case is something flat anthracene in a vacuum. If you have two molecules far enough apart then this heuristic would fail.

@CompRhys suggested using some nl based approach. This is probably the technically best solution, but needs to be implemented with a degree of care.

n_atoms*density is just to say it scales as the number of nearest neighbors? why not call a nl algorithm to estimate and go based on that?

[curtischong]

I was actually thinking about this problem last night as well. I think we're still not done with the heuristical method:

1. If the lattice is non rectangular, then we should always use the volume of the cell for the estimation (since I feel like if people include vacuum, they usually use rectangular-shaped cells)
2. Otherwise, we will use the aabb method to get a better volume estimate

[orionarcher]

If the lattice is non rectangular, then we should always use the volume of the cell for the estimation (since I feel like if people include vacuum, they usually use rectangular-shaped cells)

Agreed, this is still the case for periodic systems I believe. What change would you suggest to the current code?

For the NL solution, I think we could:

• run NL with ~5-6 A cutoff to get n_neighbors for each atoms
• scaling metric would be mean of mean(n_neighbors) * n_atoms == (n_neighbors / n_atoms) * n_atoms == n_neighbors, as @CompRhys identified above. This should scale linearly with density * n_atoms and is in some sense the "right" metric. I think I'd favor switching to this even though there is some additional expense.

[curtischong]

still in draft, but this is what I'm thinking of #417