simulation and visualization of a 3d … and visualization of a 3d biological environment. dna and...

SIMULATION AND VISUALIZATION OF A 3DBIOLOGICAL ENVIRONMENT. DNA AND

RESTRICTION ENZYME CASE STUDY

October 2014Mirco Pazzaglia

Master of Science in Computer Science

SIMULATION AND VISUALIZATION OF A 3DBIOLOGICAL ENVIRONMENT. DNA AND

RESTRICTION ENZYME CASE STUDY

Mirco PazzagliaMaster of ScienceComputer ScienceOctober 2014School of Computer ScienceReykjavík UniversityUniversity of Camerino

M.Sc. RESEARCH THESISISSN 1670-8539

Simulation and Visualization of a 3D BiologicalEnvironment. DNA and Restriction Enzyme Case Study

by

Mirco Pazzaglia

Research thesis submitted to the School of Computer Scienceat Reykjavík University and at University of Camerino in partial fulfillment of

the requirements for the degree ofMaster of Science in Computer Science from Reykjavík University andMaster of Science in Computer Science from University of Camerino

October 2014

Research Thesis Committee:

Anna Ingolfsdóttir, SupervisorProfessor, Reykjavík University

Luca Tesei, SupervisorAssistant Professor, University of Camerino

Leonardo MostardaAssociate Professor, University of Camerino

Luca AcetoProfessor, Reykjavík University

CopyrightMirco Pazzaglia

October 2014

Simulation and Visualization of a 3D Biological Environment.DNA and Restriction Enzyme Case Study

Mirco Pazzaglia

October 2014

Abstract

We address the problem of time discrepancies between wet-lab and soft-ware simulated DNA-Restriction Enzyme molecules interactions. In previ-ous works, simulation results were lower of three orders of magnitude fromwet-lab experiments. It has been found, investigating the causes of such ananomaly, that the simulation tools were making a simplistic assumption bytreating the biological molecules as point particles. We developed a newsoftware package that consists of a simulation tool and a 3D viewer. Thesimulation software was developed by taking into account the shape of thebiological molecules, thus treating them as rigid bodies instead of point par-ticles. The 3D viewer is used for rendering previously computed simulations.This tool allows the user to move in the scene both in simulation space andtime. We did several tests that qualitatively support the hypothesis that thetime discrepancies may, in effect, depend on the physical representation ofthe biological entities. When those are treated as rigid bodies, as opposedto point particles, the results are the same order of magnitude as those fromwet-lab experiments.

To the Cosmos. . .

vii

Acknowledgements

I would like to express my deepest gratitude to everyone who was and has been part of

my life so far.

I want to thank my family that supported and helped me all along the way. Also, I couldnot make it without my friends who have always played an important role for me.Special thanks go to Noemi and Anastasia who have always made me confident, helpedme struggle to make it and never stopped to put up with me during this time of my life.I want to thank both the Reykjavík University and the University of Camerino for givingme the opportunity of the Double Degree program, such an extraordinary, yet painful attimes, experience.I also want to thank both the Erasmus program and the ERSU-Camerino that helped mefacing the expenses for living in Iceland and to continue with my studies.Last, but not the least, I want to thank:

- Me,- Myself,- and I.

Because, after all, I deserve credit too for reaching my goals.

ix

Contents

List of Figures xi

List of Tables xiii

1 Introduction 1

2 Biological Background 52.1 Deoxyribonucleic Acid Molecule . . . . . . . . . . . . . . . . . . . . . . 52.2 Restriction Enzyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Problem Analysis: Stereospecific Reaction . . . . . . . . . . . . . . . . . 82.4 The Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Brownian Motion . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Long-Range Interaction . . . . . . . . . . . . . . . . . . . . . . 10

3 Requirements and Specifications 113.1 Dictionary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . 15

3.3 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Project Design 194.1 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Project Technologies 255.1 Physics Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1.1 Bullet Physics Engine . . . . . . . . . . . . . . . . . . . . . . . 265.2 Graphics Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

x

5.2.1 Unity 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Project Implementation 316.1 Software Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 Development Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.3 Generating Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.4 Part 1 - Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.5 Part 2 - Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5.1 Main Menu GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 456.6 Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.7 Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . 48

7 Applications and Results 497.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2 Tests and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2.1 Test #1: One DNA molecule, One Endonuclease . . . . . . . . . 557.2.2 Test #2: One DNA molecule, Two Endonucleases . . . . . . . . . 567.2.3 Test #3: Two DNA molecules, One Endonucleases . . . . . . . . 577.2.4 Test #4: Two DNA molecules, Two Endonucleases . . . . . . . . 597.2.5 Test #5: Advanced Tests . . . . . . . . . . . . . . . . . . . . . . 607.2.6 Overall Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Conclusions 658.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8.1.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.1.2 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.1.3 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

References 71

A Unity Free vs Unity Pro 75

B Simulation Log Structure 77B.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77B.2 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.3 Frame Seek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

xi

List of Figures

2.1 The structure of the DNA molecule . . . . . . . . . . . . . . . . . . . . . 62.2 Restriction Enzymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 EcoRI restriction of a DNA molecule . . . . . . . . . . . . . . . . . . . . 72.4 DNA-Restriction Enzyme interaction . . . . . . . . . . . . . . . . . . . . 8

3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Simulation - Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 204.2 3D Viewer - Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 224.3 Simulation - Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 234.4 Project Suite Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Bullet Physics - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2 Unity - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3 Unity Engine - Asset Store . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Unity - IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 Software Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 Blender - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.3 DNA 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4 Restriction Enzyme 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . 346.5 Bounding Cube 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . 356.6 Bullet Modules - Dependency Graph . . . . . . . . . . . . . . . . . . . . 376.7 Bullet Modules - Visual Studio Project . . . . . . . . . . . . . . . . . . . 376.8 Biological Entity - Class Diagram . . . . . . . . . . . . . . . . . . . . . 386.9 Frame rate Duality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.10 Unity Engine - Scenes in the project . . . . . . . . . . . . . . . . . . . . 436.11 Unity Engine - Objects and Components . . . . . . . . . . . . . . . . . . 436.12 Unity Engine - Scene Editor . . . . . . . . . . . . . . . . . . . . . . . . 446.13 Unity Engine - Public Attribute Editor . . . . . . . . . . . . . . . . . . . 45

xii

6.14 Unity Engine - Build Menu . . . . . . . . . . . . . . . . . . . . . . . . . 476.15 Unity Engine - Build Directory . . . . . . . . . . . . . . . . . . . . . . . 48

7.1 BioLab Screenshot 1 - Main Menu . . . . . . . . . . . . . . . . . . . . . 497.2 BioLab Screenshot 2 - Simulator . . . . . . . . . . . . . . . . . . . . . . 507.3 BioLab Screenshot 3 - Load Simulation Log File Dialog . . . . . . . . . 517.4 BioLab Screenshot 4 - 3D Viewer . . . . . . . . . . . . . . . . . . . . . 517.5 BioLab Screenshot 5 - Time Controller . . . . . . . . . . . . . . . . . . . 527.6 BioLab Screenshot 6 - Info and Options . . . . . . . . . . . . . . . . . . 527.7 BioLab Screenshot 7 - Bounding Cube . . . . . . . . . . . . . . . . . . . 537.8 BioLab Screenshot 8 - Show Vectors Enabled . . . . . . . . . . . . . . . 537.9 One endonuclease, one DNA molecule . . . . . . . . . . . . . . . . . . . 557.10 Two endonucleases, one DNA molecule . . . . . . . . . . . . . . . . . . 567.11 One endonuclease, two DNA molecule . . . . . . . . . . . . . . . . . . . 587.12 Two endonucleases, two DNA molecules . . . . . . . . . . . . . . . . . . 597.13 20 endonucleases, 10 DNA molecules . . . . . . . . . . . . . . . . . . . 61

xiii

List of Tables

3.1 Dictionary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 163.4 Use Case - Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Use Case - View Simulation . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1 BioLab executable parameters . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 3D Viewer Key Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 547.3 Test #1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5 Test #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.7 Test #3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.9 Test #4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.11 Test #5: Real case scenario . . . . . . . . . . . . . . . . . . . . . . . . . 617.12 Test #5: Stress-test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.13 Test recap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.14 3D viewer performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.1 Unity Free vs Unity Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.1 Log File Structure - Header . . . . . . . . . . . . . . . . . . . . . . . . . 77B.2 Log File Structure - Payload . . . . . . . . . . . . . . . . . . . . . . . . 78

1

Chapter 1

Introduction

The BioLab project consists in a computer software package aimed at biophysicists whoare creating models for DNA-Restriction Enzyme reactions in order to simulate them andcompare the results with the wet-lab observations. There are still open questions in theliterature regarding the interaction between nucleic acids and proteins such as how theymanage to find the reaction sites so efficiently; the DNA-Restriction Enzyme case studygives the researchers a chance to shed light on those poorly investigated mechanism.Even though some work has already been done on this topic (Pierre et al., 2013), (Buti,Cacciagrano, Corradini, Merelli, & Tesei, 2010), we started working on the BioLabproject because of the lack of simulation software specifically aimed at biophysicists intheir investigation of the laws that govern reactions, motion and other physical propertiesof the microscopic universe where DNA and enzyme molecules can be observed, that is,the intracellular environment.In particular, we became interested in the work done in those fields by the CIML1 researchcenter at the University of Marseille (Preto, 2012). They have been studying the reactionsbetween DNA molecules and restriction enzymes. Trying to create a model for thosetype of interactions, they also developed a simulation software for testing the models asthey were created. What they found, regarding the reaction time of the biological entities,was that the simulated experiments were a lot faster, by three orders of magnitude, thanwhat was achieved in wet-lab experiments (Nardecchia, 2012). Soon after some investi-gation, it turned out that the time mismatch could have been due to a naive approach inthe simulation. The biological entities were in fact treated as point particles instead ofrigid bodies.Even if this is perfectly acceptable in many cases, in the particular scenario of DNA-Restriction Enzyme interactions, this approximation turns out to be too rough to address

1 Centre d’Immunologie de Marseille-Luminy, http://www.ciml.univ-mrs.fr/

2 Simulation and Visualization of a 3D Biological Environment. DNA and Restriction Enzyme Case Study

the problem. The main drawback may be related to the fact that these molecules have tostay in a precise orientation with respect to each other in order to react properly.So, we set our objectives for the project: build a software for helping biophysicists ininvestigating DNA-proteins interactions by taking into account what was supposed to bewrong in previous work. We have been developing a simulator working with rigid bod-ies and their dynamics due to movement, rotation and collision. In addition to this, wewanted to have a 3D viewer for analyzing the simulation logs. Such a viewer must bepowerful enough to display any biological entity in the simulated world and to allow theuser to navigate through space and time in the simulation.I have been developing this project for several months but it has its roots in previous works(Micucci, 2013), (Tesei, 2014). My work could be seen as a second iteration, rather thana revision, of a project that has gone on for many years. At first, the objective was todevelop exclusively the GUI, the tools for the simulation and, more importantly, a 3Dviewer for displaying the simulation logs. Soon enough, however, we realized that therewas more to cover regarding the simulation phase; for instance improving the accuracy ofthe collision detection and implementing interactions between biological molecules.During the development of the BioLab project, several topics were covered and problemsaddressed. Regarding the simulator, we had to make our own 3D version of the biologicalentities that could be used as rigid bodies (as opposed to point particles) in the simula-tions. We created the algorithm for the simulation itself by making use of a physics library.Dealing with the accuracy of collision checking when handling collisions brought us toimplement a system for a dynamic simulation step that increases the accuracy whenevera collision occurs. As for the user interface and the 3D viewer, we had to build a softwarepackage in which the simulator could be embedded. Such viewer was developed for al-lowing the researchers to visualize in a 3D scene the log files generated by the simulator.We put effort into making the viewer being able to render the simulation at the same timerate of the simulation time. We also addressed the possibility for the user of the softwareto adjust the viewer time rate by speeding it up and slowing it down. The results obtainedqualitatively reveal that, when addressing the DNA-Restriction Enzyme interaction sce-nario, treating the entities as rigid bodies instead of point particles may indeed make thedifference and explain the time mismatch between wet-lab and simulated experiments.Implementing the orientation of the biological entities and the attractive force betweenthem led us to positive results in comparison to what previously achieved.This report is written following the software engineering approach. Each chapter will gothrough every aspect of the software development from its requirements to our implemen-tation.In this chapter we gave the reader an overview of the project, the motivations behind its

