`RawDataProcessor` methods for spectra alignment and annotation

[dmccloskey]

Description

As a user, I would like to be able to align and annotate semi-targeted and non-targeted metabolomics data spectra

Objectives

• [ ] Implement a RawDataProcessor method that wraps the OpenMS calls to MSPGenericFile.h to load a MSP file
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::extractSpectra
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::annotateSpectra
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::pickSpectrum
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::scoreSpectra
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::selectSpectra
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::untargetedMatching
• [ ] Implement a RawDataProcessor method that wraps the OpenMS call for TargetedSpectraExtractor::targetedMatching
• [ ] Unit tests for all RawDataProcessor Methods
• [ ] Example for targeted spectral extraction
• [ ] Example for untargeted spectral extraction

Validation

• [ ] Passing unit tests
• [ ] Passing examples
• [ ] Working linux/win build

[pcolaianni]

I have spent several hours between yesterday and today with #232 . Lot of reading in OpenMS source code to understand what goes on. If that issue (#232) and this one (#233) are very heavy domain-knowledge focused and you suspect deadlines are too close, do you think it would be better that you take care of these two issues and I take care of those that deal with CI, GUI, multi-threading, etc? Meaning those that do not require mass spec knowledge.

[dmccloskey]

These issues should require minimal mass spec knowledge, but mostly just knowledge of what the underlying code is doing on the data. The majority of this code has written by both you and I so I am a bit surprised. But anyway, the mass spec knowledge will come into play for tweaking the algorithms which I will be doing the majority of once they are accessible form SmartPeak.

In regards to deadlines, there is a lot of writing that is also involved, so if you are able to take care of these issues, that would be great.

In regards to the order, CI (is AppVeyor currently usable or not?), GUI items in the sprint backlog (including working GUI on windows), and multi-threading items in the sprint backlog should be taken care of before moving onto issues #232 and #233.

[pcolaianni]

For many classes I simply converted the code from Python to C++ as close as possible. Not necessarily understanding what the code does or why. The relationship between the classes (what a ChromatogramMap is to a Featuremap, or similar cases) is not obvious to me.

Alright, let's see how things go.

On the CI:

• AppVeyor is usable only to see if code builds or does not build. I had issues with running part of the executables, or facing time limits.
• Jenkins can build and test the library. One of the examples seems to take forever (LCMS_MRM_Standards, if I am not mistaken). AIT is enabling access to the machine from github.com so that we should be able to trigger builds when we commit. Progress with Jenkins is here: https://github.com/dmccloskey/SmartPeak2/pull/239

Taking care of Jenkins forced me to learn a few things that I could try applying to AppVeyor too and see if things get solved.