Easing parameter selection for FFM

[jpfeuffer]

Optimizing parameters for FFM is a huge pain. What can we do to ease this?
Especially the noise and FWHM parameters have such a huge impact on both quality and runtime such that it is almost impossible to figure out good parameters without looking at the data for a long time.
Especially @oliveralka @FabianAicheler @timosachsenberg

[jpfeuffer]

It is not even clear what chrom_fwhm means. What is "expected"? The average as in expected value? How does it influence the trace finding exactly?
Especially since there is a min and max_trace_length param also.

[tjeerdijk]

Hi Julianus, For a complicated optimisation problem like this (parameter optimisation for FFM) we could try a Gaussian Process - Active Learning approach as detailed in this book: https://bobby.gramacy.com/surrogates/. Maybe we can write out a Master Thesis Project for the machine learners? Take care from Tjeerd

…

On 24. Jun 2021, at 12:57, Julianus Pfeuffer ***@***.***> wrote: Optimizing parameters for FFM is a huge pain. What can we do to ease this? Especially the noise and FWHM parameters have such a huge impact on both quality and runtime such that it is almost impossible to figure out good parameters without looking at the data for a long time. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGKDZEB7PKMIC72Q6OCUTE3TUMFQTANCNFSM47HUPS7Q>.

[timosachsenberg]

Multiplex or Metabo?

[jpfeuffer]

Metabo. Which is also very very slow. I am currently working on an indexing structure for mz ranges.

[jpfeuffer]

I profiled and findNearest takes over 50% of the runtime.

[timosachsenberg]

We already have kD tree but I guess you know that one. In my experience FFMetabo was mainly slow if accidentally profile data was provided or if the trace is always stopped after collecting few peaks resulting in many noise related peaks. Are you using a release build?

[jpfeuffer]

I double-checked with @oliveralka.
The data looks fine and is centroided. There are just too many peaks on a 2h gradient for this type of lookup.

We actually only need indexing in mz range, so kdtree was overkill. For RT only neighboring scans are used.
But it did not make any difference, although the range to search decreased significantly. I think there are just millions of apexes that it wants to search. It takes hours.