A key plank in the Astropharmacy is drug expression within a microfluidic device: substrates would mix inside a long and thin channel housed in a PDMS chip, with crude drugs being produced within the channel. The design of these chips is a laborious process and is based on a number of variables. Thus, the job of our model (as with any other) is to automate a process that is both painstaking and mundane: to generate an expression chip design given several key inputs.

III: Materials and Methods

The first question was choosing the best coding language in which to construct our model. The most common language used in modeling is Python; however, while powerful, Python lacks an intuitive UX, which we valued given the broader uses for our model (expanded upon in the “Results” section of this page). The language we chose for our model was Swift, the iPhone coding language developed by Apple. Swift was an ideal choice because it gave us the best of both worlds: robust processing power and an easy-to-use user interface.

The second question: what will the model do? As discussed above, we wanted a piece of software that could find utility in labs beyond our own. The microfluidics aspect of the Astropharmacy seemed like a good candidate given the number of other labs studying microfluidics. We decided that a model of ours should be more than a mere calculator: it would actually show a device design based on user inputs. We spent considerable time examining the data gathered physically designing microfluidic expression chips in order to determine key assumptions and equations for calculation purposes.

The final question: how can the goals of the model be accomplished? Most of the time spent devising the model was spent answering this question. The initial stage—the slider view where users toggle inputs—might seem rather simple from a user perspective, but the coding work it entailed was anything but. First were the UX elements—inserting sliders to toggle input values; the button taking users to the Astropharmacy wiki without leaving the application; the reset button to set slider values to zero; the alert preventing users from initiating a calculation in the presence of a zero-valued slider; the disappearance of the astronaut image and its replacement with a prompt to view the device generated. Second were the calculation elements, mostly involving the passage of data: passing values from the sliders to the slider functions in the code base, then converting those values to “global values” that could be manipulated outside of the function; preventing users from moving to the device stage without values capable of generating a device (accomplished by hiding the “View My Device!” button until all slider values were nonzero); and passing the values from the slider stage to the device view stage (which allowed the device generation calculations to be performed on the device view screen).

The device view screen was the most complicated to construct. The calculation elements—the “Device Specifications” shown at the bottom of the screen—involved the manipulation of variables imported from the slider view. The device generation involved populating the device view stage with various design elements and displaying completed designs based on user-entered constraints.

IV: Results

The model is a useful software tool with utility for anyone designing a microfluidic expression chip (note that none of the input variables are specific to the Astropharmacy). The channel length calculations were informed by laboratory data and, furthermore, were accurate to laboratory data when run independently.

V: Discussion

Before our model, there had been no published software tool to design a microfluidic chip based on user inputs. Our model was extensively tested, debugged, and corroborated with laboratory data. Overall, the ability to design microfluidic expression chips is useful for anyone attempting to use microfluidic devices for protein expression.

A video demonstration of our model follows, along with a zip file of the code base.

Astropharm App Final.xcodeproj.zip

Our team spent a lot of time designing the expression chip in which our proteins would be synthesized. These designs are complex, and incredibly time-consuming to do by hand. Our model sought to automate away this massive workload and free up time and resources in the lab. The values that users can toggle are based upon equations given to us by the Fordyce Lab at Stanford for calculating flow rate; the model's outputs were corroborated with laboratory data (we used lab data to sanity-test the model, and we used our model in the design of subsequent iterations of our expression chips). This profound interaction between wet lab and model makes our team an excellent candidate for the "Best Model" prize.

Team:BrownStanfordPrinctn/Model

Modeling