Automatic volume management for programmable microfluidics

  • Authors:
  • Ahmed M. Amin;Mithuna Thottethodi;T. N. Vijaykumar;Steven Wereley;Stephen C. Jacobson

  • Affiliations:
  • Purdue University, W. Lafayette, IN, USA;Purdue University, W. Lafayette, IN, USA;Purdue University, W. Lafayette, IN, USA;Purdue University, W. Lafayette, IN, USA;Indiana University, Bloomington, IN, USA

  • Venue:
  • Proceedings of the 2008 ACM SIGPLAN conference on Programming language design and implementation
  • Year:
  • 2008

Quantified Score

Hi-index 0.00

Visualization

Abstract

Microfluidics has enabled lab-on-a-chip technology to miniaturize and integrate biological and chemical analyses to a single chip comprising channels, valves, mixers, heaters, separators, and sensors. Recent papers have proposed programmable labs-on-a-chip as an alternative to traditional application-specific chips to reduce design effort, time, and cost. While these previous papers provide the basic support for programmability, this paper identifies and addresses a practical issue, namely, fluid volume management. Volume management addresses the problem that the use of a fluid depletes it and unless the given volume of a fluid is distributed carefully among all its uses, execution may run out of the fluid before all its uses are complete. Additionally, fluid volumes should not overflow (i.e., exceed hardware capacity) or underflow (i.e., fall below hardware resolution). We show that the problem can be formulated as a linear programming problem (LP). Because LP's complexity and slow execution times in practice may be a concern, we propose another approach, called DAGSolve, which over-constrains the problem to achieve linear complexity while maintaining good solution quality. We also propose two optimizations, called cascading and static replication, to handle cases involving extreme mix ratios and numerous fluid uses which may defeat both LP and DAGSolve. Using some real-world assays, we show that our techniques produce good solutions while being faster than LP.