ThermoRawFileParser produces files, which can not be processed with msconvert

[sampie]

When converting raw file to mzML with ThermoRawFileParser:
$ mono /opt/ThermoRawFileParser/ThermoRawFileParser.exe -f=2 -m=0 -i=170413_12mix_DIA_14.raw -b=170413_12mix_DIA_14.mzML -p

The mscovert can not process the converted file, but gives an error message about invalid cvParam
$ msconvert 170413_12mix_DIA_14.mzML --32 --zlib --filter "peakPicking false 1-" --mzXML -o ./
Invalid cvParam accession "1003145
I am not sure if this is a problem is in use-case or in ThermoRawFileParser or in msconvert (ProteoWizard release: 3.0.18344)

The raw file can be found from https://www.ebi.ac.uk/pride/archive/projects/PXD008738

[caetera]

Hi @sampie ,

Thank you for your interest in ThermoRawFileParser.
This CVTerm corresponds to "ThermoRawFileParser" as processing software. It was added to PSI-MS controlled vocabulary only recently (since version 4.1.48). ProteoWizard (even the latest version) still uses older version of PSI-MS (4.1.41) and, therefore, this term is missing.
To fix it properly ProteoWizard should include the latest version of PSI-MS in their software. As a temporary fix, you can use version 1.3.2, that does not use the new CVTerm or replace it in the mzML file produced by TRFP.
Basically, changing the accession in the following line
<cvParam cvRef="MS" accession="MS:1003145" name="ThermoRawFileParser" />
to any recognized accession, for example
<cvParam cvRef="MS" accession="MS:1000799" name="ThermoRawFileParser" /> (unreleased software)
or
<cvParam cvRef="MS" accession="MS:1001457" name="ThermoRawFileParser" /> (data processing software).
Note the change in accession field, the actual number does not seem to be checked by msconvert, so it is possible to use any accession number, even if it does not make any sense. This will produce mzML that won't be fully valid, but will eliminate the error.

[sampie]

Thank you! I'll try 1.3.2.

[hechth]

Just as a hint: this also causes problems in tools based on proteowizard such as mzR which is used as the main reader of mzml files in R, so many downstream tools depend on it.

[nielshulstaert]

Thanks it's indeed annoying that you can't use the generated files downstream. Should we release a new version with the previous value for the CV param @caetera ?

[martenson]

My 2c: I believe it would be beneficial to do this (surprisingly) breaking change in sync with the downstream tools, so the whole chain has time to prepare releases and update dependencies.

[caetera]

@nielshulstaert Yes, I think we have to release some sort of quick-fix for now. I was not expecting this small change will have such a huge effect.
@martenson I agree that I should have been more aware of downstream tools when implementing the change.

It would be nice, however, to let the developers of the downstream tools aware that the change is to be implemented soon. Display some sort of warning, but I cannot come with a good idea how that is to be implemented

[nielshulstaert]

Ok thanks for all the input, I'll release a new version later today.

[hechth]

Basically, proteowizard has to adapt their reader and then mzR has to link the newer version of proteowizard.
I created an issue on pwiz and once this is handled, I can contribute to integrating it in mzR.

Can't make any guarantees for other tools though.

[nielshulstaert]

I've released version 1.3.4 yesterday with the previous CV term. We'll keep this in mind when releasing next versions.

[caetera]

Reopening the case since the changes in CV is planned for the future version

Updated files can be processed by OpenMS (tested on 2.7.0) and ProteoWizard (tested on 3.0.22047).

mzR is lacking support (tested on 2.28.0) @hechth, should open the case?

@martenson can you confirm that Galaxy problems were resolved (I could not figure out what was the problem)

[hechth]

@caetera I'll propagate it upstream and see what needs to be done on mzR.

Regarding the Galaxy issues, they were related to the mzR wrapper in some of the tools, so not exclusively related to Galaxy itself.