Skip to content

nigeLab

Max-Home-Tower edited this page Jul 1, 2020 · 1 revision

+nigeLab

(Current as of: 2019-11-23)


Classes

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.

Tank

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.

Animal

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.

Block

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.


Sub-Packages

Contents


+defaults

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).

Block.m

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.

Events.m

This is where parameters are configured for members of the Events FieldType. Click here for details about how to configure the relevant variables.

Queue.m

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.

SD.m

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.

Video.m

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.


+evt

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.


+libs

Library of "helper" classes for nigeLab. The most important two are listed below. Click here for the full list of library classes.

DashBoard

Main GUI to visually interact with data linked via nigeLab. Hopefully convenient for those who dislike the Command Window.

DiskData

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.


+sounds

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.


+utils

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.


+workflow

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.


Other

There are three two additional sub-folders at this level: img, setup, and temp.

img

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)

setup

Contains an installation script, as well as a demo script and associated (zipped) data from a short experimental recording.

temp

Temporary files, such as those created during SPC go here.

Clone this wiki locally