VECTORIZE is misleading and in most places refers to whether a mod file is thread safe

[nrnhines]

The nrn/src/nmodl occurrences of VECTORIZE and vectorize generally refer to whether mod files are thread safe and whether instances of mechanisms should be limited to existing in thread 0. The word was first introduced long ago to allow efficient simulation on a CRAY Y/MP (which had a pipeline size of 128). Prior to that, there was no Memb_list structure and memory for a mechanism instance was allocated on a Node by Node basis. Setup of the tree matrix involved

iterating over Nodes
  iterating over mechanisms in a node mechanism list
    calling the mechanism method (e.g. described by the  INITIAL, BREAKPOINT, SOLVE blocks) with args that specified the
      mechanism and Node data.

The introduction of the Memb_list structure along with its reorganization/construction function nrn/src/nrnoc/treeset.cpp:v_setup_vectors() more or less reversed the above order to

iterate over all mechanism types in use
  call the mechanism method with an arg that specifies the mechanism Memb_list stucture
    iterate over all instances of the mechanism. The Memb_list contains a list of Nodes  in the same order as the list of instance.

Subsequently over the years, this was refactored for use with CVODE and pthreads, and memory allocation/reallocation evolved into a complete AoS (Array of structure) memory layout that exists through NEURON version 8.

A review of occurrences of

cd nrn/src/nmodl
grep -n -r 'vectorize = 0'

can be summarized as

vectorize = 0 when

This is the only case which refers to whether the translated mod file uses pre/post Memb_list function prototypes.
./nocpout.cpp:232: SUFFIX nothing
I don't believe there is any reason to consider this a special case. nocmodl and new NMODL should be able to use a single prototype for all internal functions.

All the rest refer to whether a mod file can be considered thread safe
./nocpout.cpp:246: ARTIFICIAL_CELL that would require thread specific data.
./parse1.ypp:154: VERBATIM and not THREADSAFE
./parse1.ypp:413: VERBATIM and not THREADSAFE
./parse1.ypp:628: EXTDEF5 function and not THREADSAFE
./parsact.cpp:880: state_discontinuty function not thread safe in NET_RECEIVE
./parsact.cpp:1030: any call to threadsafe(message) gives notice if not THREADSAFE
./solve.cpp:174: SOLVE method is not thread safe Complain to Hines
./solve.cpp:192: KINETIC is thread safe only with METHOD sparse
./solve.cpp:208: NONLINEAR is not thread safe
./solve.cpp:216: LINEAR is not thread safe
./solve.cpp:224: DISCRETE is not thread safe
./solve.cpp:271: SOLVE with ERROR is not thread safe

./nocpout.cpp:1880:        threadsafe("Use of EXTERNAL is not thread safe.");
./nocpout.cpp:1887:        threadsafe("Use of POINTER is not thread safe.");
./nocpout.cpp:1894:        threadsafe("Use of BBCOREPOINTER is not thread safe.");
./nocpout.cpp:3197:  Assignment to GLOBAL unless THREADSAFE

So... "vectorize" should be eliminated when possible, and otherwise changed to something like "threadsafe" All remnants of pre Memb_list function prototype code generation should be eliminated.

This issue description should be edited to increase clarity.

[1uc]

@nrnhines I'd be happy to work on this from Wed onwards. Please let me know if you'd prefer to work in it yourself, so we don't both work on this.

[nrnhines]

@1uc Go ahead. I'll be spending this week at the ebrains workshop and won't be able to start working on it til next week.