|
|
Imperial
|
The operation of the simulator is intuitive and simple. All interactions between end-user and application utilise visual interfaces as can be seen towards the end of this appendix. All data used during simulations can also be entered primarily via script files stored on permanent media (e.g. computer’s hard-disk).
In addition to the already discussed user and system interaction, the execution of the simulator involves some key-concepts that have to be well understood. Below there is a brief description of the five most important of these key-concepts, namely processing phases, action-to-proceed, training/testing epochs, stopping criteria, and grouping/granularity of results (i.e. output statistics).
· Processing phase is the way we included in the simulator the principle of developmental stages (or life cycle) of networks. It is the upper most division of one simulation race (i.e. a single simulation execution). This concept allows the occurrence of great functional and parametrical changes during one simulation race. The user prior to the simulation initiation should indicate the desired number of processing phases. Because only of trivial technological reasons (i.e. space in computer main memory), the current version of the GVNS has up to ten processing phases.
· Action-to-proceed is the means selected to include in the simulator the notion of distinct tasks to be performed in each processing phase of one simulation. As a design decision every processing phase has one and only one action defined to it. The actions defined in the current version of the simulator are: training afferents, training efferents (including two sub-modalities), training efferent feedback, testing, and resting. As the names of the first three indicate they deal with selective trainings of fibres including u-fibres. The testing action does not involve training as the simulator uses previously stored values for all synapses (or just after trainings). Finally, the resting action is functionally similar to testing, with the difference that no pattern is presented to the network - except of (i) sensory feedback and (ii) some external stimulation.
· Epoch of training and testing is the term used to describe one complete presentation of all patterns used either for training or testing of the network being simulated. This is a well know concept in the artificial neural networks literature that was incorporated in the simulation functioning. Typically, trainings and testings artificial neural networks involve several epochs. In the GVNS, many epochs are allowed to happen in each action-to-proceed, and consequently in each processing phase. Again, because of restrictions of computer main memory, epoch value is limited to a few hundreds.
· Stopping criterion is what objectively terminates training or testing phases. The GVNS implements two stopping criteria, namely (i) maximum number of training or testing epochs, and (ii) minimum average error in the effectors. It is down to the user to specify which of these two criteria should be considered in each processing phase. In the end of every epoch the system checks if the indicated value is reached – whatever selected criteria. If this has happened that particular phase is then terminated.
· Grouping and granularity of results are concepts used in the GVNS that respectively define (i) the type and (ii) the summarisation of output files containing statistics of the evoked behaviour produced by the network. Results can be grouped in four distinct manners that are: none, output, epoch or both (both means output and epochs at the same time). Regarding granularity the results can be generated in two manners namely individual or average. The adequate selection of these two options is very important for analyses of results. Because they govern the production of the several files comprising all history and statistical data of evoked behaviour (refer to Figure 1). Appropriately selected, these files are then generated along side processing phases per each effector defined in the network.
The GVNS accepts a large number of parameters to produce its expected results (i.e. use-cases, see introduction section to GVNS). The present implementation of the simulator was designed to receive its parameterisation from three distinct sources; these sources were devised according to their functionality. This section aims to briefly comment upon them.
The sources of parameters mentioned before correspond to three physical files, where parameters alike are grouped together. They are cardinality, architecture and simulation parameter files. This design decision allows different simulations to be carried out by simply changing one of the files; this helps the user to reuse parameter files across different simulations. For example, two distinct simulations can share the same net architecture thus the user only needs to prepare simulation files and vice-versa.
Next, lists of these three groups of parameters will follow including their components and features. Notice that although already defined and input, not all of the features below are considered during processing. The session future work in the conclusion chapter of this thesis contains more information about this issue.
The cardinality source (i.e. parameter-file #1) contains information about the dimension of the network, and the number of each component utilised. It also includes name of files and the name of the simulation. The latter prefixes all screens, input and output files used during one simulation. The full list of cardinality parameters is below:
· Cortex width;
· Cortex height;
· Number of unit types;
· Number of regions;
· Number of u-Fibres;
· Number of afferents;
· Number of efferents;
· Number of efferent feedbacks;
· Number of stimuli;
· Number of effectors;
· Number of processing phases;
· Number of plaque assemblies;
· Number of stimulus sets;
· Simulation name;
· Log file name;
· Cardinality file name;
· Network file name;
· Simulation file name;
The architecture source (i.e. parameter-file #2) contains information about the structure of the network, i.e. what are the features of the structural components used to make-up the simulated neural network. Notice that the number of a component defined in the cardinality file implies an equivalent number of feature definitions for that component in the architecture file. For example if the number of regions specified in the cardinality file is two, this requires that features of two regions have to be entirely defined in the architecture file. The list of architecture parameters accompanied by their features (terms inside brackets) can be seen below:
· Unit Types (Threshold; Activation function; Operation frequency; Refractory period);
· Regions (Initial width, Initial height, Final width, Final height, Unit type);
· U-Fibre fibres (Origin region, Target region, Activity type, Density, Delay);
· Afferent fibres (Stimulus source, Target region, Density, Off-set, Delay);
· Efferent fibres (Target effector, Origin region, Density, Off-set, Delay);
· Efferent-feedback fibres (Origin effector, Target region, Density, Off-set, Delay);
· Stimulus sources (Cardinality, Latency, Resilience);
· Target Effector (Cardinality, Threshold, Function, Latency, Resilience)
The last parameter source, i.e. simulation, contains all the non-structural information necessary for the simulations to be carried out. It also has to be in agreement with the parameters informed in the cardinality file. Notice that all parameters listed below have to be informed for each processing phase specified in the cardinality file. In case of more than one multiple sclerosis plaque and stimulus set be specified in the cardinality file they too have to have information provided according to their specific cardinality. The list of simulation parameters (per processing phase) is:
· Output observation (Effector breaks and granularity; Cortex sample rate);
· Network function (Cell death rate; Axon growth rate; Noise rate; Relaxation rate);
· Afferent learning (Learning rate; Decrement of learning rate; Cooperation radius; Neighbouring function);
· Efferent learning (Learning rate; Decrement of learning rate);
· Pathology-1 (Stroke file name);
· Pathology-2 (Affected fibre type and order; Ms-plaque file name; Fibre allowance);
· Stimulation (Stimulus order; Train/test file name);
· Processing action (Action identification; Number of epoch/Error; Number of Patterns/Time);
All files comprising the permanent data set of the simulator can be seen in Figure 1. In the figure all files are grouped by their access type and function. Input files are on the left and output files are on the right. Functional groups are parameters, fibres, train/test data, pathology data, information windows, log, and history and statistics.

Figure 1 – Input/Output
diagram of the Venn-network simulator
Over 18,000 lines of code entirely written in the computer programming language Java™ 2 constitute the current version of the GVNS. The integrated development environment utilised for producing the simulator was Jbuilder ™ 4 Professional from Borland®. All classes of the simulator were compiled and executed under the virtual machine Java HotSpot™ version 1.3.0-C from Sun Microsystem® Inc, and the basic software platform (i.e. operating system) was the Windows XP Professional™ produced by Microsoft Corporation®.
The present design of this generalised version of the Venn-network simulator was inspired by previous experiments carried out using a prototype written by the author in the spring of 2001. However, all results reported in this thesis were produced with the newly constructed (version 1.0) of the GVNS.