Error when running `D = OpenTIMS(path)` in python.
LipidAnalysis opened this issue · 11 comments
I meet the following error when running D = OpenTIMS(path)
in python.
"RuntimeError: dlopen(/root/anaconda3/envs/python367/lib/python3.6/site-packages/opentims_bruker_bridge/win64/timsdata.dll) failed, reason: /root/anaconda3/envs/python367/lib/python3.6/site-packages/opentims_bruker_bridge/win64/timsdata.dll: invalid ELF header"
What could be the possible reason?
Hi,
It seems that for some reason your Anaconda setup couldn't find/load the .so file containing conversion functions, and, sadly, the error reporting in this situation is completely misleading.
Basically we distribute a linux, win32 and win64 version of the library, and the function just tries loading them until one succeeds. The nasty thing is it reports only last error, which, well, of course a win64 dll isn't going to load on Linux. However, why did the .so fail? Well, that remains to be seen.
Long story short, would you mind checking out the devel branch of opentims, installing opentimspy from there, and reporting what happens? Hopefully it'll at least be a more enlightening error message ;)
Thank you for your response!
I met the error when I used a jupyter-lab on a web-server. As you said I forgort to download the '.so' or '.dll' first. Currently, I can read the '.d' file.
Unfortunately, I meet another problem that I cannot get a proper "inv_ion_mobility" value, the values changes even when I change to columns to query. For example, when I use columns ["frame", "inv_ion_mobility"], I will get mobility values around 1.5, but when I add "scan" in columns, I will get values from 1e-5 to 1e5. Does it occur on your data?
P.S. My data is collected from TIMS but not TIMS pro, does it matter?
Hi,
It might matter: if you could, please share the data with us to inspect it.
Best,
Hi, MatteoLacki!
I have sent you an email, and my email address is "zhangdh17@mails.tsinghua.edu.cn", Please check it out.
Thank you!
Okay, I have reproduced this, now I'm investigating
Okay, it does seem to be a case of different file format. We'll have to confirm this with Bruker people, and either add support, or at least cleanly fail (throw an appropriate exception) when we detect something like this. We hope to have some more info by the end of the week.
Thank you for your reply and look forward to a good result!
Is there any progress in this field?
Hi,
Currently we do not support this data. This is, unfortunately, an older inefficient scheme that Bruker does no longer use.
We are still in touch with Bruker on the case and if it is not too difficult to implement eventually do it, but they are pretty busy there and I would not bet money on that getting to be done quickly, sorry.
Best,
Thank you for your response!
It seems impossible for me to collect CCS information now. But good news is the instrument in my Lab will be upgraded soon, and data can be analyzed much easier.
Thanks again for your help!