|
| Topographica is still under very active development. As described
below, a large number of changes and new features are scheduled over
the next few months, as well as over the next few years. Our current
lower-level list of tasks is kept separately.
Most urgent (Spring 2008):
- ALERTs
-
There are a large number of relatively small problems noted in the
source code for the simulator; these are marked with comments
containing the string ALERT. These comments help clarify how the code
should look when it is fully polished, and act as our to-do list.
They also help prevent poor programming style from being propagated to
other parts of the code before we have a chance to correct it. We are
slowly working to correct these issues.
- Stable APIs
-
The Topographica API (determined by the classes in base/) is gradually
becoming more stable, and by the time of the 1.0 release it should be
possible to build add-in components and model scripts and expect them
to be usable in future versions (or to have a conversion program
available for them).
- Spiking support
-
Topographica primarily supports firing-rate (scalar) units, but
spiking models are currently under development, and preliminary
versions are included already. We will be developing interfaces
between spiking and non-spiking Sheets and analysis tools for spiking
neurons. We primarily expect to support integrate-and-fire and
related computationally tractable spiking unit models. More detailed
compartmental models can be simulated in NEST, Neuron or Genesis instead,
and packaged up using the Sheet interface so that they can be used
in Topographica.
- Polishing the GUI model editor
-
The Topographica model editor allows a model to be constructed,
modified, visualized, and edited. However, there are a few operations
not currently supported, such as setting a parameter to a random
stream of numbers. These limitations mean that in most cases
some editing of the generated .ty script file will be necessary.
Near future:
- Archival state saving
-
Model state saving is currently implemented using Python "pickling"
(persistent storage). As the Topographica classes change, these files
quickly become out of date, and cannot be loaded into more recent
versions. By the 1.0 release we plan to provide an upgrade path, so
that old saved files can be used with new versions. To make this
simpler, we are working on an alternative implementation of state
saving using XML, which is designed to be an archival, readable
format. In the meantime, users should be aware that saved snapshot
files will not necessarily be readable by future versions of
Topographica, and should be considered temporary.
- Bitmap plotting enhancements
-
The current basic support for two-dimensional bitmap plotting will
eventually need to be expanded to allow the user to control plot
brightness scaling, allow custom colormaps, and add an "overload" or "cropped"
indicator to show if some values are too large to be displayed in the
selected range.
- Automatic line-based 2D plotting
-
There are currently 1D (line), 2D (contour or vector field),
and 3D (wireframe mesh) plots available based on
MatPlotLib for any
program object selected by the user. We will also eventually be
making the general-purpose template-based plotting use the 2D plots,
which will make it possible to do
contour
plots, as well as matrix plots showing axis ticks and labels. We
also plan to use MatPlotLib 2D plots to allow any SheetView(s) to be
used as a contour or vector field overlay on top of a bitmap, e.g. for joint
preference maps (such as direction arrows on top of an orientation
bitmap plot).
Other minor changes planned include adding outlining of
ConnectionField extents, plotting histograms for each bitmap,
and separate default colors for onscreen and publication plots.
- Map statistics
-
We will implement general routines for measuring the statistical
properties of Sheets, such as for computing a perceived orientation.
Eventually:
- Improve documentation
-
The reference manual is generated automatically from the source code,
and needs significant attention to ensure that it is readable and
consistent. For instance, not all parameters are documented yet, but
all will need to be.
- More testing code
-
Topographica has a fairly complete test library, but there are still
classes and functions without corresponding tests. Eventually, there
should be tests for everything.
- Pycheck/pylint
-
It would be helpful to go through the output from the pycheck and
pylint programs (included with Topographica), fixing any suspicious
things, and disabling the remaining warnings. That way, new code
could be automatically checked with those programs and the warnings
would be likely to be meaningful.
- Animating plot histories
-
GUI plot windows save a history of each plot, and it should be
feasible to add animations of these plots over time, as a helpful
visualization.
- Registry editor
-
In a large network with components of different types, each having
various parameters and default values, it can be difficult to
determine the values that will be used for new objects of a certain
type. We plan to add a hierarchical global variable display and
editor to allow these values to be inspected and changed more easily.
We also plan to add the ability to track which parameters have
actually been used by a given object, so that it is clear how
to modify the behavior of that object.
- User-defined scales
-
The simulator is written in terms of abstract dimensions, such as
Sheet areas that default to 1.0. This helps ensure that the simulator
is general enough to model a variety of systems. However, it is often
desirable to calibrate the system for specific scales, such as degrees
of visual angle, millimeters in cortex, etc. We plan to add
user-defined scales on top of the arbitrary scales, mapping from
values in the simulator to user-defined quantities for display.
- Parallelization
-
Due to their weakly interconnected graph structure, Topographica
models lend themselves naturally to coarse-grained parallelization.
Each event processor (e.g. a Sheet) can run on a different physical
processor, exchanging information with other event processors using
either shared memory or message passing protocols such as MPI.
Implementing this type of parallelization is not likely to require
significant changes to the simulator.
Fine-grained parallelism is also possible, distributing computation
for different units or subregions of a single Sheet, or different
parts of a Projection across different
processors. This has been implemented on a prototype version for a
shared-memory Cray MPP machine, and may be brought into the main
release if it can be made more general. Such fine-grained parallelism
will be restricted to specific Sheet and/or Projection types, because
it requires access to the inner workings of the Sheet.
- More non-visual modalities
-
Most of the specific support in Topographica is designed with visual
areas in mind, but is written generally so that it applies to any
topographically organized region. We plan to implement specific
models of non-visual areas, providing input generation, models of
subcortical processing, and appropriate visualizations. For instance,
there are now models of somatosensory areas, such as hand surfaces and
rat whisker barrels, and motor areas controlling eye movements.
Additional contributions from Topographica users with experience in
these domains will be particularly helpful.
- Data import/export
- It will be crucial to provide
easy-to-use interfaces for exchanging data and calling code in other
simulators, such as Matlab (see the optional external package
mlabwrap).
These will be used both for analyzing Topographica data, and for
allowing connection patterns and/or map organization to be specified
from experimental data. Meanwhile, the Python command-line interface
can be used to display or save any element of the model.
- Lesion support
-
It is now possible to temporarily lesion any part of a Topographica
Sheet or Projection using a PatternCombine OutputFn. This capability
will eventually be extended so that it is easier to use, to make it
simpler to test which components are required for a certain behavior,
and to replicate animal lesion experiments.
- More library components
-
Topographica currently includes examples of each type of library
component, such as Sheets, Projections, ResponseFunctions,
LearningFunctions, and PatternGenerators. However, many other types
are used in the literature, and as these are implemented in
Topographica they will be added to the library. Again, user
contributions are very welcome!
- More example models
-
Topographica currently includes a number of example models,
mostly from the visual system but also from somatosensory,
auditory, and motor areas. As additional models are implemented,
they will be added as examples and starting points. Again, user
contributions are very welcome!
|
