Simulation and Visualization of A 3D Biological Environment. Dna and Restriction Enzyme Case Study

SIMULATION AND VISUALIZATION OF A 3D
BIOLOGICAL ENVIRONMENT. DNA AND

RESTRICTION ENZYME CASE STUDY
October 2014
Mirco Pazzaglia
Master of Science in Computer Science
SIMULATION AND VISUALIZATION OF A 3D
BIOLOGICAL ENVIRONMENT. DNA AND
RESTRICTION ENZYME CASE STUDY
Mirco Pazzaglia
Master of Science
Computer Science
October 2014
School of Computer Science
Reykjavík University
University of Camerino
M.Sc. RESEARCH THESIS

ISSN 1670-8539
Simulation and Visualization of a 3D Biological
Environment. DNA and Restriction Enzyme Case Study
by
Mirco Pazzaglia
Research thesis submitted to the School of Computer Science

at Reykjavík University and at University of Camerino in partial fulfillment of
the requirements for the degree of
Master of Science in Computer Science from Reykjavík University and
Master of Science in Computer Science from University of Camerino
October 2014
Research Thesis Committee:

Anna Ingolfsdóttir, Supervisor
Professor, Reykjavík University
Luca Tesei, Supervisor

Assistant Professor, University of Camerino
Leonardo Mostarda
Associate Professor, University of Camerino
Luca Aceto
Professor, Reykjavík University
Copyright
Mirco 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 from
wet-lab experiments. It has been found, investigating the causes of such an
anomaly, that the simulation tools were making a simplistic assumption by
treating the biological molecules as point particles. We developed a new
software package that consists of a simulation tool and a 3D viewer. The
simulation software was developed by taking into account the shape of the
biological 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 and
time. We did several tests that qualitatively support the hypothesis that the
time discrepancies may, in effect, depend on the physical representation of
the biological entities. When those are treated as rigid bodies, as opposed
to point particles, the results are the same order of magnitude as those from
wet-lab experiments.
To the Cosmos. . .
vi
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 could
not 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, helped
me 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 giving
me the opportunity of the Double Degree program, such an extraordinary, yet painful at
times, experience.
I also want to thank both the Erasmus program and the ERSU-Camerino that helped me
facing 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.
viii
ix
Contents
List of Figures xi
List of Tables xiii
1 Introduction 1
2 Biological Background 5
2.1 Deoxyribonucleic Acid Molecule . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Restriction Enzyme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Problem Analysis: Stereospecific Reaction . . . . . . . . . . . . . . . . . 8
2.4 The Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Brownian Motion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2 Long-Range Interaction . . . . . . . . . . . . . . . . . . . . . . 10
3 Requirements and Specifications 11

3.1 Dictionary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . 15
3.3 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Project Design 19
4.1 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Software Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Project Technologies 25
5.1 Physics Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 Bullet Physics Engine . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Graphics Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
x
5.2.1 Unity 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Project Implementation 31
6.1 Software Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Development Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Generating Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4 Part 1 - Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.5 Part 2 - Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5.1 Main Menu GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.6 Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7 Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . 48
7 Applications and Results 49

7.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 Tests and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2.1 Test #1: One DNA molecule, One Endonuclease . . . . . . . . . 55
7.2.2 Test #2: One DNA molecule, Two Endonucleases . . . . . . . . . 56
7.2.3 Test #3: Two DNA molecules, One Endonucleases . . . . . . . . 57
7.2.4 Test #4: Two DNA molecules, Two Endonucleases . . . . . . . . 59
7.2.5 Test #5: Advanced Tests . . . . . . . . . . . . . . . . . . . . . . 60
7.2.6 Overall Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 62
8 Conclusions 65
8.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.2 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.3 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
References 71
A Unity Free vs Unity Pro 75
B Simulation Log Structure 77

B.1 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.2 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.3 Frame Seek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
xi
List of Figures
2.1 The structure of the DNA molecule . . . . . . . . . . . . . . . . . . . . . 6

2.2 Restriction Enzymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 EcoRI restriction of a DNA molecule . . . . . . . . . . . . . . . . . . . . 7
2.4 DNA-Restriction Enzyme interaction . . . . . . . . . . . . . . . . . . . . 8
3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Simulation - Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 3D Viewer - Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Simulation - Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Project Suite Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Bullet Physics - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Unity - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Unity Engine - Asset Store . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Unity - IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Software Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Blender - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 DNA 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4 Restriction Enzyme 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . 34
6.5 Bounding Cube 3D Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.6 Bullet Modules - Dependency Graph . . . . . . . . . . . . . . . . . . . . 37
6.7 Bullet Modules - Visual Studio Project . . . . . . . . . . . . . . . . . . . 37
6.8 Biological Entity - Class Diagram . . . . . . . . . . . . . . . . . . . . . 38
6.9 Frame rate Duality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.10 Unity Engine - Scenes in the project . . . . . . . . . . . . . . . . . . . . 43
6.11 Unity Engine - Objects and Components . . . . . . . . . . . . . . . . . . 43
6.12 Unity Engine - Scene Editor . . . . . . . . . . . . . . . . . . . . . . . . 44
6.13 Unity Engine - Public Attribute Editor . . . . . . . . . . . . . . . . . . . 45
xii
6.14 Unity Engine - Build Menu . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.15 Unity Engine - Build Directory . . . . . . . . . . . . . . . . . . . . . . . 48
7.1 BioLab Screenshot 1 - Main Menu . . . . . . . . . . . . . . . . . . . . . 49