Mirco Pazzaglia 3

conception and the goals we had set for it. In Chapter 2 we will focus on the biologicalbackground needed for understanding our research and project development. We will gointo details about the phenomenon that motivated the development of the software. InChapter 3 we will present introductory details to the software engineering process of Bio-Lab . We will provide the dictionary of terms and the project requirements. Chapter 4 willdescribe the design stage of the project by using specific schematics related to this verystage such as activity diagrams and sequence diagrams. Then in Chapter 5 we will showwhich technologies we decided to use for the development of our project. We will alsogive some motivations behind those choices and explain how we intended to use themin the development process. In Chapter 6 we will use what we produced and describedin previous chapters as a basis for the software development and we will give the readeran insight into its structure as it has been implemented. Subsequently, in Chapter 7, wewill provide the reader with a final overview of the complete BioLab software suite, withsome screenshots and the results of our tests. Lastly, Chapter 8 will serve to cover whatmay come next in the development of this project. In fact, the reader should be aware thatthis project is still a work in progress that (if not discontinued) will be carried on also byother students and researchers. The conclusions will address why we are still far fromcompletion, but we will also recap how much we have done.

5

Chapter 2

Biological Background

In this chapter we are going to introduce the reader to the biological (and physical) con-cepts that our project is developed upon. As we have already discussed in Chapter 1, ourmain focus is on two biological molecules: the DNA (Watson & Crick, 1953) (also knownas Deoxyribonucleic Acid) and the Restriction Enzyme (Smith & Welcox, 1970). Wewill give the reader some hints on their nature and behavior in the intracellular environ-ment.

2.1 Deoxyribonucleic Acid Molecule

The DNA is a famous biological molecule whose structure is shaped as a double-helixthat (in eukaryotes organisms) is located in the cell nucleus.


Figure 2.1: The structure of the DNA molecule (DNA - Wikipedia, Accessed: 2014-09-16)

This molecule is a nucleic acid and it encodes, through a repetition of four nucleobases(paired two by two), all the instructions for the development of all the living beings. TheDNA’s typical double-helix shape originates from two strands coiled around each other;they contain the nucleobases, which are paired through hydrogen bonds. The nucleobasesare adenine, cytosine, guanine and thymine; they usually are abbreviated as (respec-tively) A, C, G and T. The information encoded as a sequence of those bases is used thecell to make proteins. When the cell divides or when a sequence of DNA is transcribedinto RNA (which in turn is used for making proteins), the strands are uncoiled and thebases are unpaired in order to be read.

2.2 Restriction Enzyme

A restriction enzyme (also known as restriction endonuclease or simply endonuclease)is a biological molecule which cuts the DNA double-helix molecule at specific restrictionsites.

Mirco Pazzaglia 7

Figure 2.2: Restriction Enzymes (Restriction Endonucleases: Molecular Cloning and

Beyond, Accessed: 2014-09-16)

The site eligibility depends on the specific enzyme and is found by the enzyme when acertain nucleotide pattern is read. The site cut by each endonuclease can also be referredas restriction site while the pattern that triggers the enzyme can be referred as recognition

site.So, different patterns are recognized and cut by as many endonucleases; thousands ofdifferent restriction enzymes have been studied over the years. However, each of themcan be classified into four distinct groups based on where they cleave, with respect to therecognition sites. Those groups are Type I, Type II, Type III and Type IV.

Figure 2.3: EcoRI restriction of a DNA molecule (EcoRI, Accessed: 2014-09-16)

Restriction enzymes may cleave the DNA in two distinct manners. The first (shownin Figure 2.3) results in two DNA sub-molecules that have complementary tails (calledSticky Ends). If those ends meet they can bond back together. This principle is also usedin cloning and in genetic engineering.


In the second type of cut, the two DNA strands have no tails, that is, they terminate in abase pair. This results in two sub-molecules whose ends are called Blunt Ends.

2.3 Problem Analysis: Stereospecific Reaction

When a restriction enzyme collides with a DNA molecule it starts reading the nucleotidesuntil it recognizes a given pattern. In our case study we will often refer to the EcoRIendonuclease, which is a Type II restriction enzyme. This is an enzyme isolated from theEscherichia Coli (Meselson & Yuan, 1968). It cleaves the nucleic sequence GAATTC1

and produces two sub-DNA molecules whose sticky ends are composed of AATT andTTAA respectively. When this occurs we will say that the Restriction Enzyme reactswith the DNA molecule. For our purposes, we are not interested in the search for the nu-cleic sequence which has already been covered in the literature. Instead we are interestedin the process involving the engagement between the molecules: how long does it take forthem to approach each other?An interesting and non-negligible fact is that in order for the restriction enzyme and theDNA molecule to react, they must be properly oriented and arranged in space.

Figure 2.4: DNA-Restriction Enzyme interaction

In fact, it is not enough for them to just touch each other but, as it usually happens forbiological molecules, they must interact at some specific sites. A stereospecific reactionis one in which the reaction can take place only meeting this condition. When a collision

1

• A (Adenine) pairs with T (Thymine).• C (Cytosine) pairs with G (Guanine).

Mirco Pazzaglia 9

occurs in the active sites of the molecules the reaction takes place with 100% probability.Our goal is to develop a simulation software for this type of scenario in which the user mayinvestigate the elapsed time from the beginning of the simulation until the in-situ reactiontakes place. The variables of the system are the concentration of DNA and RestrictionEnzyme molecules in a given volume.

2.4 The Environment

The environment that contains the aforementioned biological molecules is aquatic (bothin wet-lab experiments and in living cells). This environment serves as a spatial boundaryfor the molecules contained in it and it may be referred as domain. Anything happeningoutside the environment is not relevant for the experiment (and simulation), thus we willfocus on its properties and only on what happens inside of it.The domain boundary is the cell nucleus membrane and we will approximate it with anartificial box surrounding the biological molecules such that they bounce off any timethey collide with it.

2.4.1 Brownian Motion

Since the environment in which the biological molecules are placed is a fluid (i.e. water) atan absolute temperature greater than zero (often assumed to be human body temperature)the molecule by which it is composed are thermally excited. Thus, the big molecules(i.e. our entities of interest) inside the domain collide continuously with smaller watermolecules and move around stochastically according to the Brownian motion. There aremany forces acting upon the entities such as the drag of the fluid and the stochastic forceof the Brownian motion. The latter, described as a Wiener process, could be expressedas √

2γkBT · ~N ; γ = 6π ·Rhyd · η

In the equation above ~N is a stochastic vector in which each component is a normaldistribution (mean zero, standard deviation one), one independent from the other. kb isthe Boltzmann constant that relates the energy of individual particles with the temperatureof the system. T represents the absolute temperature of the system. η is the water viscositywhen its absolute temperature is equal to 300K. Rhyd represents the hydrodynamic radius(or Stokes radius) (Kok & Rudin, 1981).


2.4.2 Long-Range Interaction

It has been long hypothesized and tested that in such an environment and in such a smallscale, a particular type of attraction force may exist. This is called Long-Range Inter-action and it comes from an electrodynamic phenomenon. This interaction is opposed toa short-ranged interaction which conversely builds on a electrostatic phenomenon (Preto& Pettini, 2012).In fact, the hypothesis under study is that, when two biological molecules, which are cog-nate partners, resonate at the same high frequency, they develop an electrodynamic effectthat breaks through the Debye Screening, the dielectric coefficient of the medium (water)and the ions contained in the environment and makes them attract each other. Therefore,each biological entity originates a long-range potential field. Studies (Preto, Floriani,Nardecchia, Ferrier, & Pettini, 2012) have described this potential field and the potentialenergy of the biological entities; that results in the following relation

U(r) ∝ − 1

r3.

As one can see, the potential energy from the long-range interaction, is inversely propor-tional to the cubic power of the distance. For our purposes we will use

U(r) = − c

r3 + α

as a generic formula in which the two parameters c and α may vary (standard values forthose are α = 0.25µm3, c = 104KDa·µm

5

µs2).

11

Chapter 3

Requirements and Specifications

In this chapter we are going to describe what the requirements for the BioLab project are,what we would expect to be implemented in the final version of the software as well as alist of recurring terms to make them as clear as possible to the reader.

The software we wanted to develop had to be easy to use (user-friendly) bearing in mindthat the target user might not be a computer scientist. Thus, we wanted to embrace thekeep it simple and essential style whenever applicable both for the user interface andfor the user experience. We expected to be able to give the users as much control overthe simulation as needed; that is, the user must be able to set specific parameters forcustomizing each aspect of the simulation. Each simulation was expected to generate atleast an output file for the log that could then be imported in the 3D viewer (or scenerenderer). The viewer had to be straightforward in its use and it should have served theuser for navigating through space and time when rendering a given simulation log. Lastly,we wanted the software to come as a package of both the simulation tool and 3D vieweri.e. as a software suite.

3.1 Dictionary of Terms

In this section of the report we will introduce a summary of specific terms that are goingto be used in the rest of the thesis and that have also been used so far. We will explainthose words and set a specific context for them trying to avoid any possible ambiguity.Most importantly we are not interested in giving the specific meaning for the words butrather their meaning related to the project development. Should those words be used inany other contexts than the ones given in the following table, we will explicitly point out


the intended meaning.There are words that are going to be used throughout the whole report that are just syn-onyms for different contexts; we will include also these words.The dictionary of terms is presented in alphabetical order.

Term DescriptionAttractive Force (Intracel-lular)

This is a force supposed to exist inside the cell between bio-logical entities. If correctly proven it may be accountable fora particular attraction between DNA and Restriction Enzymemolecules.

Biological Entity Entities we use for our simulation purposes (DNA and Restric-tion Enzyme molecules). Those are used both in simulationand in the scene rendering.

Bounding Cube Synonym for Enclosed Environment.

Camera Scene entity in the Viewer that captures the images. This canbe moved around the scene by user interaction in order to ob-serve the simulation at any angle and from any point in space.

Collision When two entities end up touching each other at any givenpoint (or set of points) of their surfaces.

Cylinder The mesh representing the DNA in our simulation softwareand 3D Viewer.

Domain Synonym for Enclosed Environment.

DNA Biological molecule which encodes instructions for the devel-opment of all the living beings. The DNA molecule is one ofthe two biological entities that we are using in our simulations.It reacts when colliding in a specific manner with a RestrictionEnzyme

Enclosed Environment The portion of three dimensional space wherein the whole sim-ulation is computed. This is shown in the 3D viewer as a semi-transparent cube.

Endonuclease (Type II) Synonym for Restriction Enzyme

Frame Individual and discrete step of the simulation. Each frame con-tains information about every biological entity in the scene.When referring to the viewer, a frame is the static image ren-dered by the graphics engine, composed by pixels and dis-played onto the screen.

Mirco Pazzaglia 13

Term DescriptionLong-Range InteractionForce

This an electrodynamic force that may be accountable for theattraction between DNA molecules and Restriction Enzymes.(same as Attraction Force)

Mesh 3D model described by vertices, edges and faces, rendered bythe graphics engine. The DNA’s mesh is a cylinder while theRestriction Enzyme’s mesh is a spherical sector.

In Situ Reaction Reaction between two biological entities which is only possi-ble when the two are properly oriented (stereospecific reac-tion). It is not enough for such entities to collide, they mustalso wedge.

Player Another term for the 3D viewer

Point Particle Entity Entity treated as a point without spatial extension in the threedimensions. This is a simplification of the real world counter-part.

Properties (for biologicalentity)

The data of a biological entity recorded at each step of the sim-ulation. Those are the velocity vector, the quaternion repre-senting its orientation, the angular velocity and its position inspace.

Reaction When a DNA and a Restriction Enzyme collide properly theyreact. This is the phenomenon in which we are interested inour simulation.

Rendering Generating the images from the simulation log.

Restriction Enzyme (Abbr. RE). It is an enzyme that cuts a DNA molecule. REis one of the two biological entities we are interested in oursimulation.

Rigid Body It is a simplification of a real object which, as opposed to apoint particle, is spatially extended in the three dimensions. Itis subject to translation as well as rotation. Rotation alongsidethe three axes may have different results for each axis.

