lead.mis the main function that calls the apps
lead_group.m. Thus, by calling
lead dbsthe function calls lead_dbs.m
lead groupconnectome). The function is also called when exporting code instead of actually running code and when using a "submit" function to submit code from the cluster. So basically, anything related to single-patient/subject analyses will pass through
ea_write.m. All functions that process data on a single level (i.e. do not stem from
lead groupconnectome) branch off from
ea_autocoord. As a side note, the name stems from the very early days in which lead dbs was still called "eAuto" for electrode autolocalization. The same is true for the prefix (
ea_*) that we use in almost all functions.
optionsstruct that Lead-DBS uses to run jobs.
options.dicomimp.do == 1;to let
ea_autocoordknow to run the DICOM import module.
ea_elvis– thus if you study these two a bit, you'll get a good feeling about the overall pipeline.
lead connectome mapper.
ea_elvisis the main 3D output function (see above).
.ea_prefs.min the user's home directory that is derived from
ea_prefs_default.min the lead-DBS code directory. You can open the user's prefs directory by hitting command/strg+P from a main GUI. If you need to add a prefs entry, make sure to add it to both
ea_prefs_defaultand if needed to your own user prefs.
ea_prefs.mwill always combine entries from the two (if they are present in the user file, it will prefer these over the default prefs).
ea_prefs_default.matare analogous to the prefs text files (entry above) but more machine readable. That's why their content is stored in prefs.machine when calling
options.prefs.machinewhen in the main code somewhere).
optionsstruct for patient-specific entries. For many things, you need only this limited
optionsstruct together with