varys 0.5.2
For parsing and reformatting behavioral event logs.
License: BSD
Keywords: behavioral

Varys
=====

Varys is a python package for anyone who has to work with behavioral
data logs.

Chances are, you need that data in another format before you can work
with it. If you're like most of us, you have some collection of scripts
around somewhere that can parse format A, other scripts that write
format B, and somewhere in the middle you'll sandwich some logic that
actually has something to do with your experiment.

Our goal is to reduce the load down to this last bit.

Varys breaks its work into three segments: LogParser, EventBuilder, and
FileWriter. Of these, only EventBuilder needs to be customized per
experiment.

LogParser is meant to grow with time to be able to parse an increasingly
diverse list of input types. At the moment we support simple TDF and CSV
formats, as well as the FIDL format used by the eponymous software
package from Washington University in St Louis. But we're willing and
interested to work with users to expand that list.

EventBuilder takes input from a LogParser, and turns it into a list of
"event" dictionaries. These can contain arbitrary values, but at a
minimum must contain "name," "onset" and "duration."

FileWriter takes these ordered dictionaries, then writes files
consumable by analysis packages. At the time of this writing, we support
SPM, FIDL, tab delimited .txt, and python's Pickle, but here again we're
willing and eager to expand the list of supported formats.

We've thrown in some special options for working with neuroimaging data,
for concatenating runs, and other fun stuff too.

So please, take a look at the examples list, see if any of them sound
like your situation, and feel free to use them as a starting point for
your own work.

Installation
============

Varys uses scipy, which in turn uses numpy, and as of yet we're too lazy
to do the fancy dancing needed to auto-install numpy as a dependency. So
it'll take two steps:

::

    pip install numpy
    pip install varys

Or grab the latest development version from
https://github.com/beOn/varys, and install using setup.py.

Supported Formats
=================

Currently supported formats are:

Input: .txt, .tdf, .csv, .fidl

Output: spm, fidl, pickle, txt (tab delimited)

Examples
========

Varys provides several EventBuilder subclasses for handling data in
different ways - in short, you can either have your data handed to you
as a list of rows (as dicts), or you can have it handed to you one row
at a time. Usually the latter approach is the most helpful.

There are several EventBuilder subclasses you can dive into, but here
we'll cover the kinds you're most likely to use: RowWise\_EventBuilder,
RowWise\_fMRI\_EventBuilder, and FixedDuration\_EventBuilder. Please
forgive the long names. Names were never my strong suit.

Using either of the two RowWise classes involves creating your own
subclass, whereas FixedDuration\_EventBuilder is meant to be configured
and used without subclassing, making it easier to write very simple
EventBuilders.

Enough chit chat. Let's look at some examples.

Mise en Scène
-------------

For the following examples, we'll pretend that a few things are the
case:

-  Subject data is in /data/sub\_N/run\_M.txt, where 'N' and 'M' are
   two-digit subject and run numbers, respectively (ie 01, 02, etc.).
-  The event name is whatever value is stored in the column named
   "trial\_type"
-  All trials have a duration of 10.0
-  Trial onset time is in a column named 'cue\_onset'
-  Answer accuracy is in a column named "acc", and is either '1' or '0'.
-  The first trial's onset time is to be used as time = 0
-  For the fMRI subclass, the TR is .7, because your scanner is awesome
   (written circa 2014)
-  For the sake of clarity, we're going to be sloppy about not catching
   exceptions.
-  Each run's data is in its own file
-  You have three subjects, 1, 2, and 3
-  You want to save the resulting files into "/data/output"
-  Your source files fall into the correct order if sorted
   alphabetically
-  You want to use the events in SPM, and save a pickled version as well
   for later use in python

RowWise\_EventBuilder
---------------------

This is probably the most useful subclass, and is pretty simple. Let's
take a look.

.. code:: python

    from varys.EventBuilder import RowWise_EventBuilder
    class basic_EventBuilder(RowWise_EventBuilder):
        def __init__(self):
            super(basic_EventBuilder, self).__init__()
            self.trial_onset = 0
            self.data_glob_templates = ["/data/sub_%02d/run_*.txt"]
            self.subjects = [1,2,3]
            self.output_dir = "/data/output"
            self.output_formats = ["spm", "pickle"]
        def events_for_row(self, row_dict):
            events = []
            name = row["trial_type"]
            onset = float(row["cue_onset"]) - self.trial_onset
            acc = row["acc"]
            if name and onset:
                events.append(["name":name,
                               "onset":onset,
                               "duration":10.0,
                               "acc":acc,
                               "set":"all_events"])
            return events
        def handle_run_start(self, run_idx, run_data, file_name):
            self.trial_onset = float(run_data[0]["cue_onset"])

    eb = basic_EventBuilder()
    eb.run()

To get the details on this and the other subclasses, check out the noted
in the related code. But since we're here, let's take this apart a
little bit.

``handle_run_start`` gets called at the start of every run, and as such
is a great place to find and set aside any run-wide variables, like run
onset time. That's exactly what we do in this example.

``events_for_row`` gets called once per row of data in your original
file, and is expected to return a list of dicts (one dict per event).
You might be wondering what this set entry is all about, and why we
return a list of events, instead of just one. From time to time,
analysis will require that you create several different event sets - one
including all trials, and one including only those trials which were
answered correctly, for example. Suppose we wanted to do exactly this
for the current example. Then we'd change the if block of
events\_for\_row to read as follows:

.. code:: python

        if name and onset:
            events.append(["name":name,
                           "onset":onset,
                           "duration":10.0,
                           "acc":acc,
                           "set":"all_events"])
            if acc == "1":
                events.append(["name":name,
                               "onset":onset,
                               "duration":10.0,
                               "acc":acc,
                               "set":"acc_events"])

Note that we used a different ``set`` for the second event. This will
cause EventBuilder to write two sets of files for the two event sets.
You might not need this, but if you do, it sure is nice not to have to
write a whole 'nother subclass!

The ``init`` method just presets a few values specific to this
experiment. Note that you can override these. If you moved the script to
another machine, where the data was instead in
``/my_data/subjects/sN/run_M.txt`` (remembering that N and M are
two-digit subject and run numbers, respectively), and you wanted to save
the results to ``/analyses/new_data``, you don't have to modify the
subclass. You can just change a couple of values, then call ``run()``:

.. code:: python

    eb = basic_EventBuilder()
    eb.data_glob_templates = ["/my_data/subjects/s%02d/run_*.txt"]
    eb.output_dir = "/analyses/new_data"
    eb.run()

``subjects`` can be similarly changed.

RowWise\_fMRI\_EventBuilder
---------------------------

This class is pretty much the same as RowWise\_EventBuilder, but has a
few extra features specific to fMRI. Let's take a look, and go through
it afterwards. I'll omit everything that would be identical, but do
remember to include it in your own subclasses.

.. code:: python

    from varys.EventBuilder import RowWise_EventBuilder
    class basic_fMRI_EventBuilder(RowWise_EventBuilder):
        def __init__(self):
            super(basic_fMRI_EventBuilder, self).__init__()
            # same as RowWise_EventBuilder, with one extra property:
            self.TR = .7

        # events_for_row same as RowWise_EventBuilder
        # handle_run_start same as RowWise_EventBuilder

        def tr_count_for_run(self, run_idx, file_name, raw_rows, events):
            """ return the TR count for the given run. """
            if run_idx < 2:
                return 130
            else:
                return 200

So, there are really only two differences here, and their utility might
not be immediately apparent (we'll get there): the property ``TR``, and
the method ``tr_count_for_run``. In this example, we set the TR to .7,
and return one of two values for ``tr_count_for_run`` depending on the
run number.

So, who gives a flying leap at a rolling doughnut about TRs and how many
there are per run? Anyone who needs to concatenate their runs, that's
who. We use these two properties to figure out how much time to add to
the onset of all events for each run. So if you have 100 TRs of length
.7 each in run 1, every event in run 2 will have 70.0 added to its onset
time. But take note, *this will only happen if you set the
``concat_sets`` property to a list of the sets whose runs you'd like to
concatenate*. We do it this way because you may not want to concatenate
runs for every event set. So, if we wanted to concatenate runs, but only
for the event set that contains accurate response events (acc\_events),
we'd change the init method like so:

.. code:: python

        def __init__(self):
            super(basic_fMRI_EventBuilder, self).__init__()
            # same as RowWise_EventBuilder, with one extra property:
            self.TR = .7
            self.concat_sets = ["acc_events"]

Take note, some output formats, such as fidl, absolutely require
concatenated runs. If you specify one of these output formats, *all runs
in all sets will be automatically concatenated*, even if you don't set
concat\_sets.

Skipping Output
---------------

Sometimes, you don't actually want to write the event set out to any
file. You just want to parse the events, then keep working with them in
your code.

To do this, set the ``skip_output`` property to True, then retrieve the
values for the subject you're interested in. Working with our
``basic_EventBuilder``, if we wanted to get the list of lists of event
dicts for subject 1, we'd do as follows:

.. code:: python

    eb = basic_EventBuilder()
    eb.skip_output = True
    eb.run()
    sub_num = 1
    s1_events = eb.sub_data[sub_num]["acc_events"]

One Giant Input File
--------------------

It may be the case that, instead of having one input file per run,
everything's in one big table, and there's some column whose value
changes every time a new run's data begins. To handle this, just set the
``run_field`` property to the name of that column. If this were the case
for our example, and the name of the column was "run\_number", we'd just
make a slight modificaiton to the init method:

.. code:: python

    class basic_EventBuilder(RowWise_EventBuilder):
        def __init__(self):
            super(basic_EventBuilder, self).__init__()
            # everything is the same as before, but add:
            self.run_field = "run_number"
        # everything else is the same as before

Not so bad, eh?

TODO
----

-  FixedDuration\_EventBuilder, once it's ready

Reporting Bugs, Requesting Features
===================================

Submit all bug reports and feature requests using the github ticketing
system: https://github.com/beOn/cili/issues

Please make an effort to provide high quality bug reports. If we get one
that just says, "sample range extraction is broken," we'll probably
trash it without a second look, because the submitter is probably the
kind of person who saps energy from everything they touch.

A good bug report should include three things:

1. Steps to reproduce the bug
2. Expected result
3. Actual result

The goal is to give the developers the ability to recreate the bug
before their own eyes. If you can give us that, we'll take a very close
look.

Why Varys?
==========

Because it manipulates events: http://gameofthrones.wikia.com/wiki/Varys

TODO: Thanks, credit to CCP Lab