search

McDermott-Group / servers

Public repo that stores LabRAD servers and other non-measurement related code
0 stars 2 forks source link

[Grapher] Add ability for plugins #62

Open roboguy222 opened 8 years ago

roboguy222 commented 8 years ago

The way we decided to do this was the following. Basically the grapher follows the following format:

data = getDataFromChest()
doStuffTo(data)
plot(data)

This doStuffTo(data) function can be user defined in a file. These plugins can be selected on the left side or something. As an example, a user might take an averaged vertical cut of a 2D plot and subtract it from everything else, such that a small signal can be detected amongst background. Maybe the plugin browser should just be another file browser from which the user can select a file, or maybe we put them all in a folder and it just lists them from there. Maybe some combination? We could potentially have a user select multiple plugins, but then we have to deal with implementing dragging around the ordering of them, etc.

amopremcak commented 8 years ago

I think we need to define what exactly it is we want plugins to do. As of now, the grapher offers a "File Browser", an "Available Plot Types" options list with a few different ways for plotting 1D and 2D datasets, and a space for the actual graph. These "Available Plot Types" allow users to display datasets in different ways than the default plot type. These were cooked up by @patzinak and myself to allow users to plot things like trajectories (dep1(indep) vs dep2(indep)), 3D figures for 2D datasets and stuff like that. Originally, we roped histograms into "Available Plot Types", but this modifies dataset producing a new one which varies with the number of bins. Similarly, FFTs take a time series (t, V) and produce a new dataset (f, V^2/Hz). It seems that histograms and FFTs belong with the plugins, as they perform operations on a dataset.

Plugins, as @roboguy222 described above, sound like post-processing operations, such as back-ground subtraction, smoothing, ... , that take a dataset in and return a new dataset (with the same shape or possibly a new one), but that has been altered in some way by an operation (possibly involving multiple files). I really like the idea of these plugins, but a little bit of planning now will save us a whole lot of time down the road. These plugins will in general require user inputs and therefore must be integrated into the grapher (e.g. number of bins for a histogram). It seems that we ought to keep these separate from fitting operations, as we may want to apply fits after an operation is performed (for example a 1D line slice of a 2D plot followed by a fit of this 1D curve to a Lorentzian).

What are your thoughts on this @roboguy222 and @patzinak?

@patzinak, how easy would it be to modify your measurement code to write to the dataChest when it writes to .txt and matlab files at the end of the program? I would like to do this so that we can test the grapher against the matlab code you have already written as we develop on the grapher.

roboguy222 commented 8 years ago

I think incorporating the FFT and histograms into the plugins may make a lot of sense, yeah.

If, in the best case scenario, we have the ability to add multiple plugins and drag their order around, the fit still works pretty well as a plugin I think. Including them as a plugin strikes me as the most versatile way to do this.

@patzinak said it was actually pretty hard to write the dataChest into the saving stuff, but that he would start working on it. Not sure if he has yet or not.

patzinak commented 8 years ago

Saving at the end of the measurement should be doable. I can try to implement it, so you guys can slowly bring-up the viewing/post-processing environment, maybe eventually a replacement to my MATLAB scripts. I won't implement the incremental saving, this would be too much work for me at this moment.