Unable to read Bruker 2D ser file if half or less slices were recorded

[FlorianSchreiner1]

When trying to read the Bruker raw data of an unfinished or prematurely stopped 2D experiment with half or fewer slices acquired, ng.bruker.read() fails to correctly guess the shape of the data. As far as I have been able to pinpoint the issue, it seems like ng.bruker.guess_shape() introduces it.

As an example lets take a 2D acquisition dataset with 1024 points in the direct dimension and 8 slices in the indirect dimension. guess_shape() would correctly calculate the shape as [0, 0, 8, 1024] in line 1060 or 1062 depending on the spectrometer used.
If only 4 slices in the indirect dimension were acquired, this calculation would again yield the correct shape of [0, 0, 4, 1024]. The problem will then be introduced in lines 1066 and 1067 of nmrglue/fileio/bruker.py while trying to interpret the residual file size to [1, 2, 4, 1024]. As far as I can tell, this problem occurs since TopSpin saves the raw data files with the intended size, not the actual size of the acquired data.

Additionally, lines 1066 and 1067 do not account for DTYPA, so if the example above is calculated for a NEO type spectrometer the resulting shape would be [1, 4, 4, 1024]. This behavior also results in ng.bruker.read() not being able to correctly read 2D data from NEO type spectrometers in general, since guess_shape() will always assume a third dimension (with the example above [1, 2, 8, 1024] if all slices were acquired).

I think the best way to handle this would be to first include DTYPA in lines 1066 and 1067 and only include dimensions for which a corresponding acquisition dictionary was found. The potentially missing slices could then be extrapolated via the file size.

[NanoporeAna]

When using nmrglue==0.11 to process 2D spectra (HSQC, COSY, etc.), I encountered similar problems where the guess_shape function incorrectly determined data shapes as (2, 256, 1024) or (2, 256, 2048).Upon investigation, I found that the function calculates remaining dimensions by dividing the file size by the product of direct and indirect dimension sizes, but it appears to overlook the dtype size. For Bruker files, when dtypa=2, the data type is 64-bit double (8 bytes), yet the original code uses a multiplier of 4 bytes.
Here is my modified calculation:
Original code:

if dtypa == 2:
    shape = [0, 0, td2, int(np.ceil(td0 / 128.) * 128.)]
else:
    shape = [0, 0, td2, int(np.ceil(td0 / 256.) * 256.)]

if shape[2] != 0 and shape[3] != 0:
    shape[1] = fsize // (shape[3] * shape[2] * 4)
    shape[0] = fsize // (shape[3] * shape[2] * shape[1] * 4)

Modified version:

if dtypa == 2:
    shape = [0, 0, td2, int(np.ceil(td0 / 128.) * 128.)]
else:
    shape = [0, 0, td2, int(np.ceil(td0 / 256.) * 256.)]
if dtypa==2:
    if shape[2] != 0 and shape[3] != 0:
        shape[1] = fsize // (shape[3] * shape[2] * 8)  # Changed from 4 to 8 for 64-bit
        shape[0] = fsize // (shape[3] * shape[2] * shape[1] * 8) # Changed from 4 to 8
elif dtypa==0:
    if shape[2] != 0 and shape[3] != 0:
        shape[1] = fsize // (shape[3] * shape[2] * 4)
        shape[0] = fsize // (shape[3] * shape[2] * shape[1] * 4)

This modification properly accounts for the 8-byte size of double-precision data when dtypa=2, and it has resolved the shape guessing issues in my case. However, I'm not entirely sure if this adjustment is comprehensive enough and would appreciate everyone's verification