Difference between revisions of "Team:BostonU HW/Improve"

 
(18 intermediate revisions by 2 users not shown)
Line 18: Line 18:
 
}
 
}
 
#page_background{
 
#page_background{
background-image: url("https://static.igem.org/mediawiki/2017/0/04/MARS_General_Background.png");
+
        background-image: url("https://static.igem.org/mediawiki/2017/9/94/LARGE_background_MARS.png");
}
+
        background-size:100% ;
 +
    }
 
#BACKGROUND{
 
#BACKGROUND{
 
width: 100%;
 
width: 100%;
Line 54: Line 55:
 
<div class="wrapper" id="page_background">
 
<div class="wrapper" id="page_background">
 
<div class="header" id="Header_Pic">
 
<div class="header" id="Header_Pic">
<img src="https://static.igem.org/mediawiki/2017/0/02/MARSbackground.png" id="BACKGROUND">
+
<img src="https://static.igem.org/mediawiki/2017/9/94/LARGE_background_MARS.png" id="BACKGROUND"> <div class="container" margin-top:"2%;">
<img src="https://static.igem.org/mediawiki/2017/2/22/MARSLogo2.png" id="MARS">
+
<div class="col-md-3">
<img src="https://static.igem.org/mediawiki/2017/b/bf/MARS_ImproveNeptune.png" id="TITLE">
+
 
 +
<img src="https://static.igem.org/mediawiki/2017/2/22/MARSLogo2.png" width="100%" style="margin-top:-37%;">
 +
</div>
 +
<div class="col-md-9" style="color:#eef1f5; font-size:80px; font-family:Arial,Gadget,sans-serif; margin-top:1%;">
 +
Improving on Neptune
 
</div>
 
</div>
 +
</div>
 +
</div>
 +
<div class="main main-raised">
 +
<div class="container">
 +
<h2>Improving Upon the 2016 BostonU HW Project: Neptune</h2>
  
<div class="main main-raised" style="margin-top:5%" id="uF_101">
 
<div class="container">
 
<h2>Microfluidics 101</h2>
 
<h3>Introduction to Microfluidics | Dinithi</h3>
 
 
<div class="text">
 
<div class="text">
In order to effectively use the MARS system, users need to have a fundamental understanding of microfluidics. With this in mind, we created an introduction to microfluidics that teaches users the basics of microfluidics. This educational component of project MARS consists of an introduction to microfluidic chips as well as a guide to the various primitives used in our microfluidic designs.
+
During the course of our 2017 iGEM Project, the BostonU HW team worked to improve upon the 2016 BostonU HW Project: <a href="https://2016.igem.org/Team:BostonU_HW">Neptune</a>. Neptune allow uses to specify, design, and control a microfluidic chip. For more information regarding specific elements within Neptune, please refer to their wiki.
</div>
+
</div>
+
  
<div class="container">
+
Our team worked to improve the specify and design portion of the Neptune software workflow. This Neptune can be broken down into five basic blocks:
<h3>Video Tutorials | Sarah and Dinithi</h3>
+
</div><br>
<div class="text" style="margin-bottom:3%;">
+
<div class="row" style="text-align: center">
In order to make the microfluidic chips we designed accessible to synthetic biologists we developed four fully-narrated tutorial videos. These videos go step by step through the process of manufacturing, assembling, and testing a microfluidic device. The four videos created teach uses how to mill a microfluidic chip, how to make PDMS, how to assemble a microfluidic chip, and how to clean a microfluidic chip. Each of these videos is accompanied by a detailed written protocol as well.
+
</div>
+
</div>
+
  
