processing time

[kukretiaditya]

i was practicing unidec pp and took the input data from this article https://doi.org/10.1021/acs.analchem.3c02010?urlappend=%3Fref%3DPDF&jav=VoR&rel=cite-as but it just keeps showing processing have i done any step wrong or it takes a lot of time ?

[michaelmarty]

Hmm. Can you try clicking open combined report or is it frozen? It looks like it got through everything when it says it's processing 114 of 114, but it may be stuck on the last file or something at the end. Also, which version are you using?

[kukretiaditya]

sir i am using version 8 with python latest version , this is what the cmd window of the unidec was showing

[michaelmarty]

Sorry for the delayed response. I've been out of the office for the holidays. I think I see your issue. The file name should point to the data file, not the excel file. You will also need to download all the raw files from MassIVE and update your data folder to match. It's basically not finding the raw data files. Here's the link to the data: https://massive.ucsd.edu/ProteoSAFe/dataset.jsp?accession=MSV000092242. The first image you posted has the right structure; I think you just need to download the data and update the "Data Directory" column.

[kukretiaditya]

Thank you very much for your response, and I sincerely appreciate your time despite the holiday season. I apologize for any inconvenience caused earlier.

[kukretiaditya]

so it is not possible to run it on unidec with just the excel input file , we would need the dataset on the massIVE too.

[kukretiaditya]

Downloaded the BsAb files through the ftp link using winSCP got downloaded in photo viewer format

[kukretiaditya]

worked 😁 ( open file option) , the add file option still gives the value error

[michaelmarty]

Great! Correct, you'll need to have the raw data in some format (.raw, .txt, .mzML). The excel file only points to where to find the raw data. You don't actually need to convert it to mzML. Even if the default program to view .raw files is the windows photo viewer, UniDec will still open them correctly.

I just tested the add file, and it seems to be working fine. For that, you select a data file, and it adds it to the list. It will only let you add certain file types that are recognized as MS data. Try that and let me know if it's still giving you errors. Thanks!

[kukretiaditya]

also an agilent .d folder cannot be uploaded in the upp right ?

[michaelmarty]

We're seeing the same bug here and working on it. Just to confirm, is it working when you are using Python scripting and the source code?

It should be possible to use .d folders in UPP. You cannot use the "Add File" to add it because the wxPython window doesn't recognize it as a file. However, if you edit the excel file, you can add it manually, and it should work. It's working for me on Agilent test data on my computer, but we've definitely got a bug with it.

[michaelmarty]

As for how it converts Agilent data, it's all in the Agilent DLLs. We use pythonnet (https://pypi.org/project/pythonnet/) which uses the common language runtime (import clr) for .NET code. Basically, it imports .NET functions from the DLLs and pretends they are Python functions. I'm not an expert in .NET, but a program called DotPeek is really useful for looking into the functions that are available within the DLLs.

[kukretiaditya]

in version 8.0.0 when i run a .d agilent folder in gui unidec it stops for a minute and then closes on it's own showing the same basetof.dll dependency error ; ;

[kukretiaditya]

We're seeing the same bug here and working on it. Just to confirm, is it working when you are using Python scripting and the source code?

It should be possible to use .d folders in UPP. You cannot use the "Add File" to add it because the wxPython window doesn't recognize it as a file. However, if you edit the excel file, you can add it manually, and it should work. It's working for me on Agilent test data on my computer, but we've definitely got a bug with it.

i get the basetof.dll error when I run the application directly and upload the .d folder in the GUI and it automatically closes

and same error when I run it through source code

to use .d folder through upp I will have to convert them manually to excel file with the required columns like sample name and data directory?

[kukretiaditya]

for agilent .d folder in ver 7.0.2 while converting it the cmd says failed native raw averaging and goes back to python averaging, I think that's bcz the .d folder data is maybe too big. so that error should not be a problem right?

[JoeyGrimes]

Hi Kukretiaditya, Thanks for being patient with us. I Have instructions on ensuring v 8.0.0 works properly.

Here is a recent executable build from dropbox that I have made:
https://www.dropbox.com/scl/fi/e5df1hnbdztgzzqiox4jo/UniDec_Windows.zip?rlkey=rkxbog66y82hzjclrmk66eecw&st=lajevmvp&dl=0

Please ensure you are running Python version 3.11.9, You can verify this by running python --version in command prompt.

You can install version Python 3.11.9 here: https://www.python.org/downloads/release/python-3119/

Once you have the correct version, make sure you have pywin32, you can see your current packages via running 'pip list' in command prompt. If it's not available please run 'pip install pywin32'

After this has been done. Please download the zip from dropbox, before extracting:
right click the zip->properties->unblock->apply

Inside of the extracted zip file UniDec_Windows. There should be a directory called _internal.

Then inside of _internal, there should be a file called register.cmd

Please run this, and it will register all of the agilent DLL's required(You only have to do this once).

You should be able to use agilent after this.

We will integrate this into the github branch soon.

Thank you,
Joe

[kukretiaditya]

it will take time for me to try on 3.11.9 but I did try on 3.12.7 and it did work but the txt file I got from the agilent .d folder (the raw data file) is a bit different from what I am getting in ver 7.0.2. Maybe bcz in in 7.0.2 when I upload my ,d folder it is not using the native raw averaging and pulling back to python averaging.

[kukretiaditya]

i did what you wrote but when i run or open register.cmd it shows

[JoeyGrimes]

Hi,

Can you try open command prompt and try 'pip install pywin32'

And let me know what it shows?

[kukretiaditya]

i also opened the terminal in the folder and installed the requirements .txt , pip install unidec and pip install massql
now when i open the app this comes

and this when i upload a agilent .d folder in ver 8.0.0
note - i am doing it on my other laptop with fresh download of py 3.11.9 in path .

[JoeyGrimes]

It looks like it registered properly. One thing I would test is trying to open other .d files and see if the issue persists.

Is there any way you can send me that .d directory via dropbox? I'd like to see if I can recreate your error.

Appreciate your patience.

[kukretiaditya]

really sry i am not sure if i can share the file, but let me try with some other files. Btw really curious can u tell me what you did to unidec(dropbox file) to rectify the issue or was the pre release ver fine? like the first error in this ver basetof.dll thing where it all started.

[kukretiaditya]

hmm the file you gave in dropbox does seem to be working on my main laptop with py 3.12 anaconda but the raw txt file that unidec version 8.0.0 is generating from the agilent .d folder is a bit diff than what unidec 7.0.2 is generating as I saw it maybe that's bcz while

generating 7.0.2 version shows "failed native raw averaging, using python averaging".

ver 8.0.0 photo ^

[kukretiaditya]

hmm v 7.0.2 is taking scans from 0 but 8 from 1

[JoeyGrimes]

Glad it worked! The scans shouldn't have anything to do with the difference in data. We just adjusted the display by +1 to accommodate for the 0th index for the end user.

The edits I made in the build was creating a script that would force register the necessary Agilent DLLs, and am currently trying to bundle pywin32 into the build to remove the step of 'pip install pywin32'. This should be done soon.

We did a bit of refactoring to Agilent in v 8, but it should be more accurate now than before.

Let us know if somehow you are seeing major discrepancies.

Thank you

[kukretiaditya]

yeah i think the refactoring to agilent is what is making the difference in data bcz the agilent .d folder is the same. the averaging must me more accurate than the one used in versions before .