7.2 BioLab Screenshot 2 - Simulator . . . . . . . . . . . . . . . . . . . . . . 50
7.3 BioLab Screenshot 3 - Load Simulation Log File Dialog . . . . . . . . . 51
7.4 BioLab Screenshot 4 - 3D Viewer . . . . . . . . . . . . . . . . . . . . . 51
7.5 BioLab Screenshot 5 - Time Controller . . . . . . . . . . . . . . . . . . . 52
7.6 BioLab Screenshot 6 - Info and Options . . . . . . . . . . . . . . . . . . 52
7.7 BioLab Screenshot 7 - Bounding Cube . . . . . . . . . . . . . . . . . . . 53
7.8 BioLab Screenshot 8 - Show Vectors Enabled . . . . . . . . . . . . . . . 53
7.9 One endonuclease, one DNA molecule . . . . . . . . . . . . . . . . . . . 55
7.10 Two endonucleases, one DNA molecule . . . . . . . . . . . . . . . . . . 56
7.11 One endonuclease, two DNA molecule . . . . . . . . . . . . . . . . . . . 58
7.12 Two endonucleases, two DNA molecules . . . . . . . . . . . . . . . . . . 59
7.13 20 endonucleases, 10 DNA molecules . . . . . . . . . . . . . . . . . . . 61
xiii
List of Tables
3.1 Dictionary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Use Case - Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Use Case - View Simulation . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 BioLab executable parameters . . . . . . . . . . . . . . . . . . . . . . . 42
7.1 3D Viewer Key Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.3 Test #1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.5 Test #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.7 Test #3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.9 Test #4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.11 Test #5: Real case scenario . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.12 Test #5: Stress-test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.13 Test recap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.14 3D viewer performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.1 Unity Free vs Unity Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.1 Log File Structure - Header . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.2 Log File Structure - Payload . . . . . . . . . . . . . . . . . . . . . . . . 78
xiv
1
Chapter 1
Introduction
The BioLab project consists in a computer software package aimed at biophysicists who
are creating models for DNA-Restriction Enzyme reactions in order to simulate them and
compare the results with the wet-lab observations. There are still open questions in the
literature regarding the interaction between nucleic acids and proteins such as how they
manage to find the reaction sites so efficiently; the DNA-Restriction Enzyme case study
gives 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 BioLab
project because of the lack of simulation software specifically aimed at biophysicists in
their investigation of the laws that govern reactions, motion and other physical properties
of 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 research
center at the University of Marseille (Preto, 2012). They have been studying the reactions
between DNA molecules and restriction enzymes. Trying to create a model for those
type of interactions, they also developed a simulation software for testing the models as
they 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, than
what 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 in
the simulation. The biological entities were in fact treated as point particles instead of
rigid 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 to
stay 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 in
investigating DNA-proteins interactions by taking into account what was supposed to be
wrong 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, we
wanted to have a 3D viewer for analyzing the simulation logs. Such a viewer must be
powerful enough to display any biological entity in the simulated world and to allow the
user 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 than
a revision, of a project that has gone on for many years. At first, the objective was to
develop exclusively the GUI, the tools for the simulation and, more importantly, a 3D
viewer for displaying the simulation logs. Soon enough, however, we realized that there
was more to cover regarding the simulation phase; for instance improving the accuracy of
the collision detection and implementing interactions between biological molecules.
During the development of the BioLab project, several topics were covered and problems
addressed. Regarding the simulator, we had to make our own 3D version of the biological
entities 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 to
implement a system for a dynamic simulation step that increases the accuracy whenever
a collision occurs. As for the user interface and the 3D viewer, we had to build a software
package 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 time
rate of the simulation time. We also addressed the possibility for the user of the software
to adjust the viewer time rate by speeding it up and slowing it down. The results obtained
qualitatively reveal that, when addressing the DNA-Restriction Enzyme interaction sce-
nario, treating the entities as rigid bodies instead of point particles may indeed make the
difference and explain the time mismatch between wet-lab and simulated experiments.
Implementing the orientation of the biological entities and the attractive force between
them led us to positive results in comparison to what previously achieved.
This report is written following the software engineering approach. Each chapter will go
through 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 biological
background needed for understanding our research and project development. We will go
into details about the phenomenon that motivated the development of the software. In
Chapter 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 will
describe the design stage of the project by using specific schematics related to this very
stage such as activity diagrams and sequence diagrams. Then in Chapter 5 we will show
which technologies we decided to use for the development of our project. We will also
give some motivations behind those choices and explain how we intended to use them
in the development process. In Chapter 6 we will use what we produced and described
in previous chapters as a basis for the software development and we will give the reader
an insight into its structure as it has been implemented. Subsequently, in Chapter 7, we
will provide the reader with a final overview of the complete BioLab software suite, with
some screenshots and the results of our tests. Lastly, Chapter 8 will serve to cover what
may come next in the development of this project. In fact, the reader should be aware that
this project is still a work in progress that (if not discontinued) will be carried on also by
other students and researchers. The conclusions will address why we are still far from
completion, but we will also recap how much we have done.
4
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, our
main focus is on two biological molecules: the DNA (Watson & Crick, 1953) (also known
as Deoxyribonucleic Acid) and the Restriction Enzyme (Smith & Welcox, 1970). We
will 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-helix

