MTtbox

From Flower Development, E Coen , Cell & Developmental Biology Department - JIC UK

Jump to: navigation, search

This page gives a brief guide to MTtbox and its associated software. It also provides information on how to recreate the figures in our paper.

Contents

Microtubule Toolbox (MTtbox)

MTtbox is our own software for modelling alignment formation of microtubules, developed in MATLAB. Modelling in MTtbox is mostly done through editing of the interaction function, which is a defined area of code in which microtubule states can be checked and altered. This approach (largely) abstracts the modeller from the mechanics underlying the simulator, allowing them to concentrate on the scientific concepts they're investigating.

To run MTtbox in MATLAB, you must have the code, which you can download from here:

Media: MTtboxVersion1.zip

MTtbox also has a lot of dependencies in GFtbox, which is available here:

http://sourceforge.net/p/gftbox/home/

MTtbox also requires your MATLAB license to include the Statistics and Machine Learning Toolbox.

Once both have been added to your MATLAB path, it can be started by entering the following into the command window:

MTtbox

This will display the MTtbox modelling environment:

File:Screen_Shot_2017-07-04_at_12.01.19.png

MTtbox Graphical User Interface. Note: This is after a project is loaded and run for several iterations

You can start a new project (File > New Project) and a default or "boiler plate" project will be created. By default, the model will create microtubules but it will not be very fancy. Alternatively, you can select any of the models used in our publication from the File > Sample Projects menu in MTtbox. Additionally, there is a very basic model (MT_simplified_20171004) with shallow angle zippering, steep angle catastrophe, spontaneous catastrophe and rescue, which may be an easier starting point for familiarising yourself with MTtbox. Also, you can open an existing model (File > Open Project) and run that instead.

Simple projects will consist of a project directory, an interaction function (a .m file with the same name as the project directory) and a similarly named .mat file containing a lot of simulation configuration data. During a simulation, the data within the mat file is loaded into MATLAB by MTtbox. This data is stored in a structure called data, which is passed between most functions in MTtbox to give them access to (for reading or writing to) the current state of the simulator. There are fields named userdata within the data structure which are specifically for the user to edit, as to not interfere with other critical data. The project.mat file is never updated with the up-to-date data structure information, but a save stage command can be issued to create a new .mat file with updated information. Such a stage file can be useful for resuming a simulation.

Project directories may also contain files like exp_params-170119-102647-0644.mat, which are created when cluster jobs are submitted (See the Cluster section below), and a directory called runs which contains the output from simulations run locally or downloaded from the cluster.

File:Screen_Shot_2017-07-04_at_12.01.43.png

Example Project Directory

Running a Simulation on your PC

Simulations can be run in the GUI on your PC (or on the cluster, if you are at UEA or you adapt the cluster code for your own institution. See the Cluster section on this page).

To run a simulation in the GUI, you can click Run For, which will execute the number of steps specified in the adjacent text box. Alternatively, you can click Step, which will execute one step. When a simulation is running, clicking the Stop button will halt the simulation after the current iteration has completed. The default viewpoint for models is a 3D view from a strange angle - you may prefer to click the ViewTop button after a few iterations in order to view the simulation from the top down. Running simulations in this way is great for testing models as you develop them or just to see the result of running a model.

If you want to look at long term simulations, you may wish to run in "silent mode" instead of the GUI. This procedure is similar to running a model on a cluster, as discussed in the Cluster Section. Running in silent mode ensures that all necessary simulation outputs are generated and in the same format as they are produced by the cluster, which helps with visualising model outputs. Running in silent mode requires you to call MTtboxCommandGrace, as in the following example:

MTtboxCommandGrace('Name','MT_circle_20161208','N_steps',[0:200:40000],'VIEW_STEPS',200,'ORTHO_TOP',1,'useModelCase',10,'ExpID','Test0002')