Spherical Section The mesh representing the Restriction Enzyme in our simula-tion software and 3D Viewer.

Scene Scene rendered by the 3D viewer. Inside the scene there are thebiological entities represented by their meshes, the camera anda semitransparent cube representing the enclosed environment.The user can move around the scene by translating and rotatingthe camera.


Term DescriptionSimulation The whole process in which the biological entities are spawned

inside the virtual environment and their evolution over timeis computed by the simulation software. It ends when all theDNA molecules react with the Restriction Enzymes.

Simulation Batch A number of simulations executed one after the other with thesame configuration parameters.

Simulation Log The output file generated by the simulation which stores themain properties of each biological entity for each frame (orstep) of the simulation.

Simulation Parameter The properties that can be set for customizing the simulationsuch as the number of DNA molecules, RE molecules, the at-traction force and so on.

Software Suite The aggregation of both the simulation tool and the 3D viewer.It could be also referred as software platform.

Timeline The slider which can be used for navigating through time in agiven simulation from its beginning to the end.

Viewer In our suite, the viewer is the piece of software which allowsthe user to read a simulation log and to render it in a 3D scene.Here the user can see what happened in the simulation to thebiological entities.

Table 3.1: Dictionary of Terms

3.2 Requirements

In the next subsections we are going to describe what are the system requirements for thesoftware we wanted to develop. Those are intended to be the key features of the suite;they are used as a reference for what the system should be and how it should work at theend of the development cycle. Following the standard software engineering approach werelied on the subdivision in functional and non-functional requirements. We will use theMoSCoW1 method and use a tabular representation.

1 Requirements that satisfies one of the following priorities. Must Have, if a requirement must besatisfied when the software is completed. Should Have, if a requirement should be in the final version ofthe software and if it cannot, it must somehow be replaced. Could Have, if a requirement is not strictlynecessary for the success of the software and may be skipped if resources (time, money and so on) for itsdevelopment are not enough or met at all. Won’t Have, if a requirement is not going to be implemented

Mirco Pazzaglia 15

3.2.1 Functional Requirements

The functional requirements must be always kept in mind when developing the softwarebecause they stress what it must do and what its behavior must be.

Requirement MoSCoWSimulation of Biological Entities interactions Must Have

Customizable parameters for the simulation Should Have

Simulation log as output of an execution Must Have

Output a CSV file for each simulation for statistical analysis Should Have

3D rendering for the simulation log Must Have

Use of Virtual Reality for exploring the 3D scene Could Have

Handle more than two distinct biological entities Won’t Have

Customizable biological entity 3D model Won’t Have

More than one biological entity for each type Must Have

Space and time navigability in the 3D viewer Must Have

DNA removed from the simulation after reacting with RE Must Have

Highlight and jump to key frames in the viewer Must Have

Table 3.2: Functional Requirements

3.2.2 Non-Functional Requirements

On the other hand, non-functional requirements describes how the system should behavewhen working. Non-functional requirements typically describe the performance of thesystem, its accessibility and so on.

Requirement MoSCoWSoft interruption of a simulation during execution Should Have

Fast 3D rendering Must Have

Fast import of simulation logs Should Have

Fast navigability in 3D viewer Must Have

User-friendly UI2 Should Have

Simulation and 3D Viewer integrated in a software suite Must Have

in the software, either to explicitly tell what must not be implemented or to avoid wasting resources in afeature which may come in future releases.

2 User Interface


Requirement MoSCoWSoftware extensibility through plug-ins Won’t Have

Simulation outputs compatible with file formats of other exist-ing software

Could Have

Cross-platform suite Should Have

Fancy 3D graphics and modern shaders Could Have

Show/Hide the bounding cube Should Have

Display useful information in 3D Viewer (velocity vectors) Must Have

Simulation tool and 3D viewer developed using the same tech-nology

Won’t Have

Show colliding points in the viewer Could Have

Randomly initialize biological entities Must Have

The software can run on slow hardware systems Should Have

Table 3.3: Non-Functional Requirements

3.3 Use Case

Use Case Diagrams are a tool for describing what services are provided by a given system.Those services are used by actors (which may be humans or other services/platforms) whooperate upon the system (or a part of it). As shown in Figure 3.1, the main user for our

Figure 3.1: Use Case Diagram

Mirco Pazzaglia 17

software platform is the scientist. When the system will be completed, it is supposed tolet them either run a new simulation or render a previously computed one. When runninga simulation the user may be asked to configure some parameters or may be given theoption to change them from their default values, if needed. Once the simulation ends, alog file is generated; this file can be saved and examined at a later time.When the user runs the 3D viewer we must allow them to move around the scene at anyangle, and to move back and forth in time to visualize specific moments in the simulationhistory.

Use Case Run SimulationBrief Description The user can run a new simulation in order to get log files for further

investigation.

Trigger Event The user interacts with the software and runs a simulation.

Actors The biophysicist.

Precondition The user has properly configured the simulation parameters.

Postcondition• On Success - The user obtains simulation log files which can

be used for visualizing them and where the reaction times arelisted.• On Failure - The user is notified that the simulation did not

run correctly.

Flow of Activity1. The user starts the BioLab software.2. The user configures the simulation parameters.3. The user runs the simulation.4. The user waits for completion (or error notice).

Table 3.4: Use Case - Run Simulation


Use Case View SimulationBrief Description The user can visualize in a 3D environment a previously stored

simulation log.

Trigger Event The user interacts with the software and starts rendering a log file.

Actors The biophysicist.

Precondition The user provides the 3D viewer with a simulation log generatedby the BioLab simulation tool.

Postcondition The viewer frees up the memory used for the rendering.

Flow of Activity1. The user runs the BioLab software.2. The user provides the viewer with a simulation log file.3. The user runs the rendering process for the 3D scene.

Table 3.5: Use Case - View Simulation

19

Chapter 4

Project Design

In this chapter we will go through the process of designing various aspects of the BioLabproject. We will give an overview of what choices have been made in the early stages ofthe development, so that it would be easy to understand the path we have followed. Wewill use some UML diagrams and we will describe them, in order to show the reader howthe software is supposed to evolve in the next stages of its development (as well as in nextchapters).


4.1 Activity Diagram

Activity Diagrams schematically show the behavior of a given procedure of the system.In this chapter we will focus on two major procedures for our software package.The first activity diagram (shown in figure 4.1) is an excerpt of the algorithm under thehood of the simulation tool. The future development of the algorithm will rely on thissketch that will be used as its basis.

Figure 4.1: Simulation - Activity Diagram

Mirco Pazzaglia 21

Now we will go into the details of each step of the diagram.Firstly, the simulation software should load every resource for the biological entities andthe enclosed environment. At this engineering stage we do not know how those files willbe structured; however we definitely know that those files are going to play an essentialrole in our project.The software then must create the biological entities inside the simulated environment.The created rigid bodies are then spawned by randomly locating them inside the enclosedenvironment and are randomly oriented. It is possible that in this process some of bio-logical entities, end up in an invalid position (overlapping with one another or exceedingthe enclosed environment). When this happens the algorithm should simply reiterate theprocedure until a valid configuration is reached and then terminate.Upon success of the set-up phase, the log file for the simulation must be created and ini-tialized. Then, the simulation itself can be run. It consists of a loop going through eachframe (or step) that the simulation will be composed of. At each step, every biological en-tity is moved in the enclosed environment due to the Brownian motion and the long-rangeinteraction force existing in the intracellular space (for details see Section 6.4). Afterward,the state of the system is written in the log file. A collision check is then performed; iftwo or more biological entities are colliding in the right way to trigger the stereospecificreaction in the current frame, we need to check if after removing the DNA molecule, thereare other DNA molecules around or if it was the last one for the simulation.If it was not the last one or there were no collisions at all in the current frame, the al-gorithm repeats the previous steps by applying the Brownian motion and the long-rangeinteraction force to every biological entity in their new configuration.This is repeated all over again until the last DNA molecule still existing in the simulationreacts with a Restriction Enzyme. In that case, the output log is finalized and the simula-tion ends.


Figure 4.2: 3D Viewer - Activity Diagram

The activity diagram shown in Figure 4.2, represents the procedure for loading a simula-tion in the 3D viewer.It all starts by loading the 3D resources (such as 3D models for the biological entities,shaders, terrain and so on). Then, the file log is read; specifically the header in whichsome preliminary data are stored (i.e. amount of molecules). Thanks to that data it ispossible to instantiate the biological entities.Afterwards, until the file is completely parsed, the viewer must load the data for eachframe into memory so that it could be displayed.When no more frames are left, the viewer must render the scene and it must enter themain loop in which the user may interact with the rendered simulation.

4.2 Sequence Diagram

Figure 4.3 shows a sequence diagram for the procedure described by the activity in Fig-ure 4.1.

Mirco Pazzaglia 23

Figure 4.3: Simulation - Sequence Diagram

In this diagram it is possible to understand how this aspect of the project is going tobe developed. There must be four major modules. The front-end is what the user mayinteract with. Through the front-end the user will input the parameters for each simulation(i.e. amount of biological entities). Those are then passed to the back-end, which is themain module where pretty much everything takes place.At the beginning, the back-end asks the resource loader module to import the biologicalentities, which are returned to the main back-end activity. Then it enters the previouslydescribed simulation loop. Here the simulation is computed step by step until the amountof DNA molecules is zero.In the meanwhile, the file manager module is asked to output the data to the simulationlog. When the simulation ends, the file is finalized.

4.3 Software Integration

We have already discussed that the BioLab project is composed by both the simulationtool and the viewer. In this design section we will try to focus on how the data flows fromthe simulation to the viewer.The first thing we may expect is to have some kind of input files to be processed. Those


will be processed by the simulation tool. In turn, the simulator will generate an outputfile, known as log file, which will contain all the information recorded, which is neces-sary for reconstructing the whole simulation. In the log file some basic information hasto be written: the total frame count, amount of DNA molecules, amount of RestrictionEnzymes, the data of each frame, and so on. Such data must represent the state of thebiophysical system at any given moment in time (or frame) of the simulation.Lastly, the output file of the simulator will be treated as an input file for the 3D viewer.The viewer will read and parse the log file in order to load everything into its memory.From now on, the user may explore the rendered scene both in space and in time.

Figure 4.4: Project Suite Flowchart

The Figure 4.4 is a simple schematic description of the concept previously described. Itis pretty straightforward but it will be extended further in the subsequent chapters, as theengineering phases approach the real implementation of the BioLab project.

25

Chapter 5

Project Technologies

In previous chapters we described the basis for the development of the project. We beganwith the problem analysis through the project design and we are now ready for describingthe technologies that fit our purposes best. We are getting more into the technical andpractical issues thanks to what we planned ahead with schematics, tables and diagrams.In this chapter we will describe the technologies we chose for the development of ourBioLab project. We will present them and give the reader as much information as neededfor letting him or her get a grasp as well.In Section 4.3 we explicitly described our project to be subdivided into two main pieces ofsoftware. The first being the simulator and the second being the 3D viewer for simulationlogs. Since those two systems have distinct behavior and requirements to satisfy, it wasnatural to head towards two distinct types of software modules. In both cases, in order tomaintain the focus on our goals, we avoided to reinvent the wheel, thus we searched forexisting libraries that could be used for our purposes. Specifically, we needed a PhysicsEngine for our simulator and a Graphics Engine for our 3D viewer.

5.1 Physics Engine

The first part of our project was the simulator. In fact there would be nothing to visualizein the viewer if no simulation logs were made. The reader, at this point, may come upwith the following question: why have not we embedded the viewer into the simulator sothat each simulation could be rendered as it goes?


The answer to that question is simple. We wanted the simulation to be offline1 by splittingit from the viewer; in such a way we could obtain a faster simulation software since nographical output was needed. Furthermore, each offline simulation generates a log thatmay be stored and then analyzed or read (played by the viewer) whenever needed. Thistype of simulation also allows biophysicists to run many simulations one after the otherin what we call simulation batches.Having said that, we need to pinpoint what our biological simulation is like. When work-ing with intracellular reactions (not just between DNAs and REs) we are getting veryclose to the fundamental building blocks. The more one gets to that scale the more otherdisciplines than biology itself take over; namely physics and chemistry. The in-situ reac-tion between DNA molecules and Restriction Enzymes is activated only after a specificspatial arrangement of the two is achieved. It all gets back to the physics of motion, at-tractive forces and collisions. Thus, what we were after was a specific type of softwarelibrary called Physics Engine.A Physics Engine is a software component that takes care of implementing and runningspecific routines for physical systems in which bodies or particles are the actors. Thiscomponent embeds mathematical and physical models of our world i.e. laws that describekinematic and static/dynamic systems (gravity, rigid/soft body dynamics, fluid dynamics,and so on).

