Common Issues

Common issues with ViNERS

This list was last updated 26 November 2021

Problem: During a call to models.nerve_anatomy (in the mesh_generation subfunctions), you receive error messages from GMSH followed by a MATLAB error, resembling the following:

Error   : Invalid boundary mesh (overlapping facets) on surface 1295 surface 1256
Error   : No elements in volume 61 62 63 64 65 66 859 861 862 864 865 866 867 868 869 870 871 872 873 874 875 
Info    : Done meshing 3D (Wall 1.63169s, CPU 1.5625s)
Info    : 50040 nodes 105581 elements
Error   : ------------------------------
Error   : Mesh generation error summary
Error   :     0 warnings
Error   :     2 errors (or more)
Error   : Check the full log for details
Error   : ------------------------------
Info    : Writing 'C:\Users\user\AppData\Local\Temp\pn-mdl-21080\nerve+array.msh'...
Info    : Done writing 'C:\Users\user\AppData\Local\Temp\pn-mdl-21080\nerve+array.msh'
Info    : Stopped on Thu Nov 25 22:24:55 2021 (From start: Wall 13.1811s, CPU 12.875s)
Reading "C:\Users\user\AppData\Local\Temp\pn-mdl-21080\nerve+array.msh"
 ...
Error: Index in position 2 exceeds array bounds.
...
Error in
models.nerve_anatomy>generate_nerve_mesh (line 572)
  m = mesh.make_gmsh_thinLayer(PN_mesh('.geo'), e.Perineurium_mm );
Error in models.nerve_anatomy (line 75)
  m = generate_nerve_mesh(get_,named, e);