In this example, MTtboxCommandGrace is called with a number of parameter pairs, consisting of an argument name (the first parameter in the pair) and a value (the second parameter). The command above runs a particular model case from our paper, and the parameters have the following meaning:

  • Name: the name of the project directory (e.g. MT_circle_20161208). The project must be in the current working directory in MATLAB.
  • N_steps: A MATLAB vector determining the length of the simulation in steps, and when screen captures are saved (e.g. [0:200:40000] means run until 40,000 iterations, saving images every 200 iterations).
  • VIEW_STEPS: A number telling the software when to update the simulation display. This should be set according to the interval defined in N_steps (e.g. N_steps = [0:200:40000], VIEW_STEPS = 200)
  • ORTHO_TOP: Must be set to 1 in order for screen captures to be of a top-down simulation view, instead of a 3D view.
  • useModelCase: a number specifying an index to the useModelCase parameter in the interaction function. If you look at the possible useModelCase values in the interaction function, you will see a range of model case names (e.g. a, b, c etc). Further on in the code, you will see that each case corresponds to a set of indexes for other parameters. In Supplementary File 2 of Newman et al 2017 (Pending review!), you will find the correspondence between the model cases and the figures in the paper.
  • ExpID: A unique identifier for a simulation run, which determines the name of the folder the run is stored in. I recommend at least four alphabetic characters followed by at least 3 numeric characters (e.g. Test0001)

A side point is that MTtboxCommandGrace is actually much more powerful than this example suggests (See the Cluster section on this page for more details). For example, just like the 'useModelCase' parameter specifies an index of the useModelCase parameter in the interaction function, you could instead specify other parameters and their indexes when calling MTtboxCommandGrace (e.g... 'spontaneousNucleationRate',2 ...). However, it's not a good idea to specify both a useModelCase index and indexes for other parameters, as you won't be sure which parameters are taking precedence. Also note that indices of parameters are set prior to selecting a model case, after which the parameters indexes are modified by the case. Practically, this means that unless a model case specifies indices for all parameters, changing the index of a parameter outside of the model case would result in a model case running with different/undesirable parameters - To avoid this situation, you could specify the index of every single parameter in each model case, or don't change parameter index, or be sure to change them back before running a model case.

Interaction function

The interaction function can be edited by clicking the Edit button on the MTtbox GUI. Alternatively, it can be opened in the MATLAB editor in the way that any script can be.

Broadly speaking, there are three user-editable parts to the interaction function: Parameters, The Model and Stats. There are also a number of parts which are best left alone, and which are clearly signposted.

Parameters

The top few hundred lines of code in the interaction function are concerned with cluster operation and parameter specification. Parameters are specified as follows:

data.userdata.ranges.globalCatastropheProb.range{1} = 0.0000;
data.userdata.ranges.globalCatastropheProb.range{2} = 0.0015; % Directly specified rate
data.userdata.ranges.globalCatastropheProb.range{3} = 0.0090; % Indirectly specified rate
data.userdata.ranges.globalCatastropheProb.index = 1;

Where the range indices specify possible preset values and the index field selects which range value to use. The result of the code above is the creation of a variable named globalCatastropheProb which contains the value 0.0000. Other values can be specified by changing the index field, changing or adding new range values.

This mechanism for changing model parameters is only to be used when a model is at step 0, i.e. a simulation has not been run or it has but the model has been reset to step 0. Changing the parameter values at later iterations will not have no effect, unless the simulation is restarted.

Our paper contains a number of figures showing the output from various simulations of MTtbox models. We use the term 'case' to mean a unique configuration of a model that produces a main or supplementary figure. In total, there are 26 model cases across 7 models. Four of the model cases have a possible sub model configuration. Model cases are defined and selected as follows:

data.userdata.ranges.useModelCase.range = {'NONE','C'};
    data.userdata.ranges.useModelCase.index = 2;
    data.userdata.ranges.useSubmodelCase.range = {1,2,3,4,5,6,7,8,9,10,11};
    data.userdata.ranges.useSubmodelCase.index = 1;
end

ranges =  data.userdata.ranges;
modelCase = data.userdata.ranges.useModelCase.range{data.userdata.ranges.useModelCase.index};
switch modelCase
    case 'NONE'
        % DO NOTHING
    case 'C', ranges.useRescueProfile.index = 1; ranges.edgeNucleationType.index = 1;
    otherwise %do nothing
end


The index for useModelCase selects the model case. The indices for the parameter ranges as they appear in the interaction function constitute the default parameter values for a given model. Model cases (above) then update a subset of these indices.

