eVOLVER measures optical density with good precision and at frequent intervals. Peter has build a block of code, mufit, to do a global exponential growth rate fit outputting growth rate and confidence intervals. However, the code needs manual input of certain noise approximating variables, is kinda slow in Matlab, can only process one vial’s growth rate at a time, and now needs preprocessing of the OD text files as they changed format. I was thinking about implementing it in Python so that
it can take in the current file format
does not need manual noise parameters (better data nowadays than a couple of years back)
it can process all 16 vials without manual intervention.
After talking to Chris, it seemed like if it has good runtime, we could think about interfacing it with the website for realtime growth rate.
Would it be useful to have the mufit growth rate fitting algorithm available with these properties to process the OD traces?
Thats a good idea to have an updated version of mufit, along with other growth rate measurement programs. Let me put more thought into what the best way to implement is. From what I can remember, it was helpful that mufit plotted the data and the fitted growth rate line onto the same graph so you can make some adjustments to the parameters. So an ideal solution might be a Python backend to interact with the data and having a NodeJS GUI (similar to what we’ve been making with the eVOLVER touchscreen) to run the script and adjust certain constants.
Sorry for the super late response, been letting this simmer. @bgwong I kind of feel like the algorithm should be written in python as part of the dpu with the goal of having it able to run in real time or when a user triggers it through the GUI. If it runs slowly, we can put it on a separate process, allow it to run, finish up, then graph/save those results. Alternatively, it could be it’s own script that the GUI kicks off upon user request or over a time interval. Either way, the code should be written as a module in it’s own file so that it can be flexible enough for both solutions or any other use cases we haven’t thought of yet.
Being able to tweak the parameters in real time is also possible with some of the new changes I made in the dpu for electron - it is possible to send the python script arbitrary messages that can be parsed to change any parameters the algorithm needs. Running the script on the side as it’s own thing isn’t a bad idea either, but my thinking right now is that the GUI at least should be integrated into the single electron app and not be a separate NodeJS project. If it’s in the same electron app it could interact with any running experiments if we wanted it to.
Thanks for the response. I totally agree. So @kiriakov, back to your original question, I think its probably best to write in Python, with mufit taking command line arguments. For example, it would look something like this:
python3.6 mufit.py -d <path-to-file> -r <range of data> -c <constants>
We can then use this for 1) calling it like a normal Python Function or 2) Call it from the NodeJS GUI (with Python Shell Executing the script).
Oh one thing to note. We are currently using Python 3.6 in our DPU cause our websockets library requires that version of Python. Would make things a lot easier if everything was run off the same version. I added a post to help add the correct version of Python. Generally, it all should work with later versions but might be better off this way.
I am excited about this for many reasons.