I had some high hopes for your code as a way to simplify OPUS processing while retaining Linux compatibility for large batch jobs, however I ran into a snag while testing the program. Spectragryph loads the files just fine, so there may be something silly the Python script is stumbling on. When I try to read a file from my instrument, Python kicks back a Key Error.
First, some housekeeping:
- Python v3.8.10
- brukeropusreader version: 1.3 (from pip3)
- OS/Kernel: Ubuntu 20.04 focal/x86_64 Linux 5.11.0-40-generic
- Bruker Hardware: EM-27/Sun
Example 1
This is the most basic example of the error encountered.
Minimal Working Failing Example:
from brukeropusreader import read_file
opus_data = read_file('211118_EM27-SUN_#155_BA.0000')
Error raised:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/opus_parser.py", line 23, in read_file
opus_data = parse_data(data, meta_data)
File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/opus_parser.py", line 60, in parse_data
name, parser = block_meta.get_name_and_parser()
File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/block_data.py", line 67, in get_name_and_parser
return BLOCK_7[self.channel_type], parse_series
KeyError: 136
Example 2
Here, I dug through the code a bit to see what about the blocks is not behaving
Minimal Working Example:
import brukeropusreader
with open("211118_EM27-SUN_#155_BA.0000", 'rb') as infile:
mydata = infile.read()
metas = brukeropusreader.opus_parser.parse_meta(mydata)
for i in metas:
print(i.data_type)
Result:
0
96
64
48
7
23
7
7
23
7
0
23
23
160
32
As you can see, there are multiple block types that do not match your existing prototypes. Not accustomed to much Bruker data, I'm not sure if this is normal. However, the frequency of 0, 7, and 23 suggest that we have a reasonable cursor offset. This may be irrelevant to the BLOCK_7 key error I see, but it was an interesting observation. If most of OPUS code the author is used to seeing comes from more traditional benchtop instruments, the EM-27 may be introducing some strange new formats.
Reference Code
Binary data I used
https://www.dropbox.com/s/5jawojpjmboop0c/211118_EM27-SUN_%23155_BA.0000?dl=0
Hex dumped to plain text for your convenience
https://www.dropbox.com/s/vjwf0ibxlniptfz/tmp.xxd?dl=0
I had some high hopes for your code as a way to simplify OPUS processing while retaining Linux compatibility for large batch jobs, however I ran into a snag while testing the program. Spectragryph loads the files just fine, so there may be something silly the Python script is stumbling on. When I try to read a file from my instrument, Python kicks back a Key Error.
First, some housekeeping:
Example 1
This is the most basic example of the error encountered.
Minimal
WorkingFailing Example:Error raised:
Example 2
Here, I dug through the code a bit to see what about the blocks is not behaving
Minimal Working Example:
Result:
As you can see, there are multiple block types that do not match your existing prototypes. Not accustomed to much Bruker data, I'm not sure if this is normal. However, the frequency of 0, 7, and 23 suggest that we have a reasonable cursor offset. This may be irrelevant to the BLOCK_7 key error I see, but it was an interesting observation. If most of OPUS code the author is used to seeing comes from more traditional benchtop instruments, the EM-27 may be introducing some strange new formats.
Reference Code
Binary data I used
https://www.dropbox.com/s/5jawojpjmboop0c/211118_EM27-SUN_%23155_BA.0000?dl=0
Hex dumped to plain text for your convenience
https://www.dropbox.com/s/vjwf0ibxlniptfz/tmp.xxd?dl=0