Allignment IDs overwriten by updated MS-DIAL version

[m-j-keller]

Bug report:
I have multiple versions of MS-DIAL installed for continuity with different ongoing lipidomics projects. I discovered that a reexported alignment result from one of my projects did not match the export I had originally generated months before. It had the same alignment IDs and metabolite names and such, but reference mass, reference rt, formula, ontology, INCHIKEY, and SMILES were all nonsensical for the listed metabolite name. After some testing, I’ve realized that if you save an MS-DIAL project, load it later and rerun the identification with a different version’s lipid library, the previous alignment result’s IDs will be replaced with lipids from the other version's library, which won’t necessarily correspond to the original IDs. When exporting the alignment parameters, it also replaces the library name, so there’s no record of the original processing and its IDs. This seems to be true for all the versions I’ve been using (4.70, 4.90, and 4.9221218).
Thanks!

[kozo2]

Hi @m-j-keller
Thank you for creating the issue. What you reported as a "bug" is actually the behavior we intended. Therefore, I will first convert this GitHub Issue into a Discussion. I will respond afterwards.

[m-j-keller]

Okay, thanks for checking on this. In my case, I didn't intend to reprocess with a different library, and must have entered something wrong. In any case, when I wanted to export an m/z matrix for my previous processing I was confused for a while by mismatching data. You can look at the attached document to see what I mean, but, as an example, alignment ID 1851 with an average mass of 369.3517 and name "ST 27:1;O" is matched with a reference mass of 927.8253, a formula of C55H111N2O6P and ontology of SM. Opening the data in the MS-DIAL program shows the same information, and I assumed the file had been corrupted before I figured out what was going on.

I would prefer retaining the matches to each alignment result, with a record of what library was used, to prevent data being overwritten and spurious results being generated.

Mz_3_2023841159-trimmed.txt

[m-j-keller]

Hey Kozo, I wanted to check in and see if there are any thoughts on how this should be treated going forward?