5.1.1 Bullet Physics Engine

Figure 5.1: Bullet Physics - Logo

Since BioLab has its roots in previously developed software, we found it best to continuewith something we already knew and which worked well. For this reason, we have con-firmed Bullet as the Physics Engine we wanted to use (Bullet Physics Library: Real-Time

1 An offline simulation gathers all the resources needed once and runs from start to finish while produc-ing an output log which may be consulted later on. An online simulation constantly requires some inputand it displays its output at any step.

Mirco Pazzaglia 27

Physics Simulation, Accessed: 2014-09-16), (Erwin et al., Accessed: 2014-09-16).Bullet is a free, open source, physics library originally created by Erwin Coumans anddeveloped by a small community which contributes to the project. There are currentlytwo branches of the software being developed: the stable version 2.82 (which is movingto 2.83) and the experimental 3.0. Bullet is licensed under the ZLib License2 and free forcommercial use. This library has been made famous by many games developed for PC,gaming consoles and smartphones as well as animation movies. It is written in C++ andit has been developed modularly, thus different aspects of the library may be swapped orimplemented as necessary. Bullet Physics supports discrete and continuous collision de-tection. It implements rigid bodies dynamics, soft bodies dynamics (deformable bodies),the serialization of physics data in its own .bullet file structure and it has been supportedand integrated as a plug-in by many 3D graphics modeling and animating software suchas Blender, Maya, 3D Studio Max.At version 2.83 Bullet still lacks some important features such as GPU computing; thisfeature is going to be implemented in Bullet 3. Thanks to the features previously describedand the large support given by the community, this physics engine has reached a high qual-ity standard and it can compete with many other famous physics engines (Hummel, Wolff,Stein, Gerndt, & Kuhlen, 2012).

5.2 Graphics Engine

The second part of our project is aimed at constructing and rendering in 3D graphicsthe scene from a previously generated simulation log. Any simulation log contains allthe information needed for displaying on screen the biological entities. For our purposeswe needed some software component that could easily render 3D graphics and handlereal-time inputs from the user. The type of component that better suits that descriptionis a Game Engine, which provides these features and much more (audio, networking,artificial intelligence, scripting, etc.). Specifically, the Graphics Engine is a subroutine ofa Game Engine that takes care of what concerns graphical input/output. As for graphicalinputs, it must have an importer module for loading specific 3D mesh and data. As forthe outputs, it must expose a set of API for the developers, which gives them the abilityto interact with every single subroutine of the graphics rendering pipeline. From simplevertex operations, to custom shaders, from reference systems to animations and so on.In our previous works, the graphics engine that was used was Ogre3D (OGRE – Open

Source 3D Graphics Engine, Accessed: 2014-09-16). It is a cross-platform open source

2 http://opensource.org/licenses/zlib-license.php


rendering engine written in C++ by the OGRE Team. However, for our purposes it wasnot enough on its own for the complete development of the 3D viewer as it lacked a widecommunity and ease of use among other things. Thus, we looked for something moreadvanced, modern and widely supported and we ended up choosing Unity.

5.2.1 Unity 3D

Figure 5.2: Unity - Logo

Unity (Unity - Game Engine, Accessed: 2014-09-16) is a combination of a completegame engine, an integrated development environment, tools and assets; usually it is re-ferred as a game development ecosystem.We chose Unity as our graphics engine for the 3D viewer because it comes in a free ver-sion that may be upgraded to the Pro version (for more details about the Free and Pro

version of Unity see appendix A). Developing for Unity is quite straightforward and onemay find many resources on the web, thanks to its very wide community: there are tutori-als, documentation, and forums where one may find or ask for answers to their problemsand there is an official asset store for retrieving (both for free and by purchase) 3D mod-els, scripts, plug-ins, and so on.

Mirco Pazzaglia 29

Figure 5.3: Unity Engine - Asset Store

Unity has been developed by the Unity Technologies and it is written in C++ and C#. Theengine is incredibly cross-platform and it relies on renderers specifically written for eachplatform one may want to target. OpenGL is used for Linux, Mac OS X and Windows.Direct3D is used for Windows and XBox. OpenGL ES is used for projects running onportable devices (namely smartphones and tablets). Thus, Unity can build for all the con-soles of the current generation as well as the major PC operating systems and, as a browserplug-in, for in-browser applications. For the time being, more than 60 videogames and3D applications have been developed3 using Unity and more are yet to come.

Figure 5.4: Unity - IDE

3 http://unity3d.com/showcase/gallery


When we started the development of BioLab the current version of Unity was the 4.3 andwe kept on working with that until the end of the development process. As we write thisreport Unity has reached version 4.5 and the major release of version 5 is planned.As we have already said, Unity comes both in a Free version and a Pro version. Sincethere were no Pro feature we were going to miss, we decided to use the plain Free ver-sion.

31

Chapter 6

Project Implementation

In this chapter we will focus on the implementation of the BioLab software suite. Thanksto what we achieved in previous chapters we are now ready to give the reader an insightinto the structure of the software as it has been developed and programmed. In fact, weare moving from schematics and diagram towards the real processes of implementationand coding.

6.1 Software Suite Architecture

We have documented in previous chapters how the suite is designed. It consists of twomain parts: the first being the simulator and the second being the 3D viewer for renderingsimulation logs. This decision is also based on the tools used for the development and theprogramming languages.For the simulator, as previously discussed in Chapter 5, we decided to rely on Bullet. Thismiddleware is written in C / C++. Therefore, we decided to develop the BioLab simulatorin C++. Implementing the simulator using the same technologies of the viewer wouldhave generated an incredible overhead in the program which, in turn, would have sloweddown the computation.As for the 3D viewer, we used Unity that has its own integrated set of development tools.The core logic of the viewer has been developed by using C# scripts.Lastly, we joined the two parts of the software by creating a custom User Interface inUnity. The user interface is a scene inside the viewer that offers the user some control overthe simulations (by setting the simulation parameters) and lets them choose a simulationlog to be rendered.Now we will present how the data flow in our system from the beginning to the end.


Figure 6.1: Software Suite Architecture

We will see in detail each step of Figure 6.1 as we go along with this chapter. As the figureshows, all the software is packaged inside the GUI1. The source files are the 3D models forthe biological entities and the bounding cube (that is, the enclosed environment where thesimulation takes place). From those models we generate files compatibles with Bullet (seeSection 6.3). Those files are loaded inside our simulator in order to output a simulationlog file. Also a CSV file log is produced, which will contain all the notable information forthe biophysicists. The former log file will then be fed (if needed for further investigation)to the 3D viewer.Once we defined the data flow of our system, we had to focus on each stage, starting fromthe input files to the 3D viewer.

6.2 Development Software

In this brief section we want to acknowledge and let the reader know what software weused along the whole development of the BioLab project.All the software we used was either open-source and free licensed or licensed by theMicrosoft DreamSpark for Academic Institutions program.

• We used Blender for modeling 3D shapes. (blender.org - Home of the Blender

project - Free and Open 3D Creation Software, Accessed: 2014-09-16)

• We used Bullet as Physics Library.

1 Graphical User Interface

Mirco Pazzaglia 33

• We used Unity2 as our game engine/graphics engine.

• We used material from the Unity Asset Store for implementing the scenes in the 3Dviewer. (Unity - Asset Store, Accessed: 2014-09-16)

• We used MonoDevelop for the C# scripting of the 3D viewer. (MonoDevelop, Ac-cessed: 2014-09-16)

• We used Microsoft Visual Studio 2013 for developing the biophysical simulator.(Visual Studio, Accessed: 2014-09-16)

• We used Microsoft Viso 2013 for the schematics also included in this report. (Visio

Office, Accessed: 2014-09-16)

• We used SVN for the software versioning and revision control. (Apache Subversion,Accessed: 2014-09-16)

6.3 Generating Input Files

In this section we will show how we created the input files for our simulator.

The first thing we needed when we were starting our implementation stage was to obtainour desired biological entities in such a way that they could be both used for 3D renderingand 3D physics simulation. This was made possible by 3D modeling softwares. In ourcase, we designated Blender for the 3D modeling.

2 Under the Free Unity license


Figure 6.2: Blender - Logo

Blender is a software developed by the Blender Foundation that is widely adopted by theprofessional community of 3D graphic designers. It is free and open-source, written inPython, C and C++ and is released under the GNU GPL v2 license3.We also chose this 3D modeling software because of the ease in exporting both the 3Dmesh for the viewer and the serialized .bullet file that is used by Bullet.We wanted to create two three-dimensional shapes, one for the DNA molecule and theother one for the Restriction Enzyme. We wanted those shapes not to be too complex forthis first version of the software, yet somewhat resembling their real counterparts.

Figure 6.3: DNA 3D Mesh

Figure 6.4: Restriction Enzyme 3D Mesh

3 http://www.gnu.org/licenses/gpl-2.0.html

Mirco Pazzaglia 35

Therefore, we used a cylinder whose height is greater than its width (the height beingthe distance between the two circular surfaces) as our DNA simple model; we shaped themodel for the Restriction Enzyme in such a way it had a situ in which the DNA could fitwhen properly oriented. Thus, we created a 3D spherical sector. This has been achievedby composing the model of two specular nearly hemispherical sub-meshes.Those two models were enough for what concerns the biological entities, however wesoon realized we needed a way to represent the spatial constraints for a given simulation.For this reason, we modeled a cubic environment.

Figure 6.5: Bounding Cube 3D Mesh

The bounding cube was modeled bearing in mind that it must scale with the size of thesimulation; therefore it is a unit cube whose side length is equal to 1.The three meshes we described have had their margin property set to zero. That means thatno extra margin should be added around the object. In the second instance, the 3D meshescollision bounds have been set to Convex Hull (Convex Hull, Accessed: 2014-09-16). Acollision bound wraps a 3D mesh and it is used for collision checking: collisions occurwhenever the collision bounds of two distinct meshes overlap. Convex hull generates ashrink-wrapped simplified geometry around the mesh. Using Triangle Mesh as collisionbounds would have increased the accuracy in collision detection but it would have alsoslowed down the simulation speed. In fact, Triangle Mesh do not approximate the shape ofthe meshes, instead the triangles that compose the mesh themselves are used as collisionbounds. This results in collision bounds that match exactly the shape of the 3D object butit increases the complexity for the collision checking.Those properties we discussed were needed for the BioLab simulating tool because areinternally used by the Bullet library.Once the cylinder, the spherical sector and the cube models were ready, we needed toexport them so that they could be used both for the simulation and the viewer. Thanks toUnity, the game engine we adopted, we could just use the .blend files as they are correctlyprocessed by the model importer.


Regarding the simulator, we needed very little Python scripting in order to be able toexport the .bullet4 serialized file.

import PhysicsConstraints;

PhysicsConstraints.exportBulletFile("file.bullet")

The output .bullet file contains all the world dynamics for the 3D scene modeled inBlender.

6.4 Part 1 - Simulation

The BioLab biophysical simulator was entirely developed using the C++ language byincluding the Bullet Physics Library in our project. We have already discussed the mod-ularity of Bullet in previous chapters. Figure 6.6 is an excerpt from the Bullet API docu-mentation (Bullet Dependency Graph, Accessed: 2014-09-16) that shows the establishedhierarchy of the modules and how they are linked one another.

4 http://bulletphysics.org/mediawiki-1.5.8/index.php/Bullet_binary_serialization

Mirco Pazzaglia 37

Figure 6.6: Bullet Modules - Dependency Graph

For our purposes we used the Linear Math, Bullet Dynamics and Bullet Collision mod-ules. Furthermore, the external Bullet File Loader and Bullet World Importer havebeen used for what concerns the .bullet files loading features.The Linear Math module contains the mathematical data structure for working in a phys-ical simulation such as scalars, vectors, matrices, quaternions (Hamilton & Hamilton,1866) and so on.The Bullet Dynamics module contains the mathematical and physical structures for repre-senting physical objects as rigid or soft bodies. For our purposes, we used the rigid bodyimplementation for the DNA and RE molecules.The Bullet Collision module provides the user of the library with built-in algorithms anddata structures for the collision detection between physical entities (rigid bodies and softbodies).