Solution: This is most often caused by bad mesh geometry (e.g. a fascicle clipping through the electrode array). To visualize the input geometry for the mesh, cd(tools.cache) (see +tools.cache, then open nerve+array.geo in GMSH to view the generated input geometry to the mesh.

Most commonly, this issue is corrected by adjusting the -xMove / -xScale / -xRotate inputs to mesh.insert_gmsh_fascicles. The +plot utility +plots.preview_fascicles is also helpful here.

Problem: tools.cache('reset')

Error using rmdir: No directories were removed.
Error in tools.cache (line 67): rmdir(cachepath,'s');

Solution: Close any open files (e.g. a .geo file open in GMSH) and ensure that the MATLAB working directory is not in the directory you’re trying to remove (i.e. pwd is not in C:\Users\user\AppData\Local\Temp\pn-mdl-*\) before calling tools.cache.

Problem: Unrecognized function or variable 'ctfroot'. Error in tools.file (line ...)

Solution: This is an obsolete test to see if ViNERS is running in MATLAB or OCTAVE. If you are running MATLAB, replace isempty(strfind(ctfroot,'MATLAB')) %#ok<STREMP> with false. If you are running OCTAVE, replace isempty(strfind(ctfroot,'MATLAB')) %#ok<STREMP> with true. This issue can also be solved by installing the MATLAB compiler toolbox, or replacing with a call to tools.isOctave.

Problem: Error using tools.parse_arguments (line 132) expected positional argument 2: axons Error in models.axon_thresholds (line 35) % most other modules are similar to this [EM,AX] = tools.parse_arguments(varargin, 'LOAD', ...

Solution: Most model components require both an EIDORS fields definition file (either a sensitivity or a [stimulus] (Data/eidors_stimulus.mat) file and an axon population definition file.

In this example, I got this error with a call to models.axon_thresholds(opts,'-file', eidors_file). I was able to fix this issue by either defining opts.thresholds.axons = axons_file, or by changing the call to models.axon_thresholds(opts,'-file', eidors_file,'-axons', axons_file), or by changing the call to models.axon_thresholds(eidors_file, axons_file, opts). See also +tools.opts_to_args.

Problem:

Error using eidors_obj. 
Error in function test_install (line 145)
EIDORS not correctly started. Did you do ">>run /path/to/eidors/startup"? 

Solution: Something went wrong starting EIDORS. Try running tools.setupEIDORS. That should produce the following output:

EIDORS:[=== SETTING UP EIDORS version 3.9.1 ===]
EIDORS:[tested function eidors_var_id: OK]
 EIDORS:[Setting Default Colours]
EIDORS:[Installed EIDORS (Ver: 3.9.1)]
EIDORS:[Parameter: cache_size=1024 MB]
EIDORS:[Parameter: mapped_colour=127]
EIDORS:[Default background colour: white]
EIDORS:[EIDORS mex folder: C:/Users/user/Documents/MATLAB/EIDORS/eidors/arch/matlab]
EIDORS:[EIDORS cache folder: C:/Users/user/Documents/MATLAB/EIDORS/eidors/models/cache (must be writable)]
EIDORS:[EIDORS model cache: C:/Users/user/Documents/MATLAB/EIDORS/eidors/models/cache]
EIDORS:[New to EIDORS? Have a look at the Tutorials.]

If that output does not appear, try running eidors_startup, which should be located in the folder returned by tools.configuration('eidors') (see tools.configuration. If that fails still, tools.fix_eidors_overloads (new) is sometimes necessary depending on the versions of MATLAB and EIDORS (note: this modifies the EIDORS source code, please only run once). global eidors_objects may also give some insight into what is happening here.

Common issues with ViNERS experimental code

(note: this is largely peripheral to ViNERS itself, but is included here for completeness. Some of the solutions to these problems will require access to other resources e.g https://gitlab.unimelb.edu.au/ceiber/matlab-utilities)

Problem: Unrecognized function or variable expdir.

Solution: add the Utilities folder to the path or remove the call to expdir and replace it with the full path to the resource you are trying to access. The utilities folder is available on gitlab at https://gitlab.unimelb.edu.au/ceiber/matlab-utilities.

In order to work efficiently, routine tasks (file path handling, PDF generation, and some others) have been off-loaded to a series of simple utilities which lived in my local utilities folder (Documents/MATLAB/Utilities). The function expdir is an example of such a utility which provides a compact syntax for accessing a library of standardized file-paths across my systems. expdir is used in nearly every model run or analysis script, at a minimum to add ViNERS to the path and occasionally to access other resources.

If you are continuing development, I recommend maintaining the expdir system for your filesystem as I have found it very useful. For instance, if I have needed to move a resource, updating the path in expdir has the effect of preventing the need to update that path across hundreds of scripts. Many of the other utilities which I found most useful have been duplicated in the +tools folder of ViNERS, e.g. tidyPlotForIllustrator is provided as tools.tidyPlot.

Problem: Unable to resolve the name tools.file.

Solution: Add ViNERS to your path. If you have expdir, path(path,expdir('ViNERS')) will do the trick. See +tools.file for more information.

Problem: Error using expdir (line 120) CE-20****** not found in Experiment folders.

Solution: Replace the call to expdir with the full path to the required resource, or update expdir.

The resource you are trying to access has been moved, or you are using expdir on a system for which it no longer has the correct paths to the required resources.   Problem: Error using load: Unable to read file '../data/missingFile.mat'. No such file or directory.

Solution: Update the code to the current path to the resource.

Many filenames and filepaths were changed during the process of experiment curation and archival. The most common changes are renaming “results” to “derivative” (or “figures”) and “data” to “primary” (or “derivative”). In some places I have updated the code to point to these new locations but in general the code likely relies on old resource locations.

Note: many scripts iterate over files, using code like

list = dir('../data/filespec*.mat').

These scripts may not throw an error for missing files, but instead run and return nothing or generate empty figures. The underlying issue remains the same.

Problem: Error using tools.file>set_subject_ID (line 334)

Missing sub-*** in ~/primary, did you mean to call tools.make_SPARC_subject?
Error in tools.file (line 69)
      sub = set_subject_ID(info,varargin{:});

Solution: Update the code to the current subject/sample path to the resource.

Similar to the above issue, this relates to missing or moved data. In this case, in a call to tools.file('set', ... ) the requested subject path was not found in [ViNERS]/primary/. Most often, this is because the requested subject has been moved to [experiment]/primary/, but it is also possible that the experiment number has been changed for other reasons (e.g. different subjects folders have different numbers for instances of ViNERS on different platforms, or related work was grouped by sample or split by run). In many cases, solving this issue where tools.file('set') is called will make will fix all of the other tools.file path outputs. In the case of folders having been moved to [experiment]/primary/, replacing the subject in tools.file with '../primary/sub-...' (i.e. a local subject path) will work as long as the current version of ViNERS is on the path.

For experiments where subjects.xlsx is generative, it may be necessary to either update the subject/sample path specified in subjects.xlsx, or replace the call in the script a constant, valid subject/sample path.

tools.file('list') will list all subjects currently saved to [ViNERS]/primary/

IF you have multiple installations of ViNERS on your system, this issue can also arise if you have the wrong instance of ViNERS on your path. This can be tested by running cd(tools.file) and observing if the ViNERS path where you land is where you expected to land.