When submitting jobs to the cluster (See Cluster section), it is necessary for the useModelCase index to be kept at 1 (i.e. case 'NONE') and for the model case to selected by way of the cluster job submission software. Specifying 1 model case in the interaction function and another in the cluster software will result in the interaction function model parameters being selected first, followed by the parameter values for the case loaded by the cluster, which could result in unwanted parameter selection if both cases don't alter the same parameters.

A good way to try new model configurations is to add a new model case and, if necessary, add new parameter ranges. A bad way is put actual numbers in the code as and when you need them.

There is also a section which starts:

if data.iterations==0
     ...
else

Everything between these lines is also user editable. You will see that some of the most fundamental range parameters declared earlier are passed into the mtSETMTprops function, which is actually how the model knows to use them. There are also some parameters which we need to specify but are extremely unlikely to change so they do not have associated range variables (e.g. microtubule thickness). This is also where we initialise variables that will store statistics information.

The Model

The middle most portion of code, following the else above, is where microtubule behaviour is altered according to the state of the simulator. Basically, this is the actual model.

Firstly, before the microtubules are processed, a subset of the statistics variables defined previously are set to 0. This is for stats like the number of spontaneous catastrophes per iteration.

The main body of the model is a loop which iterates through each microtubule in the simulation:

for i_MT=1:length(data.working.dyn.microtubules.Org)
     MT=data.working.dyn.microtubules.Org(i_MT);
     ...
end

Within that loop, most of our models have the following structure:

1) Handle new microtubules - adjust relevant stats (e.g. number of nucleations) and record information that will be needed later (e.g. if the microtubule was born through branching,
   it is initally not severed from the parent microtubule, therefore set severedFromParent flag to false .
2) Branch severing - establish whether the parent microtubule branch site still exists or if the branch delay has expired and set the minus-end rate accordingly.
3) Collision code - flags identify collisions with types of object (e.g. plasma membrane edge or other microtubules) and the current growth state of the microtubule informs the code of what
   to do (e.g. hit a microtubule and growing, we have a zipper event. Or hit a microtubule and not growing, it has undergone collision induced castastrope). Microtubules that collide with the
   cell edge are processed partially here (growth state resumed), but wrapping and edge induced catastrophe are performed later.
4) Spontaneous and edge catastrophe - Based on whether a microtubule has collided with an edge or is in the cell, and based on the rates specified in the range variables above, plus-end
   catastrophe is initiated.
5) Rescue of severed and unsevered microtubules - The rates of rescue for both causes of catastrophe are used to resume growth. Severing in this context refers to crossover severing.
6) Crossover severing - A subfunction which uses a complicated record of collision vertices to split microtubules according to the rules of crossover severing.
7) Iteration specific stats - Record the number of growing and shrinking microtubules, the total length of all microtubules etc.
8) Reset collision information - flags which identify collisions are reset so that the next iteration starts from scratch.

As eluded to in the earlier description of the interaction function, microtubule nucleation, growth, removal from the data structure, etc all happens behind the scenes.

Stats

The last few hundred lines of code are mostly concerned with which stats are displayed on the graphical interface and screenshots, and also the stats that are written out to text files. You may not need to edit this section, but it useful to know how data is recorded and how to output new statistics.

The function plotMTCounts is passed a number of string parameters that determine which statistics will be recorded:

   % Write out stats information
   if isfield(data,'NameOfResultsDirectory')
       resultsDir=fullfile('runs',data.NameOfResultsDirectory(1:end-4));
       data.working.resultspath = resultsDir;
       data = plotMTCounts(data,'type',{'ROSE_PLOT','ORDERPARAMETER','CYCLIC_MEAN_2','CATONLY_MEASUREMENTS','JORDIS_MEASUREMENTS','ALL_BY_ANGLE','LIFESPANS'});
   else
       data = plotMTCounts(data,'type',{'ROSE_PLOT','ORDERPARAMETER','CYCLIC_MEAN_2','CATONLY_MEASUREMENTS','JORDIS_MEASUREMENTS','ALL_BY_ANGLE','LIFESPANS'});
   end

In the example above, the statistics are ROSE_PLOT, ORDERPARAMETER etc. ROSE_PLOT is an exception to the other statistics, as it actually updates the rose plot histogram on the display rather than outputting statistics to a file. The result of specifying ORDERPARAMETER is that a text file will be created during a simulation which contains the model name, ORDERPARAMETER and a unique time stamp:

MT_thin_rect_edges_20160830_-170324-142542-0303R001R_ORDERPARAMETER_170324-14-30-04.txt

This is achieved through the plotMTCounts function. This function contains a loop which iterates through each string parameter, with switch statement cases for a number of possible stat types. As with most MTtbox functions, it has access the data structure, which contains all the data regarding the simulation. Within the switch statement cases, the output for each statistic is formatted into a string. Once formatted, a specially named text file is created (see above) or updated to contain the output string. Thus, in order to record new statistics, you must think of a unique name for it, add it to the function call to plotMTCounts, and add an entry in the plotMTCounts switch statement.

Generate paper figures & visualising single simulations

Paper figures are generated in a number of ways, some of which are the same methods by which we visualise our data for day to day analysis.

Some figure generation methods require multiple simulations, as produced by the cluster, whereas other can be run on any project run directory.

As mentioned in the Cluster section, selecting Make Paper Figure when visualising simulation results using MTShowResults is one method for generating a paper figure from cluster simulations. The same results are produced by running makeMTtboxFig and selecting a simulation directory from a cluster run or a silent mode run. This method produces plots with simulation screenshots, order and mean angle plots with marked time points, and histograms of the mean angle. Generation of the histograms of mean angle causes the software to ask which of the experiments indices (for cluster runs) should be combined to make the plot. The expected input is in the form of a MATLAB expression (e.g. 1:40). Combining simulation results in this way ensures well sampled distributions, but only multiple runs from a cluster can be combined.

File:Paper-Fig-2017-Jun-29-10-01-57.png

Example simulation visualisation/Unformatted paper figure

Such combined histogram plots can also be generated, along with combined age distribution plots, using the following command:

combineAgePlots

The user will be prompted to select the first directory for a list of cluster jobs, and then to use MATLAB notation (e.g 1:40) to select which of those jobs you want to combine.

When looking at how alignments form in zippering versus catastrophe-alone models, we plotted mean length and age of microtubules as a function of angle for different time points. This is achieved using the following command:

showNewStats

Within this script, there is a MATLAB array containing the time points to be sampled, and the size of the sample window (the default is 200 iterations). This script asks the user for a LIFESPANS file from a simulation and an ALL_BY_ANGLE file. The former provides information regarding the age and frequency of microtubules as a function of birth or plus-end angle. The latter provides the distribution of lengths as a function of angle, as well as an alternative record of plus-end frequency. These produce extremely similar but not identical records of microtubule frequency: one records the frequency of plus-ends that are not paused at the cell edge (i.e. part of a wrapped microtubules) and the other establishes plus-end frequency from the birth and death time and birth orientation of each microtubule.


As mentioned in the Visualise Results section, the information produced by the Make Paper Figure command can be modified by changing the cell array of strings (plotsToPlot) within the makeMTtboxPaperFig function. In our paper figures, we generally display screenshots, mean angle plots and a histogram of the mean orientation. Additionally, the user must manually select whether or not to display a rose plot, scale bar and which shape cell to superimpose behind the microtubules, also within makeMTtboxPaperFig. This is important to remember, as you don't want circular cell shapes superimposed behind rectangular cells!:

...
% blankcellfilename = 'blankcellthinrect245.fig';
...
blankcellfilename = 'blankcell.fig';
...
scalebar = true;
...
noRosePlot = false;
...

The cell shapes are found here:

 Media: cellshapes.zip

Cluster

This work would not have been possible were it not for the UEA's High Performance Cluster. Specifically, the ability to explore parameter spaces and do multiple runs allowed us to more easily work out what was actually going on in our models.

It would take significant work to make our cluster software work with other clusters, but it has been done (e.g. I made it work with Cambridge's cluster).

To use the cluster, you will need a command line version of plink and putty, as well as an average knowledge of Unix based systems and cluster commands (e.g. bjobs, bkill, bsub etc).

The following command will submit the project MT_circle_20161208 to the cluster as a batch of 40 jobs. The simulation will run to 40000 iterations, writing out images every 200 iterations. The screenshots will be viewed from the top/above. Two variables in the model interaction function determine the number of jobs submitted; 'run', which is a dummy variable that is used to produce repeats, and 'useModelCase', which is used by the interaction function to specify the parameters for model case 27. The cluster will be used for this batch and the jobs are submitted to the short queue:

MTtboxCommandGrace('Name','MT_circle_20161208','N_steps',[0:200:40000],'VIEW_STEPS',200,'ORTHO_TOP',1,'run',[1:40],'useModelCase',10,'short',0,'Use','Cluster')

We typically run simulations up to 40000 iterations, which is ~11 hours of simulated time. Assuming average PC specs for 2017, models take between 1 hour and several days to run to completion depending on model complexity and most importantly, the number of microtubules in a simulation.

In case you don't have a cluster but you want your model output in a format as if it were from the cluster, replace 'Use','Cluster' with 'ExpID','XXXXXX0001' (i.e. run in Silent Mode), eg:

MTtboxCommandGrace('Name','MT_circle_20161208','N_steps',[0:200:40000],'VIEW_STEPS',200,'ORTHO_TOP',1,'run',[1],'useModelCase',10,'short',0,'ExpID','Test0002')

Note that you wouldn't use silent mode to explore run repeats or to explore a range of parameters, as you might with the cluster. This is because the simulations will run sequentially on your PC and take a prohibitive amount of time to complete.

Once models have run to completion, which you can determine by using the cluster's job status commands (e.g. bjobs), you must return them to your computer for analysis. This is achieved by running ClusterMonitorGrace and selecting Get project results:

ClusterMonitorGrace

File:Screen_Shot_2017-07-04_at_11.59.29.png

ClusterMonitorGrace Interface

Depending on how many and long your jobs are, the data you're recording in your simulations, and your Internet connection, downloading your simulation results can take anything from 5 minutes through to several hours.

Downloaded simulations are organised into a structure comprising a number of directories. Each directory looks like:

MT_thin_rect_edges_20160830-170324-142542-0303R001R

File:Screen_Shot_2017-07-04_at_12.01.59.png

Example cluster job directory

Where MT_thin_rect_edges_20160830 is the model name, -170324-142542-0303 is a unique identifier for the cluster batch and R001R identifies a job within that batch. Inside the job directory, there are a number of sub directories and files. The files in this directory are simulation outputs as specified by plotMTCounts in the interactions function. If it exists, the sub directory named backup contains the same files, but they are only updated every 5000 iterations, to provide a point from which simulations could be resumed if they do not run to completion within the allotted cluster time.

Visualise Results

After a cluster run is complete, you can visualise results using the following command and specifying the job .mat file that was created when you submitted the job:

MTShowResults

Exploring ranges of parameter values or multiple runs of experiments would be arduous and complicated without a way to quickly examine the context of and trends in the simulations. That's why we developed software to visualise the output from multiple simulations in one go. Various result displays are available, but many are obsolete and probably don't work anymore. In practice, the angle plot is the only thing you need to determine the reorienting behaviour of a simulation. However, the system is modular, so new methods of displaying results can be incorporated fairly easily. Just like in plotMTCounts when generating statistics, MTShowResults has case statements which refer to possible output statistics files. A good way of adding new statistics is to duplicate the code for an existing statistic (both in plotMTCounts and MTShowResults) and edit it to calculate/display what you want.

File:Screen_Shot_2017-07-04_at_11.59.51.png

Visualising mean angle plots for a cluster run of 40 repeats

Any combination and subset of cluster specified variables can be selected so that the relationship between them can be explored. Once you have displayed your cluster results, you can right click on a panel and choose to watch the simulation movie (Watch Video) or to generate a paper figure (Make Paper Figure). The paper figure maker is also a convenient way to visualise additional information about a simulation (e.g. simulation screenshots, order parameter etc).

File:Screen_Shot_2017-07-04_at_11.59.57.png

Right click menu for angle plots generated by MTShowResults

To change which information is displayed when generating a paper figure, it is necessary to manually comment/uncomment/construct a line of code in makeMTtboxFig (see the following example) which lists the panels you wish to include in your plot:

plotsToPlot = {'SCREEN_CAPS','CYCLIC_MEAN','ORDERPARAMETER','MEAN_HIST_COMBINED','DIFFERENTIAL_SURVIVAL'};

Additional Scripts

The following scripts for calculating edge bias and microtubule coverage are found, along with the MTtbox, within Media: MTtboxVersion1.zip.

  • Edge bias quantification was calculated using the MATLAB script kymo_checker.m. This script requests a directory containing the kymographs for one cell - this is also where outputs from the script will be saved. The kyomgraphs are expected to be .tif files, where the filename is appended by a piece of text which identifies which wall the image corresponds to (bot_crop, top_crop, dist_crop or prox_crop - e.g. mycell_bot_crop.tif). From the images, the script calculates the mean intensity of each wall (the mean of the mean of each row) and each pair of parallel walls (e.g. top-bottom, prox-dist). An image is saved with plots of this data, including standard error bars (+/- 2SE) for establishing statistical significance. If an angles.csv is present in the directory containing the kymographs (a list of the microtubule mean orientations for each time point (row) in the kymograph data), the script will also make a number of figures showing the wall intensities alongside a plot of microtubule orientation. When using angles.csv, the script will also look for a file named long or short in the kymographs directory. The script uses this information to generate some plots in terms of long or short walls, instead of proximal-distal or top-bottom. MATLAB returns four outputs from this script:
[bottop_distprox,cellOrientation,wallswitch,shortwalls,longwalls,sig]

where bottop_distprox is a four element vector containing the mean intensities of the respective kymographs. Where cellOrientation is a vector containing the mean angle information, assuming an angles.csv file exists for the cell. A wallswitch flag, which will be true if there is file named switch.txt in the kymographs directory (means the cell has been manually identified as having a switch in edge behaviour corresponding to a change in microtubule orientation). Where shortwalls and longwalls are the mean of their respective wall intensities, assuming a short or long file is located in the kymographs directory. And where the sig flag is TRUE for edge pairs that do not have overlapping error bars (2SE).

  • Microtubule coverage for experimental data was calculated using the estimateDensity.m MATLAB script. This script uses a pixel intensity threshold (MATLAB's graythresh function) to segment microtubules in an image. When this script is executed (but before image processing begins), it will ask for a number of items and ask some questions. Firstly, it will ask for an image stack (usually a TIFF of time series images) of the experimental data to be processed. Secondly it will ask "Single image with no mask?", to which you will usually click 'No' to process a time series (You make click 'Yes' to process the first image in the stack. In which case, later on the script will display a picture of the cell and the user must click around the cell edge in order to generate a cell mask). Next, the script will ask "show output". Clicking 'Yes' will display the microtubule segmentation frame by frame, requiring the user to click any key to progress to the next frame. Clicking 'No' will process all data without showing any visual information about the segmentation. Finally, the script will request a directory containing image masks. There should be separate png images for each frame in the stack, with the cell coloured in white and the background in black. The files should be named such that they are processed by MATLAB in numerical order (it is a good idea to 'pad' numbers with zeros, e.g. mask0001.png not mask1.png, as some computers will sort filenames differently to others). The script will then calculate the cell coverage for each frame, writing the results out to a text file (SIM-DENSITY.txt). The script also returns a vector containing the same data (e.g. densityVec), from which a mean value can be calculated (e.g. mean(densityVec).
  • Microtubule coverage for simulation data was calculated using a similar approach, but using a two-step process with two different scripts. Firstly, the MATLAB script renderMTtboxFigs.m was used to convert MTtbox simulation fig files into a format that could be segmented and processed (png images where the cell background is black and microtubules are white). renderMTtboxFigs requests a directory of fig files, as produced by MTtbox simulations executed in silent mode (see section: Running a Simulation on Your PC). It is necessary to adjust the celltype variable according to the model you are processing (e.g. 1 = 20um diameter circle, 2 = 20x10um rectangle). This is for two reasons: the first is to load the correct cell template figure file (Media: cellshapes.zip), so that the background of the cell can be filled with black, and the second is to dilate microtubule thickness such that it approximately matches the thickness of microtubule fluorescence in experimental data, given the scale of the simulated cell. This script will write out the processed images into a directory named outputdir, within the fig directory specified earlier. The final part of the process is to create a png image mask of the cell (called cell_mask.png) and then to calculate the microtubule coverage. The mask can be created by copying one of the processed images from renderMTtboxFigs, and then making everything within the cell white, and everything else black. Running calcDensityOfSim from within the processed directory of images will then display a vector of cell coverage for each frame and a mean value. This script simply reads in each image and uses the mask to calculate the proportion of the cell that is covered by white pixels (white pixels).

Notes on collision resolution

For each step, nucleation, growth and depolymerisation processes are executed by MTtbox before each microtubule is processed sequentially by the interaction function. Each time a microtubule grows, a new vertex is defined for the plus-end hemispherical cap and the intermediate vertexes are represented visually as tubular segments. The vertexes of shrinking minus-ends are adjusted according to the rate of minus-end shrinking, and removed when the segment length is zero.

If a microtubule collides with another during a growth step there are a number of collision responses depending on the parameters specified by the interaction function. Firstly, the collision may be ignored, leading to a crossover. In such cases, a record is kept detailing the collision, but the microtubule stays in the growing state, effectively ignoring the collision. Secondly, a microtubule may redirect to follow the obstruction, according to the threshold zippering angle. In this instance, the plus-end of the colliding microtubule is first trimmed back to the point of collision. The microtubule is redirected along a parallel trajectory if the angle of deflection is less than the zippering threshold angle. Otherwise, the microtubule will enter a paused state, which is either ignored and growth resumed (steep angle crossover) or undergoes collision-induced catastrophe.

Another type of collision event is crossover-severing, which typically occurs some time after a collision at the intersection between two microtubules. Severing is implemented as a sub-function of the interaction function. Active crossover points, in which the collision angle is greater than 2 degrees, are determined through the recording of collision events (the identity of the crossing versus obstructing microtubules, the identity of the nearest vertex on both microtubules and the time of collision).

The severing probability determines which crossover points, if any, will be severed. A severed microtubule is split into two separate microtubules, with the collision and vertex records divided accordingly. In the zippering-alone model, steric hindrance can result in constrained growth. To avoid this behaviour introducing differential survival we introduce a parameter, keepIgnoredMTs, which allows a microtubule to ignore repeated collisions with the same microtubule in an iteration. The outcome is that microtubules will crossover unresolvable obstacles. Collisions between hemispherical microtubule ends are ignored unless the collision is axial, in which case a catastrophic collision is registered (rather than crossover). When collisions are ignored, microtubules may travel through the obstruction.

Microtubules may also collide with edge of the cell. We consider two options for this event. One is for the microtubule’s plus end to re-enter at the opposite edge, travelling in the same direction. This option is termed wrapping. In our simulations, wrapping microtubules do not always encounter their tails. The probability of wrapping when colliding with an edge can be specified, but with wrapping enabled, the default proportion is 100%. Alternatively, a plus-end can pause at the cell edge, whilst the minus-end continues to shrink at its normal rate. We term this option face-exit. When wrapping in a circular cell, we assume that the re-entry position is calculated from the backward projection of the exit trajectory and the trajectory remains unchanged. In other geometries with distinct edges, such as square or rectangular geometries, microtubule trajectories remain unchanged, but the re-entry position is a translation of the exit position onto the opposite edge. We found that other wrapping assumptions make little qualitative difference to the model behaviour. In our simulations, microtubules that undergo wrapping do not always encounter the minus-ends of their parent microtubule. This assumption promotes alignment formation in models using cell-wrapping.

History

MTtbox was originally developed by Prof. Andrew Bangham in late 2011 to explore alignment formation in 3D cells. It was at least the second generation of the group's modelling software. It is my understanding that Andrew wanted MTtbox to employ the same interaction function mechanism as GFtbox, which had proven so successful. As with GFtbox, MTtbox was developed in MATLAB, as it is cross-platform compatible and an extremely efficient environment for developing scientific software. After an extraordinary stab at a fully functional prototype of MTtbox, Andrew passed the software onto Richard Kennaway to make the code sensible, correct, and fast. Around Christmas 2011, Jacob Newman started using the toolbox for modelling, and also assisted Richard with its development. Jacob was primarily responsible for developing software to run MTtbox on the UEA cluster and for visualising the simulation results.

We fairly quickly developed a spontaneously reorienting model, however, it took much longer to work out why the model worked. After the passing of Andrew, the project has been supervised by Prof. Enrico Coen. We took a reductionist approach to disentangling our model. Over several months, we gradually stripped away many microtubule behaviours that we (and the microtubule community) considered essential to alignment formation, and probably reorientation. Latterly, with a very simplified model, we arrived at an understanding of how alignment formation and reorientation occurs.

modified on 10 October 2017 at 15:56 ••• 5,283 views