Figure 6.7: Bullet Modules - Visual Studio Project


Once the project was correctly set up, we could proceed by implementing the algorithmdescribed in Chapter 4.In Figure 6.8, we shows a class diagram for the representation of a biological entity in ourproject.

Figure 6.8: Biological Entity - Class Diagram

The attributes shown in the class diagram are essential to represent a biological entity(namely for representing its position, movement and to allow the simulation tool to checkfor collisions). Each entity in the scene must be represented by a number of physicalattributes as well as a 3D mesh. The mesh is associated to the biological entity throughthe rigidBody member (which is matched in the Bullet Library with btRigidBody). Then,each of the physical attributes (position, orientation, mass, linear velocity and angular ve-

locity) is used as a member of this class. To represent those attributes, three-dimensionalvectors, quaternions and scalar values are used (all matched by specific Bullet types).First of all, the simulation program must import the .bullet files and associate to each en-tity some fundamental properties such as the mass, the restitution coefficient (relative toeach collision with any other object in the scene) and the forces acting upon it, such asgravity (which is absent in our scenario).Afterwards, the entities must be located and oriented in space. For our purposes wewanted that to happen with random values for both the orientation and spatial arrange-ment. It is worth noting that, in this process, more than one DNA molecule or RestrictionEnzyme could be spawned, based on the user’s decision.When the entities are loaded and initialized the simulator can perform the real simulationphase that is implemented in a while loop fashion. Until some condition (i.e. no moreDNA molecules to react with) is met, the simulator keeps doing the same actions to eachentity in the scene. First of all, the Brownian motion is applied to those entities every 30steps. This mimics the behavior of such entities when immersed in a fluid. The formulafor the change in velocity for each entity is as follows:

~v′ = ~v +

√∆t · σ ·N(0, 1)

∆t

Mirco Pazzaglia 39

This formula means that the current velocity vector ~v′ is updated from its previous value~v by adding to each of its components a scalar value in function of the time step ∆t, auser defined constant σ and a random value N(0, 1) generated from a normal distribution

(mean 1, standard deviation 0).Beside the Brownian motion, which is applied every 30 steps in order not to constantlychange the velocity, two other interactions take place during the simulation, one of whichis the biological attractive force that supposedly exists and favors the approach betweenDNA molecules and Restriction Enzymes. This force is applied to the entities’ rigid body;due to the Second Law of Motion, we know it builds up their velocity by changing their ac-celeration. The magnitude of the attractive force, which derives from the potential energyU(r) = − c

r3+αdescribed in Chapter 2, is computed using the following formula:

F (r) = −3c(

r

r3 + α

)2

It depends on two user defined parameters, α and c, and it is inversely proportional tothe distance r between any two entities such a force is applied to. As already mentioned,this force is attractive, thus its direction is given by the line that connects the center ofmass of the two entities, while the sense is always oriented from the biological entity theforce is applied to, to the other one. This particular type of force (which results from thelong-range interaction explained in Section 2.4.2) only acts upon two paired and distinctbiological entity types such as the DNA molecules and Restriction Enzymes. No two ormore DNA molecules are affected by this force one another (in other words, they are notcognate partners) and the same holds for two or more Restriction Enzymes. However eachmolecule of a given type is pushed towards (and pulls inwards) each and every moleculeto which it is paired, as a cognate partner, in the system.The last kind of interaction is given by the collisions between molecules themselves andbetween molecules and the bounding cube. These calculations are delegated to the BulletLibrary thanks to its collision module and are affected by the value assigned to the bio-logical entities during their initialization as previously described.As the simulation keeps going, those interactions are continuously applied. Every cycleof this loop is called step, or frame, and it is represented by the configuration of the sys-tem at any given point in time during the simulation. The duration of each step of thesimulation is set to 1

120s. We chose this value as the simulation step because it allows both

to simulate at a fast pace and to have a smooth rendering in the viewer without sacrificingthe accuracy.Every time a DNA molecule triggers an in-situ reaction in a Restriction Enzyme, that isevery time the DNA properly enters the cavity of the RE, the DNA is removed from the


simulation. There are two simplifications in this process we have decided to make withrespect to the real wet-lab case scenario. The first simplification is that in reality, the DNAonce reacted with the Restriction Enzyme does not disappear, rather it still floats aroundin the intracellular environment. The second simplification concerns the reaction time. Inour BioLab prototype software it was not a requirement for the reaction to last some time,therefore we assumed it to be instantaneous. In fact, as we wrote in Section 2.3, the searchfor the nucleic sequence to be cut by a restriction enzyme has already been covered in theliterature and we are only interested in how and when the DNA and restriction enzymemolecules engages one another.When every DNA molecule has reacted with the Restriction Enzyme(s) in the simulatedenvironment, the simulation halts. During the simulation process two output files are pro-duced. The .log output file contains the data, that is the configuration state of the system,of each biological entity for each frame of the simulation (for details see Appendix B).In addition, a CSV file is created; this file is human readable and contains just the timein milliseconds after the beginning of the simulation in which an in-situ reaction had oc-curred.In order to achieve as much accuracy as possible when dealing with collision detection,we implemented a specific feature into the simulator. As we have already reported, thestep (or frame) duration is set to 1

120s. During the initial tests we found, as a novel ap-

proach, that we could obtain a more accurate collision detection and resolution5 if wewere able to increase the time density, that is, the simulation step.

Figure 6.9: Frame rate Duality

Figure 6.9 shows a typical cycle for the main loop of the simulation. The first thingthe software does is to save the current physical configuration state. This is possible bystoring each property of the biological entities and the current simulation time. Then

5 By resolving a collision we mean all the procedures involved since the first time two entities arecolliding (passing the collision test) until their collision status decays. A collision may be resolved inseveral ways, for instance by making the two entities bounce off or by removing one from the scene as ithappens in our case study when they react.

Mirco Pazzaglia 41

the software proceeds by computing the next step of the simulation by applying all theforces and interactions described. If no collision occurs during this step, the simulationmay continue computing the next step. Otherwise, the system goes one step back in timeby restoring the previously saved state, it sets the time density (frame rate) to a higherresolution (i.e. 1

1000s) and continues to simulate as many steps as needed for resolving the

collision under this high-frame rate condition. This condition lasts until the collision thatraised it is resolved. Finally, the software reset the frame rate to the standard value andcontinue to the next frame.As a last overview over our implementation of the BioLab biophysical simulator, wewould like to bring to the attention of the reader that we made it possible for the userof our software to set some simulation parameters in order to make it customizable asneeded. In the following table we recap the parameters currently implemented in thesimulator.

Parameter Description–enzyme <AMOUNT> Set the amount of the Restriction Enzyme.

Default value: 1

–dna <AMOUNT> Set the amount of the DNA molecules. De-fult value: 1

–cubeside <SIZE> Set the size to which the unit bounding cubeis scaled to. For more biological entities thisvalue must be increased. Default value: 4

–logfilename <FILENAME> Set the filename for the output log files. De-fault value: sim.log

–outputdir <PATH> Set the directory for the output files. Defaultvalue: Same directory of the executable file.

–bulletdir <PATH> Set the directory file in which are containedthe .bullet files for the DNA, RE and bound-ing cube. Default value: Same directory ofthe executable file.

–Aforceparam <FLOAT VALUE> Set the a variable for the attractive force. De-fault value: 1

–Cforceparam <FLOAT VALUE> Set the c variable for the attractive force. De-fault value: 1

–csv:yes Enables the CSV output log files. Defaultvalue: No


Parameter Description–enzRestitution <FLOAT VALUE> Set the coefficient of restitution for the Re-

striction Enzymes. For a value of 1.0 it col-lides elastically, for positive values < 1.0 itcollides inelastically. Default value: 0.2

–dnaRestitution <FLOAT VALUE> Set the coefficient of restitution for the DNAmolecules. For a value of 1.0 it collides elas-tically, for positive values < 1.0 it collidesinelastically. Default value: 0.2

–sigma <FLOAT VALUE> Set the σ value described in the Brownianmotion formula. Default value: 1

Table 6.1: BioLab executable parameters

6.5 Part 2 - Visualization

In this section will describe the implementation process of the 3D viewer. This part of ourBioLab suite has been realized using the aforementioned Unity Engine. Thus, we used thetools provided by the Unity IDE. In addition, we intensively used the C# language to writethe custom scripts we needed for implementing the various features we were supposed toachieve in the 3D viewer.

The purpose of the viewer is simple and essential. It must load a simulation log, parse it,and finally render it to the screen allowing the user to move in time and space.A Unity project may be composed by several scenes. A scene is a self-contained envi-ronment in which objects and components, such as scripts, are included. Traditionally,in a videogame context there would be one scene per level of the game as well as onescene for the main menu and so on. In our non gaming context, we used two scenes. Thefirst being the main menu (mainmenu.unity) which we will focus on later, and the secondbeing the real 3D rendered simulation (scene1.unity).

Mirco Pazzaglia 43

Figure 6.10: Unity Engine - Scenes in the project

Each scene may contain objects such as 3D meshes, 2D/3D text, cameras and so on. Toeach object, in turn, one can attach one or more components such as textures, effects,physics attributes and scripts. The application logic is script driven; this means that thereis no main loop in which the developers can write the software behavior. Instead the pro-gram logic is written by composing the scene of one or more scripts attached to gameob-

jects. Each script can access the Unity Engine API and hook to its event dispatcher.

Figure 6.11: Unity Engine - Objects and Components

The scripts may be written in C# but also in JavaScript and in Boo6. For each of thoselanguages it is possible to import the Unity library and call its methods, use its specificobjects and variables, or hook to its event routine.

6 http://boo.codehaus.org/


Figure 6.12: Unity Engine - Scene Editor

The Unity editor is WYSIWYG7 and it reacts in real-time to the developer interaction.As they add objects, apply changes and so on, everything is shown immediately, and it ispossible to play the scene to test if everything works as expected. It is even possible toedit object properties while the scene is running, but those changes are not permanent andthey will revert to their original values as soon as the user stops the scene.In our 3D viewer Unity scene we developed several scripts which we will now describein detail.It is customary, when working with Unity scripts, to extend the MonoBehaviour class.This allows the script (if active) to register to the main loop of the Unity Engine. Specifi-cally, it is possible to program the desired behavior by implementing some given methodssuch as:

void Start(){ /* STUB */ }

This method is the first among the others to be invoked when the script is enabled. It isused for initializing variables and starting procedures.

void Update(){ /* STUB */ }

Once the script has been enabled, the Update method is invoked every time a frame isgoing to be rendered.

7 What You See Is What You Get

Mirco Pazzaglia 45

void OnGUI(){ /* STUB */ }

This method is used both for rendering the GUI and for handling events generated by theuser interaction with it. Buttons, dialogs, checkbox, textbox and other GUI elements areimplemented via this method.We have an "Act" script that is attached to the container object Script (see Figure 6.11);this is the main one and it handles the core logic of the 3D viewer. In its Start() methodwe implemented the log file loader and parser. We iterate through each frame stored inthe file and load it into the main memory used by the application. Here we had to takeinto account the log file peculiarity such as the variable frame size (see Appendix B). Inthe OnGUI() we managed to create an on-screen user interface for providing the user withinformation about the simulation and for letting him or her move the time cursor for thesimulation, play/pause the simulation and jump to next/previous collisions. Finally on theUpdate() method we could implement the passage of time (both in forward and backwardmode).The ObjectLabel is an auxiliary script used for displaying a floating text on the renderedscene. This is used when the user ticks the Show vectors checkbox, in fact it serves fordisplaying the vector arrow and magnitude.Movement is the last script we developed and it is attached to the Main Camera. It bindsa set of keyboard keys to some movement functions. It is worth noting a particular featureof Unity’s scripting system.

Figure 6.13: Unity Engine - Public Attribute Editor

As shown in Figure 6.13, whenever in the code one declares a public attribute for aMonoBehaviour implementing class, the IDE lets you edit those values directly fromwithin itself.

6.5.1 Main Menu GUI

So far we have introduced how we implemented the 3D viewer. Now we are introducingthe GUI which we developed for allowing the user to interact with the simulator softwarein a user-friendly fashion.