</div>
 
  
<div class="main main-raised" style="margin-top:5%" id ="Chip_Repo">
+
<img src="https://static.igem.org/mediawiki/2017/1/15/Neptune.png">
<div class="container">
+
</div>
<h2>Mars Repository</h2>
+
<div class="text">
<div class="text">
+
<br> The portion of Neptune’s workflow we contributed to was Fluigi. Fluigi is a place-and-route software that receives a detailed microfluidic description in the form of MINT code, and outputs a fully routed chip design with accompanying SVG and JSON files.
In order to make microfluidics a practical field for synthetic biologists, we created the MARS microfluidic chip repository. This repository hosts nine microfluidic chips that each perform a fundamental synthetic biological protocol. These nine protocols were determined after reaching out to synthetic biologists in the Boston University and iGEM communities. Each chip comes with all the required design files and documentation so that a synthetic biologist could download, manufacture, and test any chip in the repository. The nine chips in the MARS repository are as follows:
+
</div>
+
</div>
+
  
<div class="container">
+
During the process of our iGEM project, 17 distinct microfluidic chip designs were coded in MINT and routed using Fluigi. These chips ranged from designs replicated from various journals to original designs for the MARS Repository.
<h3>Cellular Lysis | Dylan</h3>
+
</div>
+
<div class="container">
+
<h3>DNA Digestion | Dinithi</h3>
+
</div>
+
<div class="container">
+
<h3>Cell Sorting | Dinithi</h3>
+
</div>
+
<div class="container">
+
<h3>Ligation | Sarah</h3>
+
</div>
+
<div class="container">
+
<h3>Transformation | Sarah</h3>
+
</div>
+
<div class="container">
+
<h3>PCR | Sarah</h3>
+
</div>
+
<div class="container">
+
<h3>Antibiotic Resistance | Dylan</h3>
+
</div>
+
<div class="container">
+
<h3>Fluorescence Testing | Dinithi</h3>
+
</div>
+
<div class="container">
+
<h3>Cell Culturing | Dylan</h3>
+
</div>
+
  
<div class="container" >
+
While designing and routing these chips we were able to identify issues, limitations, and areas for improvement in the Fluigi and Neptune software system. These issues were identified as elements of Fluigi to fix or improve upon.<b> During the course of our 2017 iGEM project, we altered design rules that would be necessary to integrate into the layout algorithms, some of them in particular are:</b>
<div class="text" style="margin-bottom:3%; margin-top:3%;">
+
</div>
For more information regarding each chip, please see our <a href="https://2017.igem.org/Team:BostonU_HW/Archive">MARS repository page</a>
+
<br>
</div>
+
<ol>
</div>
+
<li><b>Ports are no longer automatically pushed to the edges of a design.</b> When manufacturing a chip using photolithography ports must be at the edges of the chip. However, when using the Makerfluidics workflow this is no longer a requirement; ports can be located anywhere on a chip, within reason. In fact, many designs benefit from or rely on ports being placed in nontraditional locations. Therefore, the pre-existing design rule that ports must be pushed to the edges of a chip needed to be updated. Instead of automatically pushing all ports to the edges of a design, Fluigi can now infer whether or not doing so would be beneficial/required. Thus, the design rule was updated to be more relaxed and accurate for the Makerfluidics workflow.
 +
</li>
 +
<li><b>Primitive locations can be set in the X and/or Y direction. </b>When designing a chip using Fluigi’s place and route system, primitives are defined by the user but the location and connections of these elements of these primitives are determined by Fluigi’s place and route system. However, for some designs the location of primitives must be in specific locations. Fluigi contains a function that allows primitives to be locked in place, the set function, however this function requires both an X and Y coordinate. For some designs, only one of these coordinates is known or required. To accommodate this, Fluigi’s pre-existing “set” design rules was updated to allow the user to set a primitive’s X coordinate, Y coordinate, or both. This updated design rule made the “set” function more practical to use.
 +
</li>
 +
<li><b>Subtle routing changes were added to make designs more practical and functional. </b>Fluigi’s place and route system is effective at connecting primitives with channels, however, it did not always make these connections in the most practical or functional ways. For example, random bends or “kinks” would sometimes be added to channels during the routing process. While a chip with random bends is still a valid design, it may not necessarily be practical as these bends may affect fluid flow. Fluigi’s design rules regarding bend tolerance have been progressively increase over time, thus limiting the amount of unnecessary bends that can be added to a design.
 +
