Strip transformed Bruker data is interpreted incorrectly. about nmrglue

[jjhelmus]

@kfritzsc I'm certain that you know more about the format of Bruker pdata data that I do. I never used this type of data while I was doing NMR. I've never hear of data being "striped transformed", can you give more details on this process. Is this similar to to oversampling and decimation of data?

I think the logic of getting the correct unit_conversion object from this type of data should lie in the bruker.guess_udic function and not the fileiobase.uc_from_udic. The parameters of the universal dictionary should match the data to give the correct unit conversions, even if the file metadata incorrectly identifies these parameters.

That said I don't complete understand this issue, if you could provide a stand alone example it might be helpful.

[kfritzsc]

@jjhelmus

I've never hear of data being "striped transformed", can you give more details on this process.

Bruker has an option to only save some of the data points after Fourier transform. The range of points to be saved (i.e. the strip) is set using the options SI, STSI and STSR. SI is the total number of points in a given dimension, to help clarify: the number of points zero filled is SI-TD, where TD is number of points collected. STSI is the 'Strip SI', i.e. the number of point to keep after a FT. STSR is the 'Strip SR', this parameter controls the location of the first point to start keeping data (normally from the left of the spectrum).

Graphically:

In solid-state NMR it is desirable for many reasons to collect a larger spectral width in the direct dimension. On older spectrometers, due to filter restriction it is often the only option. Still it is silly to manipulate all of the extra points. Therefore, STSI and STSR can be used to save a large amount of memory and computation time.

Is this similar to to oversampling and decimation of data?

It is different. Although we sometimes do something like decimation and some FT tricks in the indirect dimension to prevent zero frequency artifacts.

I think the logic of getting the correct unit_conversion object from this type of data should lie in the bruker.guess_udic...

Okay, I will add this functionality to bruker.guess_udic.

My current problem is that SI is overwritten by STSI and the set SI is saved as a 'status parameter'. The parameter we need is therefore not in 'procs' but in the 'audit trail' saved to 'auditp.txt', for example '1/pdata/1/auditp.txt' . This file is in a slightly odd JCAMPDX format so I will have to write an additional parser for it.

After I parse the audit file, We should be able to make the 'effective' udic parameters for strip transformed data with something like:

# Careful, untested code.
strip_sw = (SI/sw) * STSI

strip_car = (SI/sw) * STSR + car

That said I don't complete understand this issue, if you could provide a stand alone example it might be helpful.

I will provide an example soon, I can not share the current data I am working on, but can look for some data of a model compound. It will take me a few days to get back to this.

[kfritzsc]

I forgot about the parameter FTSIZE, that makes things a lot easier.

[jjhelmus]

Alright, this creates a strip. Makes complete sense now. I was thinking in this was time domain data and got lost. Yes, the best method is to "fake" the various spectral parameters to give the correct parameters to the universal dictionary. NMRPipe does a similar procedure with the EXT function which extracts a region from a spectrum. In nmrglue the ng.pipe_proc.ext function also adjusts the spectral width and other additional parameters to account for the new layout of the data. I'll check out #50 shortly.

[jjhelmus]

I believe this is closed by #50. @kfritzsc if you can confirm.

[kfritzsc]

Thank you @jjhelmus!