Since Unity fits well for the graphics interface, we also used it for creating a Main Menufor the 3D viewer. When the user runs the software developed with unity, the main-

menu.unity scene is firstly loaded and displayed. Here the user may customize the param-eters for one or more simulations (if executed in batch) and run them. If the user doesnot need to run a new simulation but they prefer to just render a simulation log alreadycomputed, they can load it. Unity will load the scene1.unity scene which was previouslydescribed in Section 6.5 and renders the simulation by reading it from the given log file.By running a simulation within the Main Menu, a user actually starts a new process whichstarts the Bullet simulator by passing to it the customized simulation parameters set in theGUI. The script responsible for this behavior and the GUI rendering is Menu. The exter-nal process launching process however uses some Microsoft Windows specific calls.

1 while (currSim < int.Parse(iteCount)) {

2 string filename = outputFileName + "-" + System.DateTime.Now.

ToString("yyyyMMdd") + "-" + currSim + ".log";

3 System.IO.FileInfo info = new System.IO.FileInfo(Application.

dataPath + "/BulletSimulator.exe");

4 System.Diagnostics.Process proc = System.Diagnostics.Process.Start(

info.FullName,

5 "--bulletdir" + Application.dataPath +

6 " --outputdir " + location +

7 " --logfilename " + filename +

8 " --Aforceparam " + fA +

9 " --Cforceparam " + fC +

10 " --cubeside " + envSize +

11 " --dna " + dnaCount +

12 " --enzyme " + enzCount +

13 " --csv:yes "

14 );

15 proc.WaitForExit();

16 currSim++;

17 }

A typical parameters string passed to the simulator executable may look like the follow-ing:

BulletSimulator.exe --bulletdir C:/Users/M1rcu2/Desktop/Projects/thesis

/Assets --outputdir C:\ --logfilename simulation-20140805-0.log --

Aforceparam 1 --Cforceparam 1 --cubeside 4 --dna 1 --enzyme 1 --csv

:yes

Mirco Pazzaglia 47

6.6 Putting It All Together

In this chapter we have presented the two modules that compose our BioLab softwaresuite, that is the simulator and the 3D viewer; in addition, there is also the main menuwhich is part of the 3D viewer. Now we will describe how it is possible to compose thosemodules into one software package.First of all, we need to compile and get the executable for the biophysical simulator. Then,we need to build the Unity project.

Figure 6.14: Unity Engine - Build Menu

Once we are sure that the order of the scenes in the build is correct (first comes the main-

menu.unity then the scene1.unity) we can proceed and build the project.When the Unity project has been built we need to copy in its data directory (that is iden-tified by the name of the project to which it is appended the suffix _Data) the BulletSimulator and the .bullet files needed by it.


Figure 6.15: Unity Engine - Build Directory

Nearly the whole procedure could be automated by using a batch file for compiling andcopying the files into the data directory of the Unity built project.

6.7 Hardware and Software Requirements

The BioLab software suite could run on any modern computer. The software itself doesnot require any high-end expensive hardware, however the simulation is very CPU andDisk I/O intensive. Therefore, even though it could be run on a low-end computer thecomputing time could be significantly longer than when executed on a more efficientmachine. For what concerns the 3D viewer, the following hardware requirements have tobe met:

• Graphics card: DX9 (shader model 2.0) capabilities; generally everything madesince 2004 should work.

• CPU: SSE2 instruction set support.

In addition, the viewer is Disk I/O and memory intensive for what concerns the log fileloading.The simulator itself may be compiled for Windows, Mac OS X and GNU/Linux and doesnot need any external library to work properly. The Viewer however uses some Windows-only calls thus, for the time being the software suite works only on the Microsoft Windows

operating system.Generally speaking, a Unity project may be built for the following OSs: Windows XP+,Mac OS X 10.6+, Ubuntu 10.10+, SteamOS and many GNU/Linux distributions.

49

Chapter 7

Applications and Results

In this chapter we will show what the current version of our BioLab project looks like,what it can do and the results we achieved with it.

7.1 Application

In this section we will show some screenshots of the software and we will describe themin detail, showing what features they depicts.

Figure 7.1: BioLab Screenshot 1 - Main Menu


In Figure 7.1 it is possible to observe the user interface developed in the mainmenu Unityscene (Section 6.5.1). The user is given the option to customize the simulation parameterssuch as the attraction force, the amount of DNA molecules and Restriction Enzyme andso on and so forth. By pressing the Start Simulation(s) button, the user runs the simulationbatch (which is composed of a number of subsequent simulations as set by the user in theBatch size field). If the user wants to render an existing simulation file log they may pressthe Render Simulation button, and he or she will be prompted for the simulation log toload. Figure 7.2 shows the Simulator itself. It displays the parameters set for the currentsimulation. The console window remains open and the user interface stays idle in thebackground until the simulation is done.

Figure 7.2: BioLab Screenshot 2 - Simulator

At any point of the simulation process the user can stop the execution. The SIGINT

(CTRL+C) signal is handled in such a way that the software goes through one last sim-ulation step and then quits; this soft handled interrupt allows the log files to be finalizedproperly. In fact, such log files, even though they end up being incomplete, are still load-able by the viewer.Figure 7.3 shows the GUI dialog the user is prompted with when they want to render anexisting simulation log or when they choose the output directory for the simulation.

Mirco Pazzaglia 51

Figure 7.3: BioLab Screenshot 3 - Load Simulation Log File Dialog

Figure 7.4 shows how a rendered simulation looks like in our current version of the soft-ware.

Figure 7.4: BioLab Screenshot 4 - 3D Viewer


We will now inspect each elements present in the 3D viewer. First of all, we will focus onthe time controller which allows the user to move along the simulation steps.

Figure 7.5: BioLab Screenshot 5 - Time Controller

The upper part of the 3D viewer window is assigned to the time controllers. Specifically,there is a slider controller which can be manipulated by mouse interaction. Sliding thecursor to the right will make the viewer jump to a specific frame in the future whilemoving the cursor to the left will make the viewer render frames in the past from thecurrent position in time. The Play/Pause allows the user to automatically let the timecursor move at a given rate, forward or backward. The default time speed rate is in 1:1scale. One second of simulation passes in one second of 3D rendering. The time speedrate could be decreased and increased by pressing the « and » buttons (or by manuallywriting a float value in the textbox between them). By ticking the Reverse checkbox thetime will flow backward. Lastly, the Previous/Next Reaction buttons will help the user tojump to specific points in time where an in-situ reaction has occurred.

Figure 7.6: BioLab Screenshot 6 - Info and Options

In Figure 7.6 we show the left-side panel. In this panel the user may read some infor-mation about the simulation being rendered and also enable/disable some features. Asone can see, the current time and the frame number are provided to the user as well asthe bounding cube size. In addition, the user may tick two options. The first one enablesthe rendering of the bounding cube, the second one shows the velocity vectors for eachbiological entity. Lastly there is a Main Menu button which can be used to jump back tothe main menu shown in Figure 7.1.

Mirco Pazzaglia 53

Figure 7.7: BioLab Screenshot 7 - Bounding Cube

Figure 7.8: BioLab Screenshot 8 - Show Vectors Enabled

In the following table we will recap the key bindings for the 3D viewer.

Key DescriptionW Move the camera forward

A Slide the camera to the right

S Move the camera backward

D Slide the camera to the left


Key DescriptionUp Arrow Tilt the camera upward

Down Arrow Tilt the camera downward

Left Arrow Pan the camera to the left

Right Arrow Pan the camera to the right

Left Shift Move the camera upward

Left Ctrl Move the camera downward

Space Play/Pause

R Move the camera back to the initialposition and restore its initial orien-tation

Table 7.1: 3D Viewer Key Bindings

7.2 Tests and Results

In this section we shows some results we were able to achieve with the BioLab softwarewe developed. For each test, we set the parameters for the initial configuration of thesystem and ran five simulations in batch; we analyzed the resulting log file and gatheredsome data. For each one of the five simulations a test is composed of, we will report thefirst reaction time (in seconds) and the last reaction time (in seconds), the log file size (inMegaBytes) and the simulation elapsed time (in seconds). The reader should note thatthe elapsed time refers to the real time the simulation lasted while the first/last reactiontimes refers to the in-simulation times. The parameters for the long-range were set totheir default values, that is, α = 0.25µm3, c = 104KDa·µm

5

µs2as described in Chapter 2.

The reader must also be aware that these tests were mainly run for testing the capabilitiesand the efficacy/efficiency of the software developed rather than for gathering real biolog-ical results; those results will follow once the software will be handed to biophysicists.The goal of our tests is to check if we could obtain, in any circumstances, an improvementover previous work (by measuring the reaction times).The tests have been run and rendered on a home computer with the following specs:

• CPU: Quad-Core 2.66GHz (2008).

• Memory: DDR2 4GB 800MHz.

• Disk: Solid State.

Mirco Pazzaglia 55

• Graphics Card: 512MB, GPU clock 750MHz, Memory Clock 900MHz. (2008)

7.2.1 Test #1: One DNA molecule, One Endonuclease

As our first example, we show the very basic type of simulation we can achieve with theBioLab software. The configuration is as follows:

Restriction Enzyme Amount 1

DNA Molecules Amount 1

Domain Side Size 4

In this test, we focused only on the two cognate biological molecules. By setting the boxside to 4, the biological entities are allowed to move freely in the domain; this also avoidsthem to either get stuck forever or react immediately. For this reason, the following testswill also have some extra space for the entities to move into.Figure 7.9 depicts the simulation as it is rendered by the BioLab 3D viewer.

Figure 7.9: One endonuclease, one DNA molecule

In Table 7.3 we summarize the data gathered from the simulation log files. We will usethe current test as a base for the following ones.

Sim #1 Sim #2 Sim #3 Sim #4 Sim #5 Mean σ

First Reaction (s) 45.96 19.00 52.45 61.89 57.62 47.38 16.95Last Reaction (s) 45.96 19.00 52.45 61.89 57.62 47.38 16.95



File Size (MB) 3.72 1.64 4.55 5.26 4.90 4.01 1.44Elapsed Time (s) 7.01 3.39 9.38 10.65 9.61 8.01 2.90

Table 7.3: Test #1

