robinschmid
commented
10 months ago Exactly we will try to implement most checks in MZmine as well as we are there at a crucial point where RAW data is converted in annotated data. We also have access to isotope MS1 patterns to check. And purity of precursor selection based on MS1.
Downstream python pipeline will definitely still need to check all quality metrics as possible - never know where data comes from.
We will work on two main parts: MZMine (java) Quality control (python)
Let's discuss here how we can best separate what we implement where, to reduce the overlap. Based on our discussion via zoom, I would summarize it as follows, but please correct me, if you have something else in mind.
MZMine focuses on a specific case of library generation, where standards are analyzed in a batch. In a 96 wells plate multiple standards per well are added and MS2 spectra are generated. MZMine is able to match the annotations with the spectra generated per well. (correct me if this is incorrect @robinschmid ) In MZMine the specific quality control for this usecase will be implemented, for instance the check that in most wells multiple compounds could be annotated.
Quality control of library spectra can be applied to a more general use case. This could also be users uploading 10 spectra that they manually annotated, or actual pure standards that were run one by one. The quality control (in python) could do all the general checks. These checks are also useful for MZMine, but would also apply to the more general cases. Checks you can think of are:
There will be some overlap in checks in this way, since MZMine will already have check that smiles and precursor mz + adduct match, but I don't think this should be a big issue.