Models, stimuli, and responses are described using plain text parameter files. A structured parameter file format (file extension .moo), described in detail in the next section, is now used for most models, including models of the ‘pop’ type. An unstructured format is used for stimulus (.stm) and response (.rsp) files and also for some older model files (.mod). Lines in the unstructured format are as follows:
Stimulus files (.stm) have a number of special parameter names with specific line formats. Please see the section on Stimulus parameter files for more details.
Differences between two unstructured parameter files can be found by using the ‘diff’ option:
wm diff m1.mod m2.mod
The .moo format uses tags to enclose structures, for example:
<pop> ... </pop>
contains parameters to define a population of cells for the ‘pop’ model type.
In general, an object of type ‘oname’ is described as follows:
<oname> [item_name] [val] [(unit)] [# comment] ... </oname>
<area> name v1 # Area name x0 16.0 # Origin wrt stim grid y0 16.0 # umx 64.0 (um) # micons per Area grid unit </area>
An object can be assigned an ID, for example:
<geometry ID=v1_geom> ... </geometry>
This allows it to be referred to using ‘COPY’:
Only the items and objects not already present in the new object will be copied from ‘v1_geom’.
To automatically run a set of models in which the values of one or more parameters are varied systematically, a <var_param> object is used. This object can be placed in the .moo file or in a separate file (see below). For example:
<var_param> <var_moo> tau 1.0 2.0 3.0 </var_moo> </var_param>
This would cause the running of three different models in which the parameter named ‘tau’ would take on the values 1.0, 2.0 and 3.0.
Linked parameters. Two or more parameters can be linked and varied together as follows:
<var_param> <var_moo> tau1 1.0 2.0 3.0 tau2 0.2 0.3 0.4 </var_moo> </var_param>
This would also run three separate models, the first having tau1 = 1.0 and tau2 = 0.2, the second having tau1 = 2.0 and tau2 = 0.3, and so on. By adding more lines within the <var_moo> object, the values of more parameters can be linked together.
Product-space parameters. A product space of values for multiple parameters can be achieved as follows:
<var_param> <var_moo> tau1 1.0 2.0 3.0 </var_moo> <var_moo> tau2 0.2 0.3 0.4 </var_moo> </var_param>
In this case, nine separate models would be run for combinations of tau1 and tau2 as follows: (1.0, 0.2), (1.0, 0.3), (1.0, 0.4), (2.0, 0.2), ...
The techniques of linked parameters and product-space parameters can be combined, by having multiple parameter names (on separate lines) within a <var_moo> object, and also multiple <var_moo> objects.
Where to put the <var_param> object. The <var_param> object can be placed either in the .moo file, as a top level object (i.e., not within any other tags) or in a separate file that is named in the .moo file with the following parameter:
This parameter must be placed at the top level in the file (i.e., not within any tags). The file name specified (here ‘foo.txt’) can be any name. The file should contain only one <var_param> object.
Auto-generated model index parameter. When a <var_param> is used and an nData file is generated, a special, additional variable parameter named MOO_var_i is created to enumerate the model configurations that were generated by the <var_param> object. For example, in the example above under Product-space parameters, the MOO_var_i parameter would take on values from 0 to 8, corresponding to the nine model configurations. This automatically generated variable parameter provides a convenient way to group trials together and sort them when analyzing the nData file, e.g., with the nda system or with the nData browser.