As one can see, the first reaction time and the last reaction time are the same; in fact, thereis only one DNA molecule in the scene. The file size and the elapsed simulation time arerelatively small. The longest simulation (i.e. Sim #4) accounts for 47, 680 frames.

7.2.2 Test #2: One DNA molecule, Two Endonucleases

The second test we ran is very similar to the first one. We increased the complexity justa bit in order to keep everything under control. We added an extra Restriction Enzyme tothe biological environment.



Domain Side Size 4

Figure 7.10 shows a simulation from this test. The reader may see the two enzymes andthe DNA molecule.

Figure 7.10: Two endonucleases, one DNA molecule

Mirco Pazzaglia 57

The increased number of biological entities in the scene reflected on the elapsed timeand the log file size. However, as the reader may see in Table 7.5, the mean reactiontime (which also in this case is the same for the first and last reaction times) is nearlycomparable with the test with one Restriction Enzyme. Even though the entities mayinterfere one with another in their movement and approach, the DNA molecules getshigher chances to collide with a reacting site.




Table 7.5: Test #2

The longest simulation (i.e. Sim #1) accounts for 96, 499 frames.

7.2.3 Test #3: Two DNA molecules, One Endonucleases

In test #3 we swapped the amount of the two biological entities from the previous test.



Domain Side Size 4

Figure 7.10 is a screenshot of the BioLab 3D viewer when it renders a simulation log fromthis test.


Figure 7.11: One endonuclease, two DNA molecule

As shown in Table 7.7, two DNA molecules seem to interfere with each other more thanit happens with two endonucleases.




Table 7.7: Test #3

The mean last reaction, file size and elapsed time values nearly doubled from the previ-ous test. This is an expected behavior; in fact, for the simulation to end, all the DNAmolecules in the scene must react. While in the previous test the single molecule of DNAhad two possibilities for reacting, in this scenario the restriction enzyme must catch oneDNA at a time.The mean time for the first reaction is greater than that in Test #2 but it is not increased asmuch as the other values. In effect, the first reaction time is slowed down by the increasednumber of collisions taking place between the entities.The standard deviation is high for both the reaction times. In effect, the first simulationcould appear somewhat strange if compared to the others. Thus, we inspected the sim-ulation in the viewer and we found that, by chance, the enzyme happened to react withboth the DNA molecules one nearly subsequently the other. This is an expected behavior

Mirco Pazzaglia 59

when dealing with stochastic events and actions (such as the random initial location ofthe biological entities and the Brownian motion). The longest simulation (i.e. Sim #3)accounts for 256, 729 frames.

7.2.4 Test #4: Two DNA molecules, Two Endonucleases

This test increases the complexity of the simulation a bit more. We included two DNAmolecules and two restriction enzymes in the scene.



Domain Side Size 4

Figure 7.12 depicts a simulation log of this type of test being rendered by the BioLab 3Dviewer.

Figure 7.12: Two endonucleases, two DNA molecules

The results obtained in the current test are nearly comparable with the previous test.






Table 7.9: Test #4

The first reaction and last reaction mean times are lower than in Test #3 and, as for thefirst reaction time, similar to those of Test #2. In fact, the odds for the entities to reactincreases as the type-ratio gets back to 1:1.Both the simulation software and the viewer perform well; we preserved small time ofsimulation and fast rendering times.The longest simulation (i.e. Sim #4) accounts for 148, 597 frames.

7.2.5 Test #5: Advanced Tests

The last tests we decided to run served as a real case test scenario and as a stress test. Theresearchers may in fact run tests that resembles the chaotic environment of a cell nucleuswhere a lot of entities are contained and they interact and collide with each other.

Mirco Pazzaglia 61



Domain Side Size 10

We increased by a large step the number of the DNA molecules and Restriction Enzymesresulting in a total of 30 biological entities in the simulated scene (shown in Figure 7.13).The domain side was increased from 4 to 10 to be able to fit all the molecules inside thevolume and in order to get a similar concentration.

Figure 7.13: 20 endonucleases, 10 DNA molecules

In such a dense state of biological molecules the first reaction mean time lowered. All inall, the last reaction did not increase from previous tests. Since the RE-DNA ratio is 2:1,this example resembles that in Test #2.




Table 7.11: Test #5: Real case scenario

As expected, the simulation time (as well as the maximum frame of the simulation reachedthat increases likewise) increased both due to the complexity of the scene and to the high


number of entities. This also reflects on the log file size. In fact, in each frame the infor-mation (see Appendix B) of each individual entity must be stored .We ran this test because this type of simulation is a typical scenario for a biophysicist torun in their experiments. We know that the software suite can handle such scenarios andthat it worked as expected both efficiently and effectively.The longest simulation (i.e. Sim #2) accounts for 162, 173 frames.In addiction, we ran a stress-test simulation. This last simulation was run with 80 bi-ological entities (60 restriction enzymes and 20 DNA molecules). The following tablesummarizes the data gathered from the test.

ValuesFirst Reaction (s) 4.13

Last Reaction (s) 165.48

File Size (MB) 545.34

Elapsed Time (s) 1110.9

Table 7.12: Test #5: Stress-test

The simulation accounts for 165, 272 frames and it took almost 19 minutes to be com-puted. The output log file is quite big in its size even though the total in-simulation timeand amount of frames are not that far from previous tests. This can be explained by themassive amount of data that needs to be stored in each frame.

7.2.6 Overall Assessment

The tests we carried out in this section, scaled from the the very basic one to a real casescenario that the BioLab project aims to address. Table 7.13 summarizes the test meanvalues.

Test #1 Test #2 Test #3 Test #4 Test #5.1 Test #5.2(*)First Reaction (s) 47.38 46.95 70.11 50.10 6.17 4.13

Last Reaction (s) 47.38 46.95 176.75 110.88 118.99 165.48

File Size (MB) 4.01 7.14 18.9 18.55 142.40 545.34

Elapsed Time (s) 8.01 19.98 37.52 42.10 233.26 1110.9

Table 7.13: Tests recap. (*) Only one test was done.

Mirco Pazzaglia 63

When analyzing the individual tests and comparing the different simulations for each ofthem, it may at first seem that some values are floating too much and that some tests havesimilar results irrespectively of their complexity. In fact, the standard deviation of thetests is high in many instances. This is an expected behavior if one takes into accountthat in this type of simulation there is a non-negligible random behavior (i.e. Brownian

motion and initial position of the entities) embedded in the system.As for the 3D viewer, we want to provide some additional data about its performance. Forthis purpose, we actually focused on the three more computationally intensive tests.

Test #5.2 Test #5.1 - Sim #2 Test #4 - Sim #4Max Loading Time 1m 25s 29s 5s

Max CPU Load 7.5% 4.7% 2.9%

Max RAM Load 475MB 200MB 76MB

Table 7.14: 3D viewer performance

To conclude, the results we obtained from the tests we did, show that the first reaction timeis in the order of seconds. This qualitative result is definitely positive when comparedwith previous simulation tools which were off by three orders of magnitude (order ofmilliseconds) (Nardecchia, 2012). The physical representation of biological molecules asrigid bodies may indeed be the key for a more accurate simulation. However, we mightstill need to put some effort to improve the quantitative accuracy of our simulation tool.In fact, as we have said in Section 7.2, we will need to hand the software to biophysicistsfor real in-lab experimentations that may help us in fine tuning the simulation parameters,the molecule 3D model and its attributes, and so on.

65

Chapter 8

Conclusions

In this chapter we will recap what we discussed and described throughout this report.Then, we will give some details about what may come next in the future development ofthe BioLab project.We started giving the reader an overview of the problems we wanted to address. The timediscrepancy between wet-lab experiments and the simulated ones was the motivation thatled us to develop a new kind of simulator which took into account rigid bodies instead ofpoint particles.We showed how we started from this simple idea and from previous works, to develop anew software, that practically became a complete suite of a 3D viewer and a simulationtool. This is all packaged in a graphical user interface that aims to ease the interactionwith the software from the user’s (biophysicists) point of view.We showed how we proceeded, in software engineering terms, from the bare concepts tothe requirements, from the design to the actual implementation.Finally, we showed where we got in the development process with our current versionof the software suite and we described the results we obtained. Both the simulator andthe 3D viewer performed well. We are enthusiastic about how far we got with our Bio-Lab project. The application and the results described in Chapter 7 are promising. The3D viewer allows the user to properly interact with a rendered simulation log. Regard-ing the simulation tool results, the simulation time for the first reaction is in the orderof seconds as expected and as it happens in real wet-lab experiments. This is an im-provement over previous simulation software that were off by three orders of magnitude(milliseconds) from wet-lab experiments. The rigid body physical representation of thebiological molecules and the implementation of the long-range attractive force betweencognate molecules seems to produce the expected qualitative results. For better and more


accurate quantitative results, we will hand the software to biophysicists and, by workingside by side with them, we will tune and improve our tools as needed.

8.1 Future Work

The BioLab software is still a work in progress and it is far from completion. We hope tocontinue to work on it, enhancing the already existing features and adding new ones. Inthe remaining part of the report we will try to focus on what we would like to add to thesoftware and what may come next.

8.1.1 Simulation

For what concerns the simulation there are a number of features we would like to add/im-prove:

• More accurate 3D models. So far, we represented the DNA molecule as a cylinderand the Restriction Enzyme as a spherical sector. Even if this is a step further fromthe job done by previous simulation tools, that represented them as point particles,we are still far from the real world. We did not want to add too much complexityto the simulation at first, but sooner or later it will be necessary to get as close tothe reality as possible. For instance, the DNA molecule may be represented by acomplex 3D mesh resembling its typical twisted-ladder shape.

• Sophisticated collision detection algorithms. So far, we relied on the collisiondetection algorithms provided by Bullet. However we are aware that we couldprobably get more efficient and effective collision detection by searching for othertype of algorithms. This is especially true for the in-situ collision when movingon more complex 3D shapes. In our current release, the check for the reaction ishardcoded based on the geometrical representation of the DNA and RE. In fact, itis quite simple: when the distance between a point along the surface of the cylinderand the center of the spherical sector is less than the radius of the latter, we aregeometrically sure that the DNA entered the site. However, this is not as genericas possible especially if the simulation tool is working with many different types ofmeshes.

• Open to new type of biological entities and scenarios. When we started thisproject we had just the concept of solving the time mismatch for DNA-RE reactions.As the development went along, we realized that the software could indeed serve

Mirco Pazzaglia 67

for other issues. Thus, we would like to extend BioLab to be a complete biologicalframework for investigating many problems in which a simulation tool and our 3Dviewer may help. This could be possible by extending the suite with plug-ins ormodules to dynamically load new type of biological entities inside the scene. Also,the scene may become more complex than a simple bounding cube wherein thesimulation takes place. Obstacles may be added, or tissues may be simulated. Itwould be amazing to be able to reproduce real biological scenarios as accurate aspossible (i.e. neuron cells, heart cells, and so on and so forth).

• Improved simulation parameters and forces editor. We already made possiblefor the user to customize each simulation with a number of parameters as discussedin Chapter 6. Anyway, there are a large number of parameters which are hardcodedin the simulator and cannot be edited by the user without recompiling it. Beside that,we would also like to make a specific tool for creating and editing, as modularlyas possible, formulae to be used for describing attractive/repulsive forces betweenmolecules as one may need.

• GPGPU computing physics acceleration. This is a key point that should be im-plemented as soon as possible. Being able to use a GPGPU computing techniquewould definitely speed up the whole process of simulation (for instance by usingCUDA, OpenCL or DirectCompute). Since we use Bullet as Physics Library weare definitely waiting for the next 3.0 release that will feature a 100% GPU rigidbody acceleration by implementing parallelized algorithms.

• Molecules Concentration. So far, we let the user change the domain size manually.In the future, we would like to make the domain size change automatically, bysetting a concentration value for the molecules contained in it.

8.1.2 Visualization

In this subsection we would like to focus on the future work regarding the 3D viewer.

• Visual improvements. There are a lot of minor changes that may be made to theaesthetics of the viewer. For instance, achieving better transparencies effects; wewould also like to improve the lighting in the scene, with movable lights and betterlight effects. Furthermore, features for highlighting important collisions and an autozoom-in to a current reacting sites should be added.

• Improve the user interaction with the viewer. We would like to collect feedbackon the UI of the viewer from as many users as possible and try to figure out a way


of giving the maximum control over the camera and other user interface elementsin the 3D scene without harming the ease of use.

• Stereoscopic mode. We would like to be able to add a stereoscopic renderingfeature. The stereoscopy would allow any user wearing a proper glass to perceivethe scene as if it were really in three dimensions, giving the feeling that the imagesare floating outside the screen.

• Virtual reality. This would be a step further than the stereoscopic rendering. Weare extremely interested in enhancing our viewer with the virtual reality. Nowadays,technologies like Oculus Rift (Oculus Rift, Accessed: 2014-09-16) are making vir-tual reality less expensive than ever before.

This technology would allow any glass wearing user to enter the scene and feel itfrom the inside. Moving their head they could explore the scene as if they wereinside of it.

• Buffered reader. In our BioLab prototype when a file log is loaded into the 3Dviewer, it is read from beginning to the end, and stored into the computer mainmemory. Even though this is good for moving along the time of the simulationseamlessly, it has quite a drawback both in loading times and in memory usage. Inorder to overcome to this issue, it would be smart to implement in future releasesof the software, a buffered reader for log files. This allows the program to readjust chunks of data in the time proximity of the current frame displayed. When theplayer approaches the upper or lower bound of the chunk, a new chunk should bepreloaded and swapped in when it is the right moment. An incomplete version ofthis feature is in development as a standalone application (not integrated with thesoftware suite). This feature is surely a candidate for an upcoming release.

Mirco Pazzaglia 69

8.1.3 Other

• Entirely cross-platform suite. As we write, the software suite is almost completelycross-platform, that is, it may run on many different operating systems (namelyWindows, Mac OS and GNU/Linux). However there are a small number of routines(e.g. the open file dialog in the GUI) that, for the time being, rely on the Windowsoperating system. We would like to get rid of those and obtain a pure cross-platformsoftware suite.

71

References

Apache subversion. (Accessed: 2014-09-16). https://subversion.apache

.org/.blender.org - home of the blender project - free and open 3d creation software. (Accessed:

2014-09-16). http://www.blender.org/.Bullet dependency graph. (Accessed: 2014-09-16). http://bulletphysics.org/

Bullet/BulletFull/dir_68267d1309a1af8e8297ef4c3efbcdba

.html.Bullet physics library: Real-time physics simulation. (Accessed: 2014-09-16). http://

bulletphysics.org/wordpress/.Buti, F., Cacciagrano, D., Corradini, F., Merelli, E., & Tesei, L. (2010). Bioshape: a spa-

tial shape-based scale-independent simulation environment for biological systems.Procedia Computer Science, 1(1), 827–835.

Convex hull. (Accessed: 2014-09-16). http://mathworld.wolfram.com/

ConvexHull.html.Dna - wikipedia. (Accessed: 2014-09-16). http://en.wikipedia.org/wiki/

DNA.Ecori. (Accessed: 2014-09-16). http://bio3400.nicerweb.com/Locked/

media/ch19/EcoRI.html.Erwin, C., et al. (Accessed: 2014-09-16). Bulletphysics github repository. https://

github.com/bulletphysics/bullet3.Hamilton, W. R., & Hamilton, W. E. (1866). Elements of quaternions. London: Long-

mans, Green, & Company.Hummel, J., Wolff, R., Stein, T., Gerndt, A., & Kuhlen, T. (2012). An evaluation of open

source physics engines for use in virtual reality assembly simulations. In Advances

in visual computing (pp. 346–357). Springer.Kok, C. M., & Rudin, A. (1981). Relationship between the hydrodynamic radius and the

radius of gyration of a polymer in solution. Die Makromolekulare Chemie, Rapid

Communications, 2(11), 655–659.

https://subversion.apache.org/

https://subversion.apache.org/

http://www.blender.org/

http://bulletphysics.org/Bullet/BulletFull/dir_68267d1309a1af8e8297ef4c3efbcdba.html



http://bulletphysics.org/wordpress/

http://bulletphysics.org/wordpress/

http://mathworld.wolfram.com/ConvexHull.html

http://mathworld.wolfram.com/ConvexHull.html

http://en.wikipedia.org/wiki/DNA

http://en.wikipedia.org/wiki/DNA

http://bio3400.nicerweb.com/Locked/media/ch19/EcoRI.html

http://bio3400.nicerweb.com/Locked/media/ch19/EcoRI.html

https://github.com/bulletphysics/bullet3

https://github.com/bulletphysics/bullet3


Meselson, M., & Yuan, R. (1968). Dna restriction enzyme from e. coli. Nature,217(5134), 1110.

Micucci, M. (2013). Simulazione e rendering di corpi rigidi 3d tramite bullet physics

library e ogre. University of Camerino. (Undergraduate Thesis)Monodevelop. (Accessed: 2014-09-16). http://monodevelop.com/.Nardecchia, I. (2012). Feasibility study of the experimental detection of long-range

selective resonant recruitment forces between biomolecules (Unpublished doctoraldissertation). Universitè D’Aix-Marseille.

Oculus rift. (Accessed: 2014-09-16). http://www.oculus.com/.Ogre – open source 3d graphics engine. (Accessed: 2014-09-16). http://www

.ogre3d.org/.Pierre, F., Sebastien, J., Ilaria, N., Matteo, G., Marco, P., & Luca, T. (2013). Modelling ex-

perimental search for long-range interactions between dna and restriction enzyme

in bioshape. (unpublished)Preto, J. (2012). Long-range interaction in biological systems (Unpublished doctoral

dissertation). Universitè D’Aix-Marseille.Preto, J., Floriani, E., Nardecchia, I., Ferrier, P., & Pettini, M. (2012). Experimental

assessment of the contribution of electrodynamic interactions to long-distance re-cruitment of biomolecular partners: Theoretical basis. Physical Review E, 85(4),041904.

Preto, J., & Pettini, M. (2012). Long-range resonant interactions in biological systems

(Tech. Rep. No. arXiv preprint arXiv:1201.5187). University of Marseille.Restriction endonucleases: Molecular cloning and beyond. (Accessed:

2014-09-16). https://www.neb.com/tools-and-resources/

feature-articles/restriction-endonucleases-molecular

-cloning-and-beyond.Smith, H. O., & Welcox, K. (1970). A restriction enzyme from< i> hemophilus influen-

zae</i>: I. purification and general properties. Journal of molecular biology, 51(2),379–391.

Tesei, C. (2014). Simultion of 3d rigid body with bullet physics library. University ofCamerino. (Internal Report)

Unity - asset store. (Accessed: 2014-09-16). https://www.assetstore

.unity3d.com/en/.Unity - game engine. (Accessed: 2014-09-16). unity3d.com/.Unity vs unity pro. (Accessed: 2014-09-16). http://unity3d.com/unity/

licenses.

http://monodevelop.com/

http://www.oculus.com/

http://www.ogre3d.org/

http://www.ogre3d.org/

https://www.neb.com/tools-and-resources/feature-articles/restriction-endonucleases-molecular-cloning-and-beyond



https://www.assetstore.unity3d.com/en/

https://www.assetstore.unity3d.com/en/

unity3d.com/

http://unity3d.com/unity/licenses

http://unity3d.com/unity/licenses

Mirco Pazzaglia 73

Visio office. (Accessed: 2014-09-16). http://office.microsoft.com/en-us/visio/.

Visual studio. (Accessed: 2014-09-16). http://msdn.microsoft.com/it-it/vstudio/aa718325.aspx.

Watson, J., & Crick, F. (1953). A structure for deoxyribose nucleic acid. Nature,421(6921), 397–3988.

http://office.microsoft.com/en-us/visio/

http://office.microsoft.com/en-us/visio/

http://msdn.microsoft.com/it-it/vstudio/aa718325.aspx

http://msdn.microsoft.com/it-it/vstudio/aa718325.aspx

75

Appendix A

Unity Free vs Unity Pro

Many of the contents in Unity are specifically aimed at videogame development. Suchfeatures are not useful for our purposes. The following table is an excerpt of the mainfeature available in Unity and in Unity Pro.

Feature Free ProGeneric

Physics Yes Yes

NavMesh, path-finding, crowd Simulation Yes Yes

Multiplayer Networking Yes Yes

Physics Yes Yes

LOD Support No Yes

Audio Yes Yes

Audio Filter No Yes

Video Playback and Streaming No Yes

Animation

Mecanim Yes Yes

Mecanim: IK Rigs No Yes

Mecanim Sync Layers & Additional Curves Yes Yes

Deployment

One-Click Deployment Yes Yes

Web Browser Integration Yes Yes

Custom Splash Screen No Yes

Graphics

Low Level Rendering Access Yes Yes

Dynamic Font with Markup Yes Yes


Feature Free Pro3D Texture Support No Yes

Realtime Directional Shadows Yes Yes

HDR No Yes

Light Probes No Yes

Optimized Graphics Yes Yes

Shaders Yes Yes

Render-to-Texture Effects No Yes

Occlusion Cullin No Yes

Deferred Rendering No Yes

Stencil Buffer No Yes

Code

.NET Based Scripting with C#, JS, Boo Yes Yes

Access to Web Data Yes Yes

.NET Socket Support Yes Yes

Native Code Plugins Support No Yes

Inspector GUI for custom classes Yes Yes

Editor

Integrated Editor Yes Yes

Animation Editor Yes Yes

Profiler and GPU profiling No Yes

External Version Control Support Yes Yes

Table A.1: Unity Free vs Unity Pro (Unity vs Unity Pro, Ac-cessed: 2014-09-16)

It is possible to upgrade from the Free licensed version to the Pro version at any time. ThePro version license may be obtained with a one-time purchase for 1,500$ or by subscrip-tion for 75$ per month (minimum 12 month subscription).

77

Appendix B

Simulation Log Structure

In this appendix we will describe how I structured the simulation log file. This file iswritten in binary mode, thus, knowing its structure it is possible to seek for a specificsimulation frame or data. First of all, I will introduce the reader with the parameters thatare going to be used in the following sections.

• E = amount of Restriction Enzymes in the scene.

• D = initial amount of DNA molecules in the scene.

• d = amount of DNA molecules in the current frame.

B.1 Header

Table B.1 shows the binary structure of the header of the simulation log file.

Data Type SizeBounding Cube size float 4B

E int 4B

D int 4B

Frame Count ulong 4B

MaxDNAFrame D*ulong d*4B

Total - 16B + D*4B

Table B.1: Log File Structure - Header


Parameters E and D have already been introduced. Frame Count represents the amountof total frames the simulation is composed of. Following Frame Count there are as manyMaxDNAFrame as the initial amount of DNA molecules D. This allows the system towork with frames which size changes over time. In fact, when a simulation with more thanone DNA molecules is run, it may happen that the amount of DNA molecules reduces asthe Enzymes reacts with them. Using a static sized frame would consist in a waste of spaceand time. Thus, whenever a DNA molecules reacts (that is, disappear from the simulationscene), the frame time is written in its MaxDNAFrame cell allowing the system to workwith one DNA molecule less in future frames. The header size grows with the number ofinitial DNA molecules: preamble(D) = 16 + 4D;.

B.2 Payload

Table B.2 shows the binary structure of what comes next the header in the simulation logfile.

Data Type SizeTime float 4B

Current DNA Amount int 4B

Enzyme Orientation E*4*float E*4*4B

Enzyme Position E*3*float E*3*4B

Enzyme Linear Velocity E*3*float E*3*4B

Enzyme Angular Velocity E*3*float E*3*4B

DNA Orientation d*4*float d*4*4B

DNA Position d*3*float d*3*4B

DNA Linear Velocity d*3*float d*3*4B

DNA Angular Velocity d*3*float d*3*4B

Collision bool 1B

Total - 8B + E*52B + d*52B + 1B

Table B.2: Log File Structure - Payload

As I described in Appendix B.1 the data for each frame depends on the amount of DNAin that point in the simulation (Current DNA Amount). The Time is a floating point rep-resentation of the simulation time from the beginning; it is expressed in seconds. Theposition, linear velocity and angular velocity of both the DNA molecule and Restric-tion Enzyme are expressed using float values for representing vectors in three dimensions

Mirco Pazzaglia 79

〈x, y, z〉. The orientation is represented as a quaternion in the form 〈x, y, z, w〉. Colli-

sion is a boolean value used for marking the current frame if a collision is occurring atthat point in time. The size of a given frame is calculated as follows: frame(E, d) =

8 + 52E + 52d+ 1.

B.3 Frame Seek

The following is an excerpt of the C# code that can be used for seeking a specific framein the simulation log file.

int Header()

{

return 16;

}

/// <param name="d">The initial amount of DNA molecules</param>

int Preamble(int d)

{

return Header() + 4 * d;

}

/// <param name="e">The amount of enzymes molecules in the simulation</

param>

/// <param name="d">The current amount of DNA molecules in the

simulation</param>

long Frame(int e, int d)

{

return 8 + 52 * e + 52 * d + 1;

}

/// <param name="n">The frame index to be seek in the file</param>

/// <param name="e">The amount of enzymes in the simulation</param>

/// <param name="dFC">Maximum frame count for each DNA in the

simulation (must be sorted in ascending order)</param>

/// <returns>The offset (in bytes) from the beginning of the log file</

returns>

long Frame_Seek(long n, int e, long[] dFC)

{

//Handle out of range values

if (n > dFC[dFC.Length - 1])

n = dFC[dFC.Length - 1];

if (n < 1)

n = 1;


int d = dFC.Length;

long result = Preamble(d);

long tempframe = 0;

for (int i = 0; i < dFC.Length; i++)

{

if (n > dFC[i]) //Out of current range

{

result += (dFC[i] - tempframe) * Frame(e, d);

d--;

}

else

{

result += (n - tempframe - 1) * Frame(e, d);

break;

}

tempframe = dFC[i];

}

return result;

}

School of Computer ScienceReykjavík UniversityMenntavegi 1101 Reykjavík, IcelandTel. +354 599 6200Fax +354 599 6201www.reykjavikuniversity.isISSN 1670-8539

School of Computer ScienceUniversity of CamerinoPiazza Cavour 19 / f62032 Camerino (MC), ItalyP.IVA: 00291660439CF 81001910439Tel. +354 599 6200Fax +354 599 6201http://www.unicam.it/

simulation and visualization of a 3d … and visualization of a 3d biological environment. dna and...

Documents