Add `sample_rate` or `resolution_cutoff` options for `to_reciprocalgrid` about reciprocalspaceship HOT 5 CLOSED

I think that's reasonable. That latter case can still be implemented easily in gemmi for first thresholding at the given dmin prior to the to_gemmi() call.

Just to summarize the proposed API change, there will be two mutually exclusive sets of options:

1. DataSet.to_reciprocalgrid(grid_size=(int, int, int))
2. DataSet.to_reciprocalgrid(sample_rate=float) or DataSet.to_reciprocalgrid(dmin=float) or DataSet.to_reciprocalgrid(sample_rate=float, dmin=float)

from reciprocalspaceship.

As it happens, I had just written this little helper function as a workaround:

def spacing_to_gridsize(spacing, cell):
    """
    Compute the optimal gridsize based on unit cell size and desired spacing

    spacing : float
        Desired (approximate) grid spacing in Angstroms
    cell : gemmi.UnitCell
        Or anything similar with attributes a, b, and c

    NOTE: does not support different spacing in each direction, but in theory could
    """
    gridsize = []
    for dim in [cell.a, cell.b, cell.c]:

        gridsize.append(int(dim // spacing))

    return gridsize

from reciprocalspaceship.

I think the most reliable implementations would use gemmi for this:

resolution cutoff:

In [1]: ds.cell.get_hkl_limits(0.95) # Grid size should be this *2 to handle negative values
Out[1]: [28, 33, 36]

sampling rate:

In [2]: ds.to_gemmi().get_size_for_hkl(sample_rate=3)
Out[2]: [80, 96, 108]

from reciprocalspaceship.

Just a note. sample_rate and resolution_cutoff / dmin both influence grid size but are not mutually exclusive concepts. I think we should support both simultaneously so that

ds.to_reciprocalgrid("F", sample_rate=3., dmin=5.)

produces a 3x oversampled grid from the reflections out to 5A.

Does that make sense? Am I talking crazy?

from reciprocalspaceship.

i think we can default sample_rate to 3. and dmin to the resolution of the mtz.

from reciprocalspaceship.