that (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. The
DNA’s typical double-helix shape originates from two strands coiled around each other;
they contain the nucleobases, which are paired through hydrogen bonds. The nucleobases
are 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 the
cell to make proteins. When the cell divides or when a sequence of DNA is transcribed
into RNA (which in turn is used for making proteins), the strands are uncoiled and the
bases 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 restriction
sites.
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 a
certain nucleotide pattern is read. The site cut by each endonuclease can also be referred
as 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 of
different restriction enzymes have been studied over the years. However, each of them
can be classified into four distinct groups based on where they cleave, with respect to the
recognition 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 (shown
in Figure 2.3) results in two DNA sub-molecules that have complementary tails (called
Sticky Ends). If those ends meet they can bond back together. This principle is also used
in cloning and in genetic engineering.
In the second type of cut, the two DNA strands have no tails, that is, they terminate in a
base 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 nucleotides
until it recognizes a given pattern. In our case study we will often refer to the EcoRI
endonuclease, which is a Type II restriction enzyme. This is an enzyme isolated from the
Escherichia Coli (Meselson & Yuan, 1968). It cleaves the nucleic sequence GAATTC1
and produces two sub-DNA molecules whose sticky ends are composed of AATT and
TTAA respectively. When this occurs we will say that the Restriction Enzyme reacts
with 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 interested
in the process involving the engagement between the molecules: how long does it take for
them to approach each other?
An interesting and non-negligible fact is that in order for the restriction enzyme and the
DNA 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 for
biological molecules, they must interact at some specific sites. A stereospecific reaction
is 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 may
investigate the elapsed time from the beginning of the simulation until the in-situ reaction
takes place. The variables of the system are the concentration of DNA and Restriction
Enzyme molecules in a given volume.
2.4 The Environment
The environment that contains the aforementioned biological molecules is aquatic (both
in wet-lab experiments and in living cells). This environment serves as a spatial boundary
for the molecules contained in it and it may be referred as domain. Anything happening
outside the environment is not relevant for the experiment (and simulation), thus we will
focus 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 an
artificial box surrounding the biological molecules such that they bounce off any time
they collide with it.
2.4.1 Brownian Motion
Since the environment in which the biological molecules are placed is a fluid (i.e. water) at
an 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 water
molecules and move around stochastically according to the Brownian motion. There are
many forces acting upon the entities such as the drag of the fluid and the stochastic force
of the Brownian motion. The latter, described as a Wiener process, could be expressed
as q
2γkB T · N~ ; γ = 6π · Rhyd · η
In the equation above N ~ is a stochastic vector in which each component is a normal

distribution (mean zero, standard deviation one), one independent from the other. kb is
the Boltzmann constant that relates the energy of individual particles with the temperature
of the system. T represents the absolute temperature of the system. η is the water viscosity
when 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 small
scale, 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 to
a 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 effect
that 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 potential
energy of the biological entities; that results in the following relation
1
U (r) ∝ − .
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
c
U (r) = −
r3 + α
as a generic formula in which the two parameters c and α may vary (standard values for
5
those are α = 0.25µm3 , c = 104 KDa·µm
µ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 a
list 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 mind
that the target user might not be a computer scientist. Thus, we wanted to embrace the
keep it simple and essential style whenever applicable both for the user interface and
for the user experience. We expected to be able to give the users as much control over
the simulation as needed; that is, the user must be able to set specific parameters for
customizing each aspect of the simulation. Each simulation was expected to generate at
least an output file for the log that could then be imported in the 3D viewer (or scene
renderer). The viewer had to be straightforward in its use and it should have served the
user 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 viewer
i.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 going
to be used in the rest of the thesis and that have also been used so far. We will explain
those 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 but
rather their meaning related to the project development. Should those words be used in
any 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 Description
Attractive Force (Intracel- This is a force supposed to exist inside the cell between bio-
lular) logical entities. If correctly proven it may be accountable for
a particular attraction between DNA and Restriction Enzyme
molecules.
Biological Entity Entities we use for our simulation purposes (DNA and Restric-
tion Enzyme molecules). Those are used both in simulation
and in the scene rendering.
Bounding Cube Synonym for Enclosed Environment.
Camera Scene entity in the Viewer that captures the images. This can
be 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 given
point (or set of points) of their surfaces.
Cylinder The mesh representing the DNA in our simulation software
and 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 of
the two biological entities that we are using in our simulations.
It reacts when colliding in a specific manner with a Restriction
Enzyme
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 Description
Long-Range Interaction This an electrodynamic force that may be accountable for the
Force attraction between DNA molecules and Restriction Enzymes.
(same as Attraction Force)
Mesh 3D model described by vertices, edges and faces, rendered by
the graphics engine. The DNA’s mesh is a cylinder while the
Restriction 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 must
also wedge.
Player Another term for the 3D viewer
Point Particle Entity Entity treated as a point without spatial extension in the three
dimensions. This is a simplification of the real world counter-
part.
Properties (for biological The data of a biological entity recorded at each step of the sim-
entity) ulation. Those are the velocity vector, the quaternion repre-
senting its orientation, the angular velocity and its position in
space.
Reaction When a DNA and a Restriction Enzyme collide properly they
react. This is the phenomenon in which we are interested in
our simulation.
Rendering Generating the images from the simulation log.
Restriction Enzyme (Abbr. RE). It is an enzyme that cuts a DNA molecule. RE
is one of the two biological entities we are interested in our
simulation.
Rigid Body It is a simplification of a real object which, as opposed to a
point particle, is spatially extended in the three dimensions. It
is subject to translation as well as rotation. Rotation alongside
the 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 the
biological entities represented by their meshes, the camera and
a semitransparent cube representing the enclosed environment.
The user can move around the scene by translating and rotating
the camera.
Term Description
Simulation The whole process in which the biological entities are spawned
inside the virtual environment and their evolution over time
is computed by the simulation software. It ends when all the
DNA molecules react with the Restriction Enzymes.
Simulation Batch A number of simulations executed one after the other with the
same configuration parameters.
Simulation Log The output file generated by the simulation which stores the
main properties of each biological entity for each frame (or
step) of the simulation.
Simulation Parameter The properties that can be set for customizing the simulation
such 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 a
given simulation from its beginning to the end.
Viewer In our suite, the viewer is the piece of software which allows
the 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 the
biological 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 the
software 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 the
end of the development cycle. Following the standard software engineering approach we
relied on the subdivision in functional and non-functional requirements. We will use the
MoSCoW1 method and use a tabular representation.
1Requirements that satisfies one of the following priorities. Must Have, if a requirement must be
satisfied when the software is completed. Should Have, if a requirement should be in the final version of
the software and if it cannot, it must somehow be replaced. Could Have, if a requirement is not strictly
necessary for the success of the software and may be skipped if resources (time, money and so on) for its
development 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 software
because they stress what it must do and what its behavior must be.
Requirement MoSCoW
Simulation 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 behave
when working. Non-functional requirements typically describe the performance of the
system, its accessibility and so on.
Requirement MoSCoW
Soft 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 a
feature which may come in future releases.
2 User Interface
Requirement MoSCoW
Software extensibility through plug-ins Won’t Have
Simulation outputs compatible with file formats of other exist- Could Have
ing software
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- Won’t Have
nology
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) who
operate 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 to
let them either run a new simulation or render a previously computed one. When running
a simulation the user may be asked to configure some parameters or may be given the
option to change them from their default values, if needed. Once the simulation ends, a
log 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 any
angle, and to move back and forth in time to visualize specific moments in the simulation
history.
Use Case Run Simulation

Brief 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 are
listed.
• On Failure - The user is notified that the simulation did not
run correctly.
Flow of Activity
1. 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 Simulation

Brief 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 generated
by the BioLab simulation tool.
Postcondition The viewer frees up the memory used for the rendering.
Flow of Activity
1. 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 BioLab
project. We will give an overview of what choices have been made in the early stages of
the development, so that it would be easy to understand the path we have followed. We
will use some UML diagrams and we will describe them, in order to show the reader how
the software is supposed to evolve in the next stages of its development (as well as in next
chapters).
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 the
hood of the simulation tool. The future development of the algorithm will rely on this
sketch 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 and
the enclosed environment. At this engineering stage we do not know how those files will
be structured; however we definitely know that those files are going to play an essential
role 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 enclosed
environment 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 exceeding
the enclosed environment). When this happens the algorithm should simply reiterate the
procedure 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 each
frame (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-range
interaction 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; if
two or more biological entities are colliding in the right way to trigger the stereospecific
reaction in the current frame, we need to check if after removing the DNA molecule, there
are 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-range
interaction force to every biological entity in their new configuration.
This is repeated all over again until the last DNA molecule still existing in the simulation
reacts 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 which
some preliminary data are stored (i.e. amount of molecules). Thanks to that data it is
possible to instantiate the biological entities.
Afterwards, until the file is completely parsed, the viewer must load the data for each
frame into memory so that it could be displayed.
When no more frames are left, the viewer must render the scene and it must enter the
main 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 to
be developed. There must be four major modules. The front-end is what the user may
interact 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 the
main module where pretty much everything takes place.
At the beginning, the back-end asks the resource loader module to import the biological
entities, which are returned to the main back-end activity. Then it enters the previously
described simulation loop. Here the simulation is computed step by step until the amount
of DNA molecules is zero.
In the meanwhile, the file manager module is asked to output the data to the simulation
log. 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 simulation
tool and the viewer. In this design section we will try to focus on how the data flows from
the 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 output
file, 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 has
to be written: the total frame count, amount of DNA molecules, amount of Restriction
Enzymes, the data of each frame, and so on. Such data must represent the state of the
biophysical 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. It
is pretty straightforward but it will be extended further in the subsequent chapters, as the
engineering 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 began
with the problem analysis through the project design and we are now ready for describing
the technologies that fit our purposes best. We are getting more into the technical and
practical 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 our
BioLab project. We will present them and give the reader as much information as needed
for 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 of
software. The first being the simulator and the second being the 3D viewer for simulation
logs. Since those two systems have distinct behavior and requirements to satisfy, it was
natural to head towards two distinct types of software modules. In both cases, in order to
maintain the focus on our goals, we avoided to reinvent the wheel, thus we searched for
existing libraries that could be used for our purposes. Specifically, we needed a Physics
Engine 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 visualize
in the viewer if no simulation logs were made. The reader, at this point, may come up
with the following question: why have not we embedded the viewer into the simulator so
that each simulation could be rendered as it goes?
The answer to that question is simple. We wanted the simulation to be offline1 by splitting
it from the viewer; in such a way we could obtain a faster simulation software since no
graphical output was needed. Furthermore, each offline simulation generates a log that
may be stored and then analyzed or read (played by the viewer) whenever needed. This
type of simulation also allows biophysicists to run many simulations one after the other
in 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 very
close to the fundamental building blocks. The more one gets to that scale the more other
disciplines 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 specific
spatial 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 software
library called Physics Engine.
A Physics Engine is a software component that takes care of implementing and running
specific routines for physical systems in which bodies or particles are the actors. This
component embeds mathematical and physical models of our world i.e. laws that describe
kinematic 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 continue
with 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 input
and 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 and
developed by a small community which contributes to the project. There are currently
two branches of the software being developed: the stable version 2.82 (which is moving
to 2.83) and the experimental 3.0. Bullet is licensed under the ZLib License2 and free for
commercial 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++ and
it has been developed modularly, thus different aspects of the library may be swapped or
implemented 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 supported
and integrated as a plug-in by many 3D graphics modeling and animating software such
as Blender, Maya, 3D Studio Max.
At version 2.83 Bullet still lacks some important features such as GPU computing; this
feature is going to be implemented in Bullet 3. Thanks to the features previously described
and 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 graphics
the scene from a previously generated simulation log. Any simulation log contains all
the information needed for displaying on screen the biological entities. For our purposes
we needed some software component that could easily render 3D graphics and handle
real-time inputs from the user. The type of component that better suits that description
is a Game Engine, which provides these features and much more (audio, networking,
artificial intelligence, scripting, etc.). Specifically, the Graphics Engine is a subroutine of
a Game Engine that takes care of what concerns graphical input/output. As for graphical
inputs, it must have an importer module for loading specific 3D mesh and data. As for
the outputs, it must expose a set of API for the developers, which gives them the ability
to interact with every single subroutine of the graphics rendering pipeline. From simple
vertex 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 was
not enough on its own for the complete development of the 3D viewer as it lacked a wide
community and ease of use among other things. Thus, we looked for something more
advanced, 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 complete

game 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 one
may 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 problems
and 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#. The
engine is incredibly cross-platform and it relies on renderers specifically written for each
platform 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 on
portable 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 browser
plug-in, for in-browser applications. For the time being, more than 60 videogames and
3D 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 and
we kept on working with that until the end of the development process. As we write this
report 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. Since
there 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. Thanks
to what we achieved in previous chapters we are now ready to give the reader an insight
into the structure of the software as it has been developed and programmed. In fact, we
are moving from schematics and diagram towards the real processes of implementation
and coding.
6.1 Software Suite Architecture
We have documented in previous chapters how the suite is designed. It consists of two
main parts: the first being the simulator and the second being the 3D viewer for rendering
simulation logs. This decision is also based on the tools used for the development and the
programming languages.
For the simulator, as previously discussed in Chapter 5, we decided to rely on Bullet. This
middleware is written in C / C++. Therefore, we decided to develop the BioLab simulator
in C++. Implementing the simulator using the same technologies of the viewer would
have generated an incredible overhead in the program which, in turn, would have slowed
down 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 in
Unity. The user interface is a scene inside the viewer that offers the user some control over
the simulations (by setting the simulation parameters) and lets them choose a simulation
log 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 figure
shows, all the software is packaged inside the GUI1 . The source files are the 3D models for
the biological entities and the bounding cube (that is, the enclosed environment where the
simulation takes place). From those models we generate files compatibles with Bullet (see
Section 6.3). Those files are loaded inside our simulator in order to output a simulation
log file. Also a CSV file log is produced, which will contain all the notable information for
the 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 from
the 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 we
used along the whole development of the BioLab project.
All the software we used was either open-source and free licensed or licensed by the
Microsoft 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 3D
viewer. (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 obtain
our desired biological entities in such a way that they could be both used for 3D rendering
and 3D physics simulation. This was made possible by 3D modeling softwares. In our
case, 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 the
professional community of 3D graphic designers. It is free and open-source, written in
Python, 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 3D
mesh 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 the
other one for the Restriction Enzyme. We wanted those shapes not to be too complex for
this 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 being
the distance between the two circular surfaces) as our DNA simple model; we shaped the
model for the Restriction Enzyme in such a way it had a situ in which the DNA could fit
when properly oriented. Thus, we created a 3D spherical sector. This has been achieved
by composing the model of two specular nearly hemispherical sub-meshes.
Those two models were enough for what concerns the biological entities, however we
soon 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 the
simulation; 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 that
no extra margin should be added around the object. In the second instance, the 3D meshes
collision bounds have been set to Convex Hull (Convex Hull, Accessed: 2014-09-16). A
collision bound wraps a 3D mesh and it is used for collision checking: collisions occur
whenever the collision bounds of two distinct meshes overlap. Convex hull generates a
shrink-wrapped simplified geometry around the mesh. Using Triangle Mesh as collision
bounds would have increased the accuracy in collision detection but it would have also
slowed down the simulation speed. In fact, Triangle Mesh do not approximate the shape of
the meshes, instead the triangles that compose the mesh themselves are used as collision
bounds. This results in collision bounds that match exactly the shape of the 3D object but
it increases the complexity for the collision checking.
Those properties we discussed were needed for the BioLab simulating tool because are
internally used by the Bullet library.
Once the cylinder, the spherical sector and the cube models were ready, we needed to
export them so that they could be used both for the simulation and the viewer. Thanks to
Unity, the game engine we adopted, we could just use the .blend files as they are correctly
processed by the model importer.
Regarding the simulator, we needed very little Python scripting in order to be able to
export the .bullet4 serialized file.
import PhysicsConstraints;
PhysicsConstraints.exportBulletFile("file.bullet")
The output .bullet file contains all the world dynamics for the 3D scene modeled in
Blender.
6.4 Part 1 - Simulation
The BioLab biophysical simulator was entirely developed using the C++ language by
including 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 established
hierarchy 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 have
been 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 body
implementation for the DNA and RE molecules.
The Bullet Collision module provides the user of the library with built-in algorithms and
data structures for the collision detection between physical entities (rigid bodies and soft
bodies).
Figure 6.7: Bullet Modules - Visual Studio Project

Once the project was correctly set up, we could proceed by implementing the algorithm
described in Chapter 4.
In Figure 6.8, we shows a class diagram for the representation of a biological entity in our
project.
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 check
for collisions). Each entity in the scene must be represented by a number of physical
attributes as well as a 3D mesh. The mesh is associated to the biological entity through
the 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-dimensional
vectors, 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 to
each collision with any other object in the scene) and the forces acting upon it, such as
gravity (which is absent in our scenario).
Afterwards, the entities must be located and oriented in space. For our purposes we
wanted 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 Restriction
Enzyme could be spawned, based on the user’s decision.
When the entities are loaded and initialized the simulator can perform the real simulation
phase that is implemented in a while loop fashion. Until some condition (i.e. no more
DNA molecules to react with) is met, the simulator keeps doing the same actions to each
entity in the scene. First of all, the Brownian motion is applied to those entities every 30
steps. This mimics the behavior of such entities when immersed in a fluid. The formula
for the change in velocity for each entity is as follows:
√
∆t · σ · N (0, 1)
v~0 = ~v +
∆t
Mirco Pazzaglia 39
This formula means that the current velocity vector v~0 is updated from its previous value
~v by adding to each of its components a scalar value in function of the time step ∆t, a
user 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 constantly
change the velocity, two other interactions take place during the simulation, one of which
is the biological attractive force that supposedly exists and favors the approach between
DNA 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 energy
c
U (r) = − r3 +α described in Chapter 2, is computed using the following formula:
2
r

F (r) = −3c 3
r +α
It depends on two user defined parameters, α and c, and it is inversely proportional to

the 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 of
mass of the two entities, while the sense is always oriented from the biological entity the
force is applied to, to the other one. This particular type of force (which results from the
long-range interaction explained in Section 2.4.2) only acts upon two paired and distinct
biological entity types such as the DNA molecules and Restriction Enzymes. No two or
more DNA molecules are affected by this force one another (in other words, they are not
cognate partners) and the same holds for two or more Restriction Enzymes. However each
molecule of a given type is pushed towards (and pulls inwards) each and every molecule
to which it is paired, as a cognate partner, in the system.
The last kind of interaction is given by the collisions between molecules themselves and
between molecules and the bounding cube. These calculations are delegated to the Bullet
Library 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 cycle
of 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 the
1
simulation is set to 120 s. 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 sacrificing
the accuracy.
Every time a DNA molecule triggers an in-situ reaction in a Restriction Enzyme, that is
every 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 with
respect to the real wet-lab case scenario. The first simplification is that in reality, the DNA
once reacted with the Restriction Enzyme does not disappear, rather it still floats around
in the intracellular environment. The second simplification concerns the reaction time. In
our 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 search
for the nucleic sequence to be cut by a restriction enzyme has already been covered in the
literature and we are only interested in how and when the DNA and restriction enzyme
molecules engages one another.
When every DNA molecule has reacted with the Restriction Enzyme(s) in the simulated
environment, 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 time
in 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, the
1
step (or frame) duration is set to 120 s. During the initial tests we found, as a novel ap-
proach, that we could obtain a more accurate collision detection and resolution5 if we
were 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 thing
the software does is to save the current physical configuration state. This is possible by
storing each property of the biological entities and the current simulation time. Then
5By resolving a collision we mean all the procedures involved since the first time two entities are
colliding (passing the collision test) until their collision status decays. A collision may be resolved in
several ways, for instance by making the two entities bounce off or by removing one from the scene as it
happens in our case study when they react.
Mirco Pazzaglia 41
the software proceeds by computing the next step of the simulation by applying all the
forces and interactions described. If no collision occurs during this step, the simulation
may continue computing the next step. Otherwise, the system goes one step back in time
by restoring the previously saved state, it sets the time density (frame rate) to a higher
1
resolution (i.e. 1000 s) 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 that
raised it is resolved. Finally, the software reset the frame rate to the standard value and
continue to the next frame.
As a last overview over our implementation of the BioLab biophysical simulator, we
would like to bring to the attention of the reader that we made it possible for the user
of our software to set some simulation parameters in order to make it customizable as
needed. In the following table we recap the parameters currently implemented in the
simulator.
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 cube
is scaled to. For more biological entities this
value 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. Default
value: Same directory of the executable file.
–bulletdir <PATH> Set the directory file in which are contained
the .bullet files for the DNA, RE and bound-
ing cube. Default value: Same directory of
the 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. Default
value: 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 it
collides inelastically. Default value: 0.2
–dnaRestitution <FLOAT VALUE> Set the coefficient of restitution for the DNA
molecules. For a value of 1.0 it collides elas-
tically, for positive values < 1.0 it collides
inelastically. Default value: 0.2
–sigma <FLOAT VALUE> Set the σ value described in the Brownian
motion 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 our
BioLab suite has been realized using the aforementioned Unity Engine. Thus, we used the
tools provided by the Unity IDE. In addition, we intensively used the C# language to write
the custom scripts we needed for implementing the various features we were supposed to
achieve 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 one
scene for the main menu and so on. In our non gaming context, we used two scenes. The
first being the main menu (mainmenu.unity) which we will focus on later, and the second
being 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. To
each 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 there
is 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 those
languages it is possible to import the Unity library and call its methods, use its specific
objects 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 is
possible to play the scene to test if everything works as expected. It is even possible to
edit object properties while the scene is running, but those changes are not permanent and
they 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 describe
in 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 methods
such as:
void Start(){ /* STUB */ }
This method is the first among the others to be invoked when the script is enabled. It is
used for initializing variables and starting procedures.
void Update(){ /* STUB */ }
Once the script has been enabled, the Update method is invoked every time a frame is
going 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 the
user interaction with it. Buttons, dialogs, checkbox, textbox and other GUI elements are
implemented 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() method
we implemented the log file loader and parser. We iterate through each frame stored in
the file and load it into the main memory used by the application. Here we had to take
into account the log file peculiarity such as the variable frame size (see Appendix B). In
the OnGUI() we managed to create an on-screen user interface for providing the user with
information about the simulation and for letting him or her move the time cursor for the
simulation, play/pause the simulation and jump to next/previous collisions. Finally on the
Update() method we could implement the passage of time (both in forward and backward
mode).
The ObjectLabel is an auxiliary script used for displaying a floating text on the rendered
scene. This is used when the user ticks the Show vectors checkbox, in fact it serves for
displaying the vector arrow and magnitude.
Movement is the last script we developed and it is attached to the Main Camera. It binds
a set of keyboard keys to some movement functions. It is worth noting a particular feature
of 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 a
MonoBehaviour implementing class, the IDE lets you edit those values directly from
within itself.
6.5.1 Main Menu GUI
So far we have introduced how we implemented the 3D viewer. Now we are introducing
the GUI which we developed for allowing the user to interact with the simulator software
in a user-friendly fashion.
Since Unity fits well for the graphics interface, we also used it for creating a Main Menu
for 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 does
not need to run a new simulation but they prefer to just render a simulation log already
computed, they can load it. Unity will load the scene1.unity scene which was previously
described 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 which
starts the Bullet simulator by passing to it the customized simulation parameters set in the
GUI. 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 software
suite, that is the simulator and the 3D viewer; in addition, there is also the main menu
which is part of the 3D viewer. Now we will describe how it is possible to compose those
modules 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 Bullet
Simulator 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 and
copying 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 does
not require any high-end expensive hardware, however the simulation is very CPU and
Disk I/O intensive. Therefore, even though it could be run on a low-end computer the
computing time could be significantly longer than when executed on a more efficient
machine. For what concerns the 3D viewer, the following hardware requirements have to
be met:
• Graphics card: DX9 (shader model 2.0) capabilities; generally everything made
since 2004 should work.
• CPU: SSE2 instruction set support.
In addition, the viewer is Disk I/O and memory intensive for what concerns the log file
loading.
The simulator itself may be compiled for Windows, Mac OS X and GNU/Linux and does
not 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 them
in 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 Unity
scene (Section 6.5.1). The user is given the option to customize the simulation parameters
such as the attraction force, the amount of DNA molecules and Restriction Enzyme and
so on and so forth. By pressing the Start Simulation(s) button, the user runs the simulation
batch (which is composed of a number of subsequent simulations as set by the user in the
Batch size field). If the user wants to render an existing simulation file log they may press
the Render Simulation button, and he or she will be prompted for the simulation log to
load. Figure 7.2 shows the Simulator itself. It displays the parameters set for the current
simulation. The console window remains open and the user interface stays idle in the
background 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 finalized
properly. 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 an
existing 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 on
the 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 the
cursor to the right will make the viewer jump to a specific frame in the future while
moving the cursor to the left will make the viewer render frames in the past from the
current position in time. The Play/Pause allows the user to automatically let the time
cursor move at a given rate, forward or backward. The default time speed rate is in 1:1
scale. One second of simulation passes in one second of 3D rendering. The time speed
rate could be decreased and increased by pressing the « and » buttons (or by manually
writing a float value in the textbox between them). By ticking the Reverse checkbox the
time will flow backward. Lastly, the Previous/Next Reaction buttons will help the user to
jump 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. As
one can see, the current time and the frame number are provided to the user as well as
the bounding cube size. In addition, the user may tick two options. The first one enables
the rendering of the bounding cube, the second one shows the velocity vectors for each
biological entity. Lastly there is a Main Menu button which can be used to jump back to
the 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 Description
W Move the camera forward
A Slide the camera to the right
S Move the camera backward
D Slide the camera to the left
Key Description
Up 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 initial
position 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 software
we developed. For each test, we set the parameters for the initial configuration of the
system and ran five simulations in batch; we analyzed the resulting log file and gathered
some data. For each one of the five simulations a test is composed of, we will report the
first reaction time (in seconds) and the last reaction time (in seconds), the log file size (in
MegaBytes) and the simulation elapsed time (in seconds). The reader should note that
the elapsed time refers to the real time the simulation lasted while the first/last reaction
times refers to the in-simulation times. The parameters for the long-range were set to
5
their default values, that is, α = 0.25µm3 , c = 104 KDa·µm
µs2
as described in Chapter 2.
The reader must also be aware that these tests were mainly run for testing the capabilities
and 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 improvement
over 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 the
BioLab 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 box
side to 4, the biological entities are allowed to move freely in the domain; this also avoids
them to either get stuck forever or react immediately. For this reason, the following tests
will 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 use
the 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.95
Last 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.44
Elapsed 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, there
is only one DNA molecule in the scene. The file size and the elapsed simulation time are
relatively 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 just
a bit in order to keep everything under control. We added an extra Restriction Enzyme to
the biological environment.

Domain Side Size 4
Figure 7.10 shows a simulation from this test. The reader may see the two enzymes and
the 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 time
and the log file size. However, as the reader may see in Table 7.5, the mean reaction
time (which also in this case is the same for the first and last reaction times) is nearly
comparable with the test with one Restriction Enzyme. Even though the entities may
interfere one with another in their movement and approach, the DNA molecules gets
higher chances to collide with a reacting site.

First Reaction (s) 102.57 47.98 20.60 51.72 11.88 46.95 35.50
Last Reaction (s) 102.57 47.98 20.60 51.72 11.88 46.95 35.50
File Size (MB) 15.55 7.37 3.16 7.83 1.79 7.14 5.38
Elapsed Time (s) 42.87 21.31 9.03 22.02 4.68 19.98 14.87
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 from
this 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 than
it happens with two endonucleases.

First Reaction (s) 1.60 89.18 121.75 24.19 113.85 70.11 54.19
Last Reaction (s) 2.30 223.49 319.34 177.33 161.284 176.75 115.31
File Size (MB) 0.31 24.06 33.87 16.02 20.19 18.89 13.31
Elapsed Time (s) 0.61 46.98 68.94 33.58 37.48 37.52 24.77
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 DNA
molecules in the scene must react. While in the previous test the single molecule of DNA
had two possibilities for reacting, in this scenario the restriction enzyme must catch one
DNA at a time.
The mean time for the first reaction is greater than that in Test #2 but it is not increased as
much as the other values. In effect, the first reaction time is slowed down by the increased
number of collisions taking place between the entities.
The standard deviation is high for both the reaction times. In effect, the first simulation
could 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 with
both 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 of
the 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 DNA
molecules 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 3D
viewer.
Figure 7.12: Two endonucleases, two DNA molecules
The results obtained in the current test are nearly comparable with the previous test.

First Reaction (s) 27.64 74.04 52.82 42.81 53.21 50.10 16.94
Last Reaction (s) 51.87 194.18 58.71 156.06 93.56 110.88 62.22
File Size (MB) 9.44 29.02 10.78 26.09 17.42 18.55 8.82
Elapsed Time (s) 25.84 42.73 14.84 76.72 50.35 42.10 23.85

Table 7.9: Test #4
The first reaction and last reaction mean times are lower than in Test #3 and, as for the
first reaction time, similar to those of Test #2. In fact, the odds for the entities to react
increases as the type-ratio gets back to 1:1.
Both the simulation software and the viewer perform well; we preserved small time of
simulation and fast rendering times.
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. The
researchers may in fact run tests that resembles the chaotic environment of a cell nucleus
where 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 Enzymes
resulting 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 the
volume 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 in
all, the last reaction did not increase from previous tests. Since the RE-DNA ratio is 2:1,
this example resembles that in Test #2.

First Reaction (s) 1.71 7.37 11.76 9.26 0.76 6.17 4.78
Last Reaction (s) 115.56 162.78 39.54 154.36 122.72 118.99 48.75
File Size (MB) 138.93 188.97 53.03 187.49 143.56 142.40 55.23
Elapsed Time (s) 234.52 312.56 87.22 296.57 235.45 233.26 88.93
Table 7.11: Test #5: Real case scenario
As expected, the simulation time (as well as the maximum frame of the simulation reached
that 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 to
run in their experiments. We know that the software suite can handle such scenarios and
that it worked as expected both efficiently and effectively.
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 table
summarizes the data gathered from the test.
Values
First 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 time
and amount of frames are not that far from previous tests. This can be explained by the
massive 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 case
scenario that the BioLab project aims to address. Table 7.13 summarizes the test mean
values.
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 of
them, it may at first seem that some values are floating too much and that some tests have
similar results irrespectively of their complexity. In fact, the standard deviation of the
tests is high in many instances. This is an expected behavior if one takes into account
that 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. For
this purpose, we actually focused on the three more computationally intensive tests.
Test #5.2 Test #5.1 - Sim #2 Test #4 - Sim #4

Max 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 time
is in the order of seconds. This qualitative result is definitely positive when compared
with previous simulation tools which were off by three orders of magnitude (order of
milliseconds) (Nardecchia, 2012). The physical representation of biological molecules as
rigid bodies may indeed be the key for a more accurate simulation. However, we might
still 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 biophysicists
for real in-lab experimentations that may help us in fine tuning the simulation parameters,
the molecule 3D model and its attributes, and so on.
64
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 of
the BioLab project.
We started giving the reader an overview of the problems we wanted to address. The time
discrepancy between wet-lab experiments and the simulated ones was the motivation that
led us to develop a new kind of simulator which took into account rigid bodies instead of
point particles.
We showed how we started from this simple idea and from previous works, to develop a
new software, that practically became a complete suite of a 3D viewer and a simulation
tool. This is all packaged in a graphical user interface that aims to ease the interaction
with the software from the user’s (biophysicists) point of view.
We showed how we proceeded, in software engineering terms, from the bare concepts to
the requirements, from the design to the actual implementation.
Finally, we showed where we got in the development process with our current version
of the software suite and we described the results we obtained. Both the simulator and
the 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. The
3D 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 order
of 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 the
biological molecules and the implementation of the long-range attractive force between
cognate molecules seems to produce the expected qualitative results. For better and more
accurate quantitative results, we will hand the software to biophysicists and, by working
side 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 to
continue to work on it, enhancing the already existing features and adding new ones. In
the remaining part of the report we will try to focus on what we would like to add to the
software 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 cylinder

and the Restriction Enzyme as a spherical sector. Even if this is a step further from
the 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 complexity
to the simulation at first, but sooner or later it will be necessary to get as close to
the reality as possible. For instance, the DNA molecule may be represented by a
complex 3D mesh resembling its typical twisted-ladder shape.
• Sophisticated collision detection algorithms. So far, we relied on the collision

detection algorithms provided by Bullet. However we are aware that we could
probably get more efficient and effective collision detection by searching for other
type of algorithms. This is especially true for the in-situ collision when moving
on more complex 3D shapes. In our current release, the check for the reaction is
hardcoded based on the geometrical representation of the DNA and RE. In fact, it
is quite simple: when the distance between a point along the surface of the cylinder
and the center of the spherical sector is less than the radius of the latter, we are
geometrically sure that the DNA entered the site. However, this is not as generic
as possible especially if the simulation tool is working with many different types of
meshes.
• Open to new type of biological entities and scenarios. When we started this
project 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 biological
framework for investigating many problems in which a simulation tool and our 3D
viewer may help. This could be possible by extending the suite with plug-ins or
modules to dynamically load new type of biological entities inside the scene. Also,
the scene may become more complex than a simple bounding cube wherein the
simulation takes place. Obstacles may be added, or tissues may be simulated. It
would be amazing to be able to reproduce real biological scenarios as accurate as
possible (i.e. neuron cells, heart cells, and so on and so forth).
• Improved simulation parameters and forces editor. We already made possible

for the user to customize each simulation with a number of parameters as discussed
in Chapter 6. Anyway, there are a large number of parameters which are hardcoded
in 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 modularly
as possible, formulae to be used for describing attractive/repulsive forces between
molecules 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 technique
would definitely speed up the whole process of simulation (for instance by using
CUDA, OpenCL or DirectCompute). Since we use Bullet as Physics Library we
are definitely waiting for the next 3.0 release that will feature a 100% GPU rigid
body 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, by
setting 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 the
aesthetics of the viewer. For instance, achieving better transparencies effects; we
would also like to improve the lighting in the scene, with movable lights and better
light effects. Furthermore, features for highlighting important collisions and an auto
zoom-in to a current reacting sites should be added.
• Improve the user interaction with the viewer. We would like to collect feedback
on 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 elements
in the 3D scene without harming the ease of use.
• Stereoscopic mode. We would like to be able to add a stereoscopic rendering

feature. The stereoscopy would allow any user wearing a proper glass to perceive
the scene as if it were really in three dimensions, giving the feeling that the images
are floating outside the screen.
• Virtual reality. This would be a step further than the stereoscopic rendering. We
are 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 it
from the inside. Moving their head they could explore the scene as if they were
inside of it.
• Buffered reader. In our BioLab prototype when a file log is loaded into the 3D
viewer, it is read from beginning to the end, and stored into the computer main
memory. Even though this is good for moving along the time of the simulation
seamlessly, it has quite a drawback both in loading times and in memory usage. In
order to overcome to this issue, it would be smart to implement in future releases
of the software, a buffered reader for log files. This allows the program to read
just chunks of data in the time proximity of the current frame displayed. When the
player approaches the upper or lower bound of the chunk, a new chunk should be
preloaded and swapped in when it is the right moment. An incomplete version of
this feature is in development as a standalone application (not integrated with the
software 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 completely

cross-platform, that is, it may run on many different operating systems (namely
Windows, 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 Windows
operating system. We would like to get rid of those and obtain a pure cross-platform
software suite.
70
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.
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 doctoral
dissertation). 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 of
Camerino. (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.
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.
74
75
Appendix A
Unity Free vs Unity Pro
Many of the contents in Unity are specifically aimed at videogame development. Such
features are not useful for our purposes. The following table is an excerpt of the main
feature available in Unity and in Unity Pro.
Feature Free Pro

Generic
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 Pro

3D 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. The
Pro 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 is
written in binary mode, thus, knowing its structure it is possible to seek for a specific
simulation frame or data. First of all, I will introduce the reader with the parameters that
are 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 Size

Bounding 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 amount
of total frames the simulation is composed of. Following Frame Count there are as many
MaxDNAFrame as the initial amount of DNA molecules D. This allows the system to
work with frames which size changes over time. In fact, when a simulation with more than
one DNA molecules is run, it may happen that the amount of DNA molecules reduces as
the Enzymes reacts with them. Using a static sized frame would consist in a waste of space
and time. Thus, whenever a DNA molecules reacts (that is, disappear from the simulation
scene), the frame time is written in its MaxDNAFrame cell allowing the system to work
with one DNA molecule less in future frames. The header size grows with the number of
initial 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 log
file.
Data Type Size

Time 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 DNA
in 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. The
position, 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
hx, y, zi. The orientation is represented as a quaternion in the form hx, y, z, wi. Colli-
sion is a boolean value used for marking the current frame if a collision is occurring at
that point in time. The size of a given frame is calculated as follows: f rame(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 frame
in 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;
}
Reykjavík University
Menntavegi 1
101 Reykjavík, Iceland
Tel. +354 599 6200
Fax +354 599 6201
www.reykjavikuniversity.is
ISSN 1670-8539

University of Camerino
Piazza Cavour 19 / f
62032 Camerino (MC), Italy
P.IVA: 00291660439
CF 81001910439
Tel. +354 599 6200
Fax +354 599 6201
http://www.unicam.it/

Simulation and Visualization of A 3D Biological Environment. Dna and Restriction Enzyme Case Study

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Simulation and Visualization of A 3D Biological Environment. Dna and Restriction Enzyme Case Study

Uploaded by

Copyright:

Available Formats

SIMULATION AND VISUALIZATION OF A 3D

BIOLOGICAL ENVIRONMENT. DNA AND

M.Sc. RESEARCH THESIS

Research thesis submitted to the School of Computer Science

Research Thesis Committee:

Luca Tesei, Supervisor

List of Tables xiii

3 Requirements and Specifications 11

7 Applications and Results 49

A Unity Free vs Unity Pro 75

B Simulation Log Structure 77

2.1 The structure of the DNA molecule . . . . . . . . . . . . . . . . . . . . . 6

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

4.1 Simulation - Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Bullet Physics - Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.1 Software Suite Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.14 Unity Engine - Build Menu . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1 BioLab Screenshot 1 - Main Menu . . . . . . . . . . . . . . . . . . . . . 49

3.1 Dictionary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

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

7.1 3D Viewer Key Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 54

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

B.1 Log File Structure - Header . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.1 Deoxyribonucleic Acid Molecule

The DNA is a famous biological molecule whose structure is shaped as a double-helix

2.2 Restriction Enzyme

A restriction enzyme (also known as restriction endonuclease or simply endonuclease)

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

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

2.3 Problem Analysis: Stereospecific Reaction

Figure 2.4: DNA-Restriction Enzyme interaction

2.4 The Environment

2.4.1 Brownian Motion

In the equation above N ~ is a stochastic vector in which each component is a normal

2.4.2 Long-Range Interaction

Requirements and Specifications

3.1 Dictionary of Terms

the intended meaning.

3.2.1 Functional Requirements

3.2.2 Non-Functional Requirements

3.3 Use Case

Figure 3.1: Use Case Diagram

Use Case Run Simulation

Table 3.4: Use Case - Run Simulation

Use Case View Simulation

Table 3.5: Use Case - View Simulation

4.1 Activity Diagram

Figure 4.1: Simulation - Activity Diagram

Now we will go into the details of each step of the diagram.

Figure 4.2: 3D Viewer - Activity Diagram

4.2 Sequence Diagram

Figure 4.3: Simulation - Sequence Diagram

4.3 Software Integration

Figure 4.4: Project Suite Flowchart

5.1 Physics Engine

5.1.1 Bullet Physics Engine

Figure 5.1: Bullet Physics - Logo

Physics Simulation, Accessed: 2014-09-16), (Erwin et al., Accessed: 2014-09-16).

5.2 Graphics Engine

Figure 5.2: Unity - Logo

Unity (Unity - Game Engine, Accessed: 2014-09-16) is a combination of a complete

Figure 5.3: Unity Engine - Asset Store

Figure 5.4: Unity - IDE