Biomod/2011/Caltech/DeoxyriboNucleicAwesome/Simulation: Difference between revisions
(Updating code to current revision) |
|||
(4 intermediate revisions by the same user not shown) | |||
Line 37: | Line 37: | ||
At 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 cargo-bearing (one-cargo one-goal) and a purely random-walk mode. The former has cargo positions corresponding to our particular origami pre-programmed 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 of all walkers positions over time, a log reporting when cargos were picked up and dropped off, a count of the number of steps the simulation took, and if desired, a move of the random walk. This function is utilized by separate cargo-bearing and random-walk data collection programs that call the function many times over a range of parameters. | At 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 cargo-bearing (one-cargo one-goal) and a purely random-walk mode. The former has cargo positions corresponding to our particular origami pre-programmed 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 of all walkers positions over time, a log reporting when cargos were picked up and dropped off, a count of the number of steps the simulation took, and if desired, a move of the random walk. This function is utilized by separate cargo-bearing and random-walk data collection programs that call the function many times over a range of parameters. | ||
The function code (saved as | The function code (saved as randomWalkFunctionGeneric.m): | ||
<span class="_toggler-codeA">Toggle Code</span> | <span class="_toggler-codeA">Toggle Code</span> | ||
<div class="codeA" style="display:none; | <div class="codeA" style="display:none; | ||
Line 460: | Line 460: | ||
==Random-Walk Simulation== | ==Random-Walk 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 fluorophore-quencher 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: <span class="_toggler-codeB">Toggle Code</span> | 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. [[Image:Caltech5000iter0ErrorRRWideLinearTrack.jpg | thumb | 300 px | right | A plot of the number of steps (on an average over 5000 iterations) it takes a walker to random walk from any point on the origami to the irreversible track at one end. This test was done assuming a 0% error rate, on the 3-track-wide linear random walking playground that we are using to investigate random walking (in a pseudolinear environment).]]Because this fluorescence is changed by a fluorophore-quencher 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: <span class="_toggler-codeB">Toggle Code</span> | ||
<div class="codeB" style="display:none; | <div class="codeB" style="display:none; | ||
border: 1px dashed rgb(0, 0, 0); | border: 1px dashed rgb(0, 0, 0); | ||
Line 477: | Line 477: | ||
% 20110701: Updating to use new, updated randomWalkFunction | % 20110701: Updating to use new, updated randomWalkFunction | ||
% 20110707: Updated to use new error-allowing randomWalkFunction | % 20110707: Updated to use new error-allowing randomWalkFunction | ||
% 20110719: Updating to use new and hopefully much faster | |||
% randomWalkFunctionGeneric | |||
%% Dependency: makes calls to randomWalkFunctionGeneric.m | |||
%Layout modes: | |||
layoutMode = 4; | |||
if layoutMode == 4 | |||
yMax = 15; | |||
xMax = 9; | |||
elseif layoutMode == 5 | |||
yMax = 16; | |||
xMax = 8; | |||
else | |||
'Layout not yet implemented.' | |||
return | |||
end | |||
iterations = 500; %Test each case of random walk this # times | |||
iterations = | |||
averages = zeros(xMax, yMax); %Init'ing this | averages = zeros(xMax, yMax); %Init'ing this | ||
trash = []; %Trash storing variable | trash = []; %Trash storing variable | ||
%Cycle over whole area, starting the walker at each position | %Cycle over whole area, starting the walker at each position | ||
%and seeing how long it takes it to get to the stop position | %and seeing how long it takes it to get to the stop position | ||
matlabpool( | matlabpool(3) | ||
for x=1:xMax | for x=1:xMax | ||
for y=1:yMax | for y=1:yMax | ||
temp = zeros(iterations, 1); | temp = zeros(iterations, 1); | ||
parfor i=1:iterations | parfor i=1:iterations | ||
[trash, trash2, temp(i)] = | [trash, trash2, temp(i), trash3]=randomWalkFunctionGeneric(... | ||
10000, | 10000, layoutMode, [x, y], 1, 0, 0.1, 0, 0, 1, 1); | ||
end | end | ||
stdDev(x, y) = std(temp); | stdDev(x, y) = std(temp); | ||
Line 502: | Line 513: | ||
matlabpool close | matlabpool close | ||
</syntaxhighlight></code></div> | </syntaxhighlight></code></div> | ||
===Results=== | ===Results=== | ||
Results of the bulk data collection at right show that the average random-walk duration, and thus the time for <math>(fluorescence_{initial} - fluorescence_{current})</math> to reach some standard level, increases with distance, though it changes less significantly the farther out one gets. | Results of the bulk data collection at right show that the average random-walk duration, and thus the time for <math>(fluorescence_{initial} - fluorescence_{current})</math> to reach some standard level, increases with distance, though it changes less significantly the farther out one gets. We can also use a similar simulation (run instead with tracks that don't continue past the start location of the walker, an arrangement which we have found to behave more like a linear track) data to generate approximate half-completion times, which we can compare with the SPEX results of the same random walk to both estimate the amount of time it takes the walker to perform a single branch migration on our origami, and to see if whatever our walker is doing on origami is looking like a random walk, as compared to a repeated jumping across or between origami platforms (whose half-completion times for this test would presumably not depend on the track length at all). That data is detailed on the SPEX results page. | ||
==Cargo Sorting Simulation== | ==Cargo Sorting Simulation== | ||
This simulation investigates both the overall tractability of our sorting problem, and the degree to which it can be parallelized via the addition of multiple walkers onto a single origami. It runs by making repeated calls to randomWalkFunction in its cargo-bearing mode, testing the number of steps it takes to sort all five cargos to respective goals over a range of number of cooperating walkers: <span class="_toggler-codeC">Toggle Code</span> | This simulation investigates both the overall tractability of our sorting problem, and the degree to which it can be parallelized via the addition of multiple walkers onto a single origami. [[Image:250iters0ErrorCargoSort.jpg | thumb | 300px | right | A plot of the number of steps (on an average over 250 iterations) it takes n walkers to sort all five cargos to respective goals on a perfectly formed 16x8 track, as detailed above. The jaggedness in the curve is a result of the large spread of results for any given test.]] It runs by making repeated calls to randomWalkFunction in its cargo-bearing mode, testing the number of steps it takes to sort all five cargos to respective goals over a range of number of cooperating walkers: <span class="_toggler-codeC">Toggle Code</span> | ||
<div class="codeC" style="display:none; | <div class="codeC" style="display:none; | ||
border: 1px dashed rgb(0, 0, 0); | border: 1px dashed rgb(0, 0, 0); | ||
Line 552: | Line 562: | ||
plot(averages) | plot(averages) | ||
</syntaxhighlight></code></div> | </syntaxhighlight></code></div> | ||
(Note: this code is now obsolete (as it relies on an obsolete version of the randomWalkFunction script), and may be rewritten in the future. This should not, however, impact the validity of this code's results. | |||
===Results=== | ===Results=== | ||
While a single walker takes over a thousand steps to complete the sorting challenge, the addition of even a single walker vastly decreases the completion time, and additional walkers decrease it further, until a critical point is reached where the walkers are more getting in the way than helping with the sorting process. This is visible in the positive slope visible in the diagram at right that starts at around the 20 walker point. | While a single walker takes over a thousand steps to complete the sorting challenge, the addition of even a single walker vastly decreases the completion time, and additional walkers decrease it further, until a critical point is reached where the walkers are more getting in the way than helping with the sorting process. This is visible in the positive slope visible in the diagram at right that starts at around the 20 walker point. | ||
{{Template:DeoxyriboNucleicAwesomeFooter}} | {{Template:DeoxyriboNucleicAwesomeFooter}} |
Latest revision as of 15:57, 31 October 2011
Friday, April 19, 2024
|
SimulationsOverviewOur proposed sorting mechanism depends very heavily on a particular random-walking 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 SPEX experiments, a one-dimensional track is easy to construct, and will behave like a standard 1D random walk, showing an average translation on the order of [math]\displaystyle{ n^{\frac{1}{2}} }[/math] 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 one-dimensional 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 one-cargo, one-goal 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 cargo-bearing (one-cargo one-goal) and a purely random-walk mode. The former has cargo positions corresponding to our particular origami pre-programmed 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 of all walkers positions over time, a log reporting when cargos were picked up and dropped off, a count of the number of steps the simulation took, and if desired, a move of the random walk. This function is utilized by separate cargo-bearing and random-walk data collection programs that call the function many times over a range of parameters. The function code (saved as randomWalkFunctionGeneric.m): Toggle Code Examining Errors in OrigamiThis code can be used to generate diagrams like those below, visualizing the mobility of the walker. One immediate question is the vulnerability of this layout to errors in the laying of track. We investigate this by, when generating the track layout in the beginning of randomWalkFunction, introducing a small (specified by input) percent chance that any single probe will be omitted. Error rates at around 10% are bearable; error rates greater than that, however, are catastrophic, causing walkers to become permanently trapped in small sections of the track field. Random-Walk 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 fluorophore-quencher 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]\displaystyle{ (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: Toggle CodeResultsResults of the bulk data collection at right show that the average random-walk duration, and thus the time for [math]\displaystyle{ (fluorescence_{initial} - fluorescence_{current}) }[/math] to reach some standard level, increases with distance, though it changes less significantly the farther out one gets. We can also use a similar simulation (run instead with tracks that don't continue past the start location of the walker, an arrangement which we have found to behave more like a linear track) data to generate approximate half-completion times, which we can compare with the SPEX results of the same random walk to both estimate the amount of time it takes the walker to perform a single branch migration on our origami, and to see if whatever our walker is doing on origami is looking like a random walk, as compared to a repeated jumping across or between origami platforms (whose half-completion times for this test would presumably not depend on the track length at all). That data is detailed on the SPEX results page. Cargo Sorting SimulationThis simulation investigates both the overall tractability of our sorting problem, and the degree to which it can be parallelized via the addition of multiple walkers onto a single origami. It runs by making repeated calls to randomWalkFunction in its cargo-bearing mode, testing the number of steps it takes to sort all five cargos to respective goals over a range of number of cooperating walkers: Toggle Code(Note: this code is now obsolete (as it relies on an obsolete version of the randomWalkFunction script), and may be rewritten in the future. This should not, however, impact the validity of this code's results. ResultsWhile a single walker takes over a thousand steps to complete the sorting challenge, the addition of even a single walker vastly decreases the completion time, and additional walkers decrease it further, until a critical point is reached where the walkers are more getting in the way than helping with the sorting process. This is visible in the positive slope visible in the diagram at right that starts at around the 20 walker point.
|