</li>
 +
</ol>
 +
<div class = "text"><br>The impact of these improved design rules can be seen in the two Fluigi-routed chips below. On the left is an output design for eColiBasic5. This chip was designed and routed prior to many of these improvements being implemented. While this chip represents a valid design, it is not optimized or practical due to bends and port location issues. On the right is an output design for eColiBasic6 following the implementation of the previously identified improvements. The MINT code for these two microfluidic chips is nearly identical, but the outputs are entirely different. eColiBasic6 is a cleaner, more practical and functional design that can be manufactured and tested.</div>
 +
<br>
  
</div>
+
<div class="row">
 +
  <div class="col-md-6">
 +
  <div style="text-align: center">
 +
      <img src="https://static.igem.org/mediawiki/2017/e/e9/Ebas5.png" height = "350 px">
 +
      <br/>
 +
    <b> <h4>eColiBasic5</h4></b><h5>This chip was designed and routed in an earlier version of Fluigi in which the design rules had not been updated. <br>This output is not ideal as it has many unnecessary bends make the design impractical for real life usage. Fluigi's design rule limitations also made it so that elements of the final design could not be included, such as properly connected ports in the middle of the device.</h5>
  
<div class="main main-raised" style="margin-top:5%; margin-bottom:3%;" id="FF">
+
  </div>
<div class="container">
+
</div>
<h2>Fluid Functionality</h2>
+
<div class="col-md-6">
<div class="text">
+
    <div style="text-align: center">
In order to verify whether or not a microfluidic device is functional, a grading system was developed: the Fluid Functionality Checklist. This fluid functionality system was broken up into two portions: a qualitative checklist and a quantitative analysis.
+
        <img src="https://static.igem.org/mediawiki/2017/e/e9/Ebas6.png" height= "350 px">
</div>
+
        <br />
</div>
+
        <b> <h4>eColiBasic6</h4></b><h5>This chip was designed and routed in an improved version of Fluigi in which the updated design rules had been implemented.<br>This output is much cleaner, having significantly less unnecessary kinks and bends, and includes portions of the chip design not previously possible; for example, two ports were placed and routed in locations not previously possible in earlier iterations due to ports being pushed to the edge.</h5>
 +
    </div>
 +
<br>
 +
<br>
  
<div class="container">
+
</div>
<h3>Qualitative Checklist | Dylan, Sarah, and Dinithi</h3>
+
<div class = "text">
<div class="text">
+
<br>
The qualitative portion of the fluid functionality checklist consists of various failure modes. These are visual cues that something has gone wrong while running a chip, such as liquid leaking out of a channel or primitive. If a chip passes each of these qualitative checks, it is deemed “fluid functional.” If a chip does not pass each of these qualitative checks, the user moves to the quantitative analysis to determine why the chip failed.
+
<br>
</div>
+
Besides these software improvements and updates, our 2017 work with Fluigi and Neptune brought other issues and suggestions to light as well. Many of these will be implemented in future iterations of Fluigi. A short list of these can be seen below.
</div>
+
<br>
 +
<b><br>
 +
Issues</b>
 +
</div>
 +
<ol>
 +
<li>Bend penalties are not clearly characterized
 +
</li>
 +
<li>Random “kinks” will be added to straight channel connections
 +
</li>
 +
<li>Channels will overlap when they are not supposed to
 +
</li>
 +
<li>Primitives will overlap when they are not supposed to
 +
</li>
 +
<li>Nesting trees within each other leads to spacing issues
 +
</li>
 +
</ol>
 +
<div class ="text">
 +
<b><br>
 +
Suggestions</b>
 +
</div>
 +
<ol>
 +
<li>Requiring all primitive dimensions to be evenly divisible by lambda (scaling value) so that scaling back up after routing retains exact primitive dimensions
 +
</li>
 +
<li>Adding the ability to reflect modules horizontally and/or vertically
 +
</li>
 +
</ol>
 +
<div class = "text" style="margin-bottom:30px;">
 +
<br>
 +
Through our work on Fluigi, the 2017 BostonU HW team improved upon both Fluigi and Neptune. We identified issues and limitations associated the Fluigi place and route tool, an  integral portion of the Neptune software workflow. By helping to improve Fluigi, we have also built upon  the 2016 BostonU HW project Neptune.<br>
  
<div class="container">
+
</div>
<h3>Quantitative Analysis | Dylan and Sarah</h3>
+
<div class="text" style="margin-bottom:3%;">
+
The quantitative portion of the fluid functionality checklist consists of various quantitative analyses. Two forms of analysis are included in this portion of our evaluation system: physics-based primitive analysis and image processing-based analysis. Physics based analysis helps to determine if a qualitative failure occurred because the incorrect primitive dimensions and/or flow rate were used. Image processing analysis is used to evaluate the functionality of primitives such as mixers. Using these analyses, a user can both determine why their chip failed and evaluate the functionality of key primitives.
+
</div>
+
 
</div>
 
</div>
 +
 +
  
 
</div>
 
</div>
 +
 +
 
   </div>
 
   </div>
 +
 +
</div>
 +
 +
<!-- THIS IS FOOTER -->
 +
<div class="wrapper" style="background:#1c1f1f; margin-top:0px;margin-right:0px !important; margin-left:0px !important;" id="Footer">
 +
  <div class="container" style="text-align:center !important">
 +
 +
    <div class="col-md-2" style="color:white; margin-bottom:30px; margin-top:5px;">
 +
      <h3>CONTACT US</h3>
 +
    <div style="text-align:center;">
 +
      <a href="mailto:igembuhw@gmail.com">
 +
      <img src="https://static.igem.org/mediawiki/2017/7/74/MARS_WHITEEmail.png" style="height:60px; margin-top:20px;">
 +
      </a>
 +
        <a href="https://www.instagram.com/buigemhardware/?hl=en">
 +
        <img src="https://static.igem.org/mediawiki/2017/9/93/MARS_Final_insta.png" style="height:60px; margin-top:20px;">
 +
      </a>
 +
          <a href="https://twitter.com/igemhwbu">
 +
          <img src="https://static.igem.org/mediawiki/2017/b/b6/MARS_Twitter_White.png" style="height:60px; margin-top:20px;">
 +
          </a>
 +
      </div>
 +
      </div>
 +
      <div class="col-md-10" style="margin-bottom:30px;">
 +
        <img src="https://static.igem.org/mediawiki/2017/0/0e/MARS_SponsorsFinal.png" style="width:100%; margin-top:30px;" usemap="#image-map">
 +
    </div>
 +
</div>
 +
 +
</div>
 +
  
 
</div>
 
</div>

Latest revision as of 16:08, 30 November 2017

BostonU_HW

Improve
Improving on Neptune

Improving Upon the 2016 BostonU HW Project: Neptune

During the course of our 2017 iGEM Project, the BostonU HW team worked to improve upon the 2016 BostonU HW Project: Neptune. Neptune allow uses to specify, design, and control a microfluidic chip. For more information regarding specific elements within Neptune, please refer to their wiki. Our team worked to improve the specify and design portion of the Neptune software workflow. This Neptune can be broken down into five basic blocks:


The portion of Neptune’s workflow we contributed to was Fluigi. Fluigi is a place-and-route software that receives a detailed microfluidic description in the form of MINT code, and outputs a fully routed chip design with accompanying SVG and JSON files. During the process of our iGEM project, 17 distinct microfluidic chip designs were coded in MINT and routed using Fluigi. These chips ranged from designs replicated from various journals to original designs for the MARS Repository. While designing and routing these chips we were able to identify issues, limitations, and areas for improvement in the Fluigi and Neptune software system. These issues were identified as elements of Fluigi to fix or improve upon. During the course of our 2017 iGEM project, we altered design rules that would be necessary to integrate into the layout algorithms, some of them in particular are:

  1. Ports are no longer automatically pushed to the edges of a design. When manufacturing a chip using photolithography ports must be at the edges of the chip. However, when using the Makerfluidics workflow this is no longer a requirement; ports can be located anywhere on a chip, within reason. In fact, many designs benefit from or rely on ports being placed in nontraditional locations. Therefore, the pre-existing design rule that ports must be pushed to the edges of a chip needed to be updated. Instead of automatically pushing all ports to the edges of a design, Fluigi can now infer whether or not doing so would be beneficial/required. Thus, the design rule was updated to be more relaxed and accurate for the Makerfluidics workflow.
  2. Primitive locations can be set in the X and/or Y direction. When designing a chip using Fluigi’s place and route system, primitives are defined by the user but the location and connections of these elements of these primitives are determined by Fluigi’s place and route system. However, for some designs the location of primitives must be in specific locations. Fluigi contains a function that allows primitives to be locked in place, the set function, however this function requires both an X and Y coordinate. For some designs, only one of these coordinates is known or required. To accommodate this, Fluigi’s pre-existing “set” design rules was updated to allow the user to set a primitive’s X coordinate, Y coordinate, or both. This updated design rule made the “set” function more practical to use.
  3. Subtle routing changes were added to make designs more practical and functional. Fluigi’s place and route system is effective at connecting primitives with channels, however, it did not always make these connections in the most practical or functional ways. For example, random bends or “kinks” would sometimes be added to channels during the routing process. While a chip with random bends is still a valid design, it may not necessarily be practical as these bends may affect fluid flow. Fluigi’s design rules regarding bend tolerance have been progressively increase over time, thus limiting the amount of unnecessary bends that can be added to a design.

The impact of these improved design rules can be seen in the two Fluigi-routed chips below. On the left is an output design for eColiBasic5. This chip was designed and routed prior to many of these improvements being implemented. While this chip represents a valid design, it is not optimized or practical due to bends and port location issues. On the right is an output design for eColiBasic6 following the implementation of the previously identified improvements. The MINT code for these two microfluidic chips is nearly identical, but the outputs are entirely different. eColiBasic6 is a cleaner, more practical and functional design that can be manufactured and tested.


eColiBasic5

This chip was designed and routed in an earlier version of Fluigi in which the design rules had not been updated.
This output is not ideal as it has many unnecessary bends make the design impractical for real life usage. Fluigi's design rule limitations also made it so that elements of the final design could not be included, such as properly connected ports in the middle of the device.

eColiBasic6

This chip was designed and routed in an improved version of Fluigi in which the updated design rules had been implemented.
This output is much cleaner, having significantly less unnecessary kinks and bends, and includes portions of the chip design not previously possible; for example, two ports were placed and routed in locations not previously possible in earlier iterations due to ports being pushed to the edge.




Besides these software improvements and updates, our 2017 work with Fluigi and Neptune brought other issues and suggestions to light as well. Many of these will be implemented in future iterations of Fluigi. A short list of these can be seen below.

Issues
  1. Bend penalties are not clearly characterized
  2. Random “kinks” will be added to straight channel connections
  3. Channels will overlap when they are not supposed to
  4. Primitives will overlap when they are not supposed to
  5. Nesting trees within each other leads to spacing issues

Suggestions
  1. Requiring all primitive dimensions to be evenly divisible by lambda (scaling value) so that scaling back up after routing retains exact primitive dimensions
  2. Adding the ability to reflect modules horizontally and/or vertically

Through our work on Fluigi, the 2017 BostonU HW team improved upon both Fluigi and Neptune. We identified issues and limitations associated the Fluigi place and route tool, an integral portion of the Neptune software workflow. By helping to improve Fluigi, we have also built upon the 2016 BostonU HW project Neptune.