Mph norm workflow

[ngreenwald]

If you haven't already, please read through our contributing guidelines before opening your PR

What is the purpose of this PR?

1. Adds functionality to the set_up_toffy notebook which allows the user to construct a tuning curve for their instrument. This takes in a detector sweep, and produces a tuning curve relating MPH to signal intensity
2. Creates the 4b_normalize_image_data notebook which walks the user through the normalization process. This assumes the user has already constructed a tuning curve, and will allow them to easily normalize their data
3. Switches the logic for normalization. Previously, we tried to fit a relationship between mass and MPH within an FOV, which would then allow us to use a small number of MPH values from selected masses to normalize. However, this created more problems than it solved. Instead, we now compute the MPH for every mass in the panel. This is more compute intensive, but it is quite fast and won't be a major bottleneck. We then fit a separate curve for each mass over the course of the run, modeling how the MPH is changing for that mass as a function of run length. This results in very smooth estimates of MPH for each marker in the panel. We then use those adjusted mass-specific MPH values to normalize the data.
4. Adds plotting and QC outputs to allow the user to visualize the curve fit, as well as get notified for any normalization values which are outside a proscribed range
5. Updates the 4a_rosetta notebook to have the same default paths as the rest of the notebooks. Also removes the nested for loop structure in favor of processing a single run, simplifying the code

Closes #37

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[ackagel]

Looks good so far. It looks like a lot of my review comments in review-nb are in the works in normalize.py

[ackagel]

Can't the sensitivity curve generation go in 4b, since it's only used there? Is the idea that putting this here will encourage people to run a sweep before data aq?

Reply via ReviewNB

[ngreenwald]

No, it's because it only needs to happen once per instrument, not separately for each run. So having it here means it won't be present in the notebook each time people are normalizing

[ackagel]

Can't this be done programmatically here?

Reply via ReviewNB

[ngreenwald]

Sweeps aren't created in their own folder, they're just put into the main /Data folder. So you need to separately identify each FOV from the sweep, which are given the generic names. This was initially what that find_detector_sweeps function was for, but then Erin had a couple sweeps where FOVs were missing, so it gave an error.

We could change it so that it would give a warning when an FOV is missing, rather than an error, and then ask people to list the first FOV and last FOV of their sweep and it would find the rest, but at that point it started to feel like the solution was almost as complicated as the problem. Up to you though, it would be an easy change

[alex-l-kong]

A few aesthetic comments mostly in the notebook.