Parameter files
---------------

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:

* Blank lines - ignored.

* **#** - comment from here to end of line.  Comments not at the
  beginning of the line must have white space before them.

* ``[name] [val1] ... [valn]`` - parameter name followed by one or
  more values.  Names and values are separated by white space.  There
  may be an optional **#** for a comment after the parameter value(s).
  Names may not start with a dollar sign (**$**), as this is a
  reserved symbol.

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


Structured format
-----------------

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>

For example::

    <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'::

     <geometry COPY=v1_geom>

Only the items and objects not already present in the new object will
be copied from 'v1_geom'.

Varying model parameters
------------------------

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.

**Varying multi-valued parameters.**
If a parameter has multiple values (which is allowed in .moo files),
it can only be varied by using a lookup table as shown below::

  <var_param>
    <var_moo>
      $pop.mt/me_v5/w  w1 w2 w3
    </var_moo>

    <varpar_lookup>
      name pop.mt/me_v5/w
      w1   0.0 1.0 2.0 3.0 4.0  5.0  5.0 4.0 3.0 2.0 1.0 0.0
      w2   0.0 2.0 4.0 6.0 8.0 10.0 10.0 8.0 6.0 4.0 2.0 0.0
      w3   1.0 1.0 1.0 1.0 1.0  1.0  1.0 1.0 1.0 1.0 1.0 1.0
    </varpar_lookup>
  </var_param>

In this example, there is a parameter in the model named
"pop.mt/me_v5/w" that is multi-valued (it requires 12 values in this
example), and so we add a dollar sign, **$**, in front of the name in
the <var_moo> object (to indicate that the values must be looked up),
and we make up labels (here we use w1, w2 and w3, but names like 1, 2,
and 3 could be used also) for three cases.  The values associated with
those labels are then defined in a <varpar_lookup> object, which must
have a 'name' that matches the variable parameter name (excluding the
$).  The labels are then listed one per line, followed by their
associated sequence of values (here there are 12 values for the sake of
example).  There can be more than one <varpar_lookup> structure, and
there must be one for each of the variables prefixed with a $.

Note: When this <varpar_lookup> technique is used, the value
associated with the variable parameter in the output .nd file will be
the **label**, and not the list of values.

**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::

  var_param_file foo.txt

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.