-
Notifications
You must be signed in to change notification settings - Fork 2
nigeLab
(Current as of: 2019-11-23)
Classes kept at this level of the package are primarily supposed to be inheritors of the nigelObj
superclass (work-in-progress), except for the Sort
class, which may see frequent use in practice and was kept at this level to prevent cumbersome 'dot'-indexing.
Hierarchically, the top-level Parent
object within the nigeLab
relational framework. A Tank
may contain one or more Animal
objects and is used to organize experiments.
Hierarchically, Animal
links Tank
to Block
classes. Each Animal
may have multiple recording Block
objects that could either be different recording epochs within the same acute preparation, or may reflect recordings made on different days for chronically-implanted animals.
The fundamental "building-block" of nigeLab
, the Block
class keeps track of metadata for a given recording and its methods are what do the basic data manipulation and access for different kinds of data that are tracked within nigeLab
. Links to data are achieved primarily through the use of user-configurable defaults that gather data from categories defined by combinations of Fields and FieldTypes.
Contents
This is the main package that has quite a few files in it. Currently, this acts in a capacity similar to a +config
, but in the future it should retain its state of just being the "default parameters" as opposed to the "configured parameters." Some of the more important +defaults
are listed below, but for more thorough documentation, check here as well as looking at documentation within functions of the package (particularly for examples of how metadata parsing variables should be set up).
This is where most of the necessary parameter defaults are set (they relate to Block
objects, which are the main class used to link data in nigeLab
). Importantly, both Fields and FieldType are configured here, as well as File Types. FileNames
and FolderNames
must contain the same number of elements as the previous variables; they are used in setting up the Block
disk file hierarchy. The TAG
variable is a struct that configures how naming conventions are parsed elsewhere, but probably shouldn't be changed.
This is where parameters are configured for members of the Events
FieldType. Click here for details about how to configure the relevant variables.
This is really only important if you are taking advantage of the Matlab Parallel Processing
and Distributed Computing
toolboxes. If you would like to run everything serially, just change pars.UseParallel
to false and pars.UseRemote
to false. We use nigeLab
to run some of the more memory-intensive methods (doRawExtraction
and doAutoClustering
being the chief use-cases) on the University of Kansas Medical Center Isilon computing cluster. If you have access to the Isilon and would like to use nigeLab
, then pars.UNCPath.RecDir
and pars.UNCPath.SaveLoc
must be configured here to reflect your internal mapping to the Isilon drives. You also may have a different naming convention for the Matlab Job Server(s) that run the remote job queue; in that case, you will need to change pars.ClusterList
to reflect the job server names.
Spike-detection parameter defaults are set here. With no re-configuration, the default spike detection uses a threshold-based peak-finding strategy on the smoothed nonlinear energy operator (SNEO). The current auto-clustering strategy uses the wavelet-based super-paramagnetic clustering algorithm developed by the Quiroga Lab, but has not been configured in our code to return optimal cluster groupings. Other options can be set according to comments next to each field of the pars
struct in nigeLab.defaults.SD
.
Defaults for parsing VidStreams
(Videos
FieldType) are set in this file. At a high-level, it is important that the dynamic variables (and associated data) parsed from your video file naming convention match up to those parsed from your Block
naming convention, or nigeLab
will not be able to associate the correct video files to your electrophysiological recordings. Click here for details about how to configure the relevant variables.
This package contains all the custom classes associated with Event
notifications issued by nigeLab
classes. Each file is a class that is a sub-class of the Matlab event.EventData
super-class. For a complete list of +evt
classes and their associated Event
notifications and sources, click here.
Library of "helper" classes for nigeLab
. The most important two are listed below. Click here for the full list of library classes.
Main GUI to visually interact with data linked via nigeLab
. Hopefully convenient for those who dislike the Command Window.
Core library class for storing and accessing data that is saved to a disk file. Essentially, this acts a pointer that allows nigeLab
to avoid loading too much data into RAM all at once. Click here for more details.
This is just a frivolous package that MM made to play notification sounds, such as the bell that rings when a job queued to a remote server is completed. Any modifications that make use of such notifications should make go here, in an attempt to try to keep the format similar for convenience. Specific details are here.
Functions and classes in +utils
include all of the open-source code that we have taken advantage of in building nigeLab
. Typically, instead of adding a helper function to a particular file, by convention that utility goes here, in case it needs to be used in some other "parallel" method as well (such as nigeLab.utils.initChannelStruct
). For a complete list of utilities, click here.
Functions in the +workflow package are used to make it easier to incorporate ad hoc workflows into the nigeLab
format. Custom code written to integrate your personal workflow into nigeLab
should go in this package. Handles to functions in this package can be assigned to fields of the Block
struct property, MatFileWorkflow
.
Functions belong to one of three core types (fields of MatFileWorkflow
): ReadFcn, ConvertFcn, or ExtractFcn. Any ad hoc function added to +workflow
should follow rules defined here.
There are three two additional sub-folders at this level: img, setup, and temp.
Contains all the beautiful images of Nigel himself! Also contains some images for documentation and poor attempts to animate Nigel's whiskers using real data. (Moved here on 2020-01-02)
Contains an installation script, as well as a demo script and associated (zipped) data from a short experimental recording.
Temporary files, such as those created during SPC go here.