Difference between revisions of "Biomod/2011/Caltech/DeoxyriboNucleicAwesome/Simulation"
(Added code) 
(Detailing random walk simulation) 

Line 164:  Line 164:  
==RandomWalk Simulation==  ==RandomWalk Simulation==  
+  The data we need from this simulator is a rough projection of the fluorescence response from our test of 2D random walking, which should change based on the starting location of the walker. Because this fluorescence is changed by a fluorophorequencher interaction upon a walker reaching its irreversible track, in the case where we plant all of the walkers on the same starting track, the time it takes <math>(fluorescence_{initial}  fluorescence_{current})</math> in the sample to reach some standard value should be proportional to the average time it takes the walkers to reach the irreversible substrate. As this 'total steps elapsed' value is one of the outputs of our simulation function, we can generate a map of these average walk durations by running a large number of simulations at each point on the origami and averaging the results:  
+  <code><pre>  
+  %%% Random walk bulk simulation that  
+  %% runs a battery of tests and plots the results  
+  %% to see how long random walks take on average to complete  
+  %% based on distance from goal / platform size  
+  % Gregory Izatt & Caltech BIOMOD 2011  
+  % 20110616: Initial revision  
+  % 20110623: Updating documentation a bit  
+  %% Dependency: makes calls to randomWalkFunction.m  
+  
+  iterations = 2500; %Test each case of random walk this # times  
+  xMax = 16; %Scale of platform for test  
+  yMax = 8;  
+  stopPos = [16, 8]; %Stop position  
+  averages = zeros(xMax, yMax); %Init'ing this  
+  trash = []; %Trash storing variable  
+  %Cycle over whole area, starting the walker at each position  
+  %and seeing how long it takes it to get to the stop position  
+  matlabpool(4)  
+  for x=1:xMax  
+  for y=1:yMax  
+  temp = zeros(iterations, 1);  
+  parfor i=1:iterations  
+  [trash, temp(i)] = randomWalkFunction(xMax, yMax, 1000000, ...  
+  1, [x, y], stopPos, 0, 1);  
+  end  
+  stdDev(x, y) = std(temp);  
+  averages(x, y) = mean(temp)  
+  end  
+  end  
+  matlabpool close  
+  </pre></code>  
{{Template:DeoxyriboNucleicAwesomeFooter}}  {{Template:DeoxyriboNucleicAwesomeFooter}} 
Revision as of 10:20, 23 June 2011
Wednesday, November 22, 2017

SimulationsOverviewOur proposed sorting mechanism depends very heavily on a particular randomwalking mechanism that has not been demonstrated in literature before. The verification of this mechanism is thus a vital step in our research. Verification of the random walk in one dimension is fairly straightforward: as discussed in <LINK TO THE EXPERIMENTAL DESIGN SECTION>, a onedimensional track is easy to construct, and will behave like a standard 1D random walk, showing an average translation on the order of Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle n^{\frac{1}{2}}} after n steps. Thus, we should expect the time it takes to get to some specific level of fluorescence to be proportional to the square of the number of steps we start the walker from the irreversible substrate. If we can, in an experiment, record the fluorescence over time when the walker is planted at different starting points and show that that fluorescence varies by this relationship, we'll have fairly certainly verified onedimensional random walking. Our particular case of 2D random walking, however, is not as easily understood, especially considering the mobility restrictions (ability to move to only 4 of 6 surrounding locations at any particular time) of our particular walker. As a control for the verification of 2D random walking, though, we still need to get an idea how long the random walk should take, and how that time will change as we start the walker at different points on the origami. We opt to do this by simulating the system with a set of movement rules derived from our design. We also use the same basic simulation (with a few alterations and extra features) to simulate our entire sorting system in a onecargo, onegoal scenario, to give us some rudimentary numbers on how long sorting should take, with one vs multiple walkers. Basic parameters and assumptions:
MATLAB CodeAt the core of the simulation is a function which runs runs one random walk on an origami of specified size. It can run in both a cargobearing (onecargo onegoal) and a purely randomwalk mode. The former has cargo positions corresponding to our particular origami preprogrammed and starting with multiple (specified by user) walkers at random locations on the origami, and terminates when all of the cargos have been "sorted" to the goal location (the x axis). The latter runs one walker starting at a specified location, and terminates when that walker reaches the specified irreversible track location. The function returns a log reporting when cargos were picked up and dropped off, and a count of the number of steps the simulation took. This function is utilized by separate cargobearing and randomwalk data collection programs that call the function many times over a range of parameters. The function code (saved as randomWalkFunction.m):
RandomWalk SimulationThe data we need from this simulator is a rough projection of the fluorescence response from our test of 2D random walking, which should change based on the starting location of the walker. Because this fluorescence is changed by a fluorophorequencher interaction upon a walker reaching its irreversible track, in the case where we plant all of the walkers on the same starting track, the time it takes Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://api.formulasearchengine.com/v1/":): {\displaystyle (fluorescence_{initial}  fluorescence_{current})} in the sample to reach some standard value should be proportional to the average time it takes the walkers to reach the irreversible substrate. As this 'total steps elapsed' value is one of the outputs of our simulation function, we can generate a map of these average walk durations by running a large number of simulations at each point on the origami and averaging the results:
