I am currently working on a change that would make function declarations not require a type.

E.g. something like

a mS
b mS
function foo = a + b

would assume (and install) the type of mS for the (alias) function foo.

Here is where I need your input:
Since these function declarations are grammatically the same as regular variable declarations (i.e. defined by the same rule) it would be rather straightforward to install the same changes for regular variables.

However, at that point it becomes no longer possible to discern between a declaration and an assignment in the update block where both can occur:

state:
    a mS
    b mS 
end

...

update:
    c = a + b #this is parsed as an assignment, when it should be a declaration
end

One easy solution for this would be to change the syntax for declarations to expect := instead of a simple =

Since @heplesser has in the past inquired about making types optional for varialbes, I judged this to be a good time to get everyones feedback on this.

@DimitriPlotnikov @jougs @Silmathoron

Hello
I manage to do ./nestml_docker.sh provision, but with sudo. Otherwise I get "Cannot connect to the Docker daemon. Is the docker daemon running on this host?"
by "sudo docker images" I check there is "nestml_release latest "
Then, I try "sudo ./nestml_docker.sh run /home/claudia/workspace/nestml/models"
but I get
"Running docker image 'nestml_release'
adduser: uid '0' in use
sudo: unknown user: nestml
sudo: unable to initialize policy plugin
"

Can you help me please?!

thanks!!

• Generate CMakeLists.txt for the model integration into the latest NEST version

Hello,
there seems to be a problem with the processing of combined units, e.g. mV/ms. Currently, when parsing a model with such a unit, only the mV part is considered, while information about ms is dropped. A model which contains such a combined unit is, for example, aeif_cond_alpha. @PTraeder , it seems that you are working on this part of the framework, could you please explain if it is an error or some mistake on my side.

Instead of calling steps(timeInMs) function to get number of ticks for given time constant, add a language mechanism to handle it

neuron iaf_neuron_nestml:
  parameter:
    t_ref   refractory_time = 2ms     # Refractory period.
  end
  update:
     if is_refractory(): # not refractory
        integrate(V)
        if V >= Theta: # threshold crossing
          set_refractory(2ms) # set_refractory(t_ref)
          V = V_reset
        emit_spike()
    end
  end
end

Since #348 it is possible to write 1 ms as shorthand for 1*ms.
Additionally, predefined variables for each unit have been registered, so that notations like foo/ms or 1 ms * mV have become possible.
In the case foo/ms the factor 1 is implied for the ms unit.

@jougs and @heplesser expressed that they would like to see literals in front of every unit.
I have some questions regarding this:

A verbose interpretation of this demand could look like:
1 ms / (1 mV * 1 nS) vs. ms/(mv*nS)
foo * 1 nS vs. foo * nS
foo / 1 nS vs. foo / nS
1 nS * foo vs. nS * foo
1 nS / foo vs. nS / foo

I have concerns regarding the legibility of the first case in large expressions.
An alternative could be that we only require one literal per "compound unit", where a compound unit would be a factor in an expression that consists only of units, e.g.:
1 ms/(mV*nS)

Which version, if any, would you prefer?

Are there any other conventions wrt. notation of units that you would like to see?

Also would you like to see some form warning if the conventions we agree upon are breached?

First of all thank you for this product. I hope it can help in my endeavors.

mvn clean install

gives on the latest master

Failed tests: 
  SymPySolverTest.test_iaf_psc_alpha:54 expected:<[success]> but was:<[failed]>
  SymPySolverTest.test_iaf_psc_exp:61 expected:<[success]> but was:<[failed]>
  EquationsBlockProcessorTest.test_psc_model:64 null

Tests run: 109, Failures: 3, Errors: 0, Skipped: 0

The fix for me was to use python2.7

Receive an error at the stage of make: error: ‘t’ was not declared in this scope. A detailed stacktrace:

/home/vogdb/workspace/xxx/neuron-intfire-nestml/build/izhikevich_neuron.cpp: In member function ‘virtual void izhikevich_neuron::update(const nest::Time&, long int, long int)’:
/home/vogdb/workspace/xxx/neuron-intfire-nestml/build/izhikevich_neuron.cpp:345:3: error: ‘t’ was not declared in this scope
   t;

However docs mention that

update: inside this block the current time can be accessed via the variable t

The last version where it works is 1.4.4.

There are several minor problems with the provided models:
In iaf_chxk_2008.nestml:
Buffers are called with their plural form (spikes instead of spike), while in other models singular (e.g. iaf_cond_beta)

In iaf_cond_beta_neuron:
The differential variables are named with capital letters (intended?).

In iaf_cond_exp_sfa_rr:
Buffers are called with their plural form (spikes instead of spike), while in other models singular (e.g. iaf_cond_beta).

In izhikevich_psc_alpha:
Buffers are called with their plural form (spikes instead of spike), while in other models singular (e.g. iaf_cond_beta)

In terub_neuron_gpe:
Problems with the correct dimensionality: The I_ex_mod function is declared with type real, right-hand side consists of pA*mV. The same problem with tau_n and some others.

While the naming stuff is not that critical (although cumbersome), the problem of correct dimensions leads to crucial problems (especially in the backend, where correct dimensionality is assumed). @PTraeder would you take a look at this?

Try to print the humanreadalbe form of the SI type, if unambiguously possible.
E.g.
NESTML_ALIAS_HAS_NO_SETTER:NESTML_ALIAS_HAS_NO_SETTER:Alias-variable 'V_m' needs a setter-function: set_V_m(v [0, -3, 2, 1, 0, 0, -1, -3]) at <78,4>
Should be:
set_V_m(v mV)

It's me again. I hope you won't put me into a blacklist of the project :)

I'm implementing a custom HH model from a Neuron simulator implementation. Somehow gating particles Act_m and Inact_n change their amplitude periodically. Act_h behaves fine. For example here how Inact_n behaves in Neuron.

In Nest it differs

The implementation is here https://github.com/vogdb/neuron-vs-nest/blob/master/neuron_vs_nest/custom_hh/nest/custom_hh_model/custom_hh.nestml . Its Neuron simulator counterpart is here
https://github.com/vogdb/neuron-vs-nest/blob/master/neuron_vs_nest/custom_hh/neuron/custom_hh.mod

As a part of #358 all languages in NESTML are defined in the same grammar. Thus, the project structure become more clear and comprehensible. @PTraeder: update your fork and branches asap to the latest state.

There is still one issue: integration of the current literals-grammar into the NESTML-grammar leads to seldom parsing errors. It look as if redefinition of the SL_COMMENT is ignored.

• Use NEST code convention for the formatting

Script should append the name of the neuron to the output. Otherwise, artifacts computed in the previous neuron can accidentally used, if the computation for the current model fails.

This is really just some kind of a bonus, but I'm not a great fan of Emacs, so I was wondering how difficult it would be to provide a Scintilla lexer for NestML, which would provide people working with it or Geany get the exact syntax highlighting when working on .nestml files.

I want to make some tests with the Hodgkin-Huxley neuron model using NESTML and therefore looked at the NESTML implementation available in the repository.
I noticed that there are two different implementations, hh_psc_alpha.nestml and hh_psc_alpha_implicit.nestml.
A simple comparison with the original implementation in the NEST master revealed that only the implicit version reproduces the behavior of the original implementation.
I attached a small reproducer script and the produced plot. The script expects the nestml models to be encapsulated in a module called hh_psc_alpha_nestml. Just rename the script from *.txt to *.py.
hh_simple_test.pdf
hh_simple_test.txt

Is this a known behavior? The difference seems to be in the calculation of synaptic input currents in the model. Do you know, why only the implicit version reproduces the original behavior?
Shouldn't this be at least marked in the file?

Test to reproduce: org.nest.integration.NestmlFrontendIntegrationTest#testTutorialModels

Produces the following warnings:
32_rc_alpha : WARNING: NESTML_ODEPostProcessingVisitorType of (derived) variable g_ex'' is: A * s**-1 * Ts**-1. This doesnt match Type of RHS expression: A * s**-1 * Gs**-1 at: 32_rc_alpha.nestml:<14,4>
I would like to clarify 2 questions

1. I don't understand the meaning of the term s**-1 * Gs**-1. Both are seconds?
2. How should the equation look like to be accepted
3. Should we make the type checking parameterizable in the sense that magnitude check (only the type signature without is considered) can be turned off?

@PTraeder what is you opinion?

As part of #354 the command line interface was extended to support different options. E.g.:
NESTML hast following options. I invite to test and review it: @jougs and @steffengraber.

usage: The NESTML command line tool can be used as 'java -jar nestml.jar
           <options> path_to_models'. Valid options are listed below:
 -d,--dry-run             Use this option to execute the model analysis
                          only.
 -e,--enable_tracing      Enables tracing of templates which were used to
                          generate C++ code. It can be used for debugging
                          purporses.
 -h,--help                Prints this message.
 -j,--json_log <arg>      Defines the name of the file where the model log
                          will be stored in JSON format.
 -m,--module_name <arg>   Defines the name of nest module which is
                          generated with neuron models. Under thisname the
                          module can be installed in SLI/PyNEST.
 -t,--target <arg>        Defines the path where generated artifacts are
                          stored. The only argument determines the folder
                          where the generated code is stored. E.g.
                          --target ~/my_path

Regarding the json output. If the file doesn't have a .log extension, it is appended automatically by the NESTML-tool. You are welcomed to ask for any additional information I should add to the JSON file (input, output folders, version of the NESTML tool, ...). I just wanted to add only necessary information.

Several example outputs in the case of an error or warning:

1. There is a parse error (in this case the neuron name entry is empty since the model structurally invalid. the tool doesn't create an AST)

[ {
  "filename" : "cli_example.nestml",
  "neuronName" : "",
  "severity" : "ERROR",
  "code" : "NESTML_PARSER",
  "row" : 3,
  "col" : 7,
  "message" : "missing ':' at '\\n'"
} ]

2. Context condition violations (errors and warnings):
   [ {
   "filename" : "sub_example.nestml",
   "neuronName" : "iaf_cond_alpha_implicit",
   "severity" : "WARNING",
   "code" : "SPL_LINE_OPERATOR_VISITOR",
   "row" : 15,
   "col" : 10,
   "message" : "Addition/substraction of real and 1 / ms. Assuming: 1 / ms.(<15,10>)"
   }, {
   "filename" : "sub_example.nestml",
   "neuronName" : "iaf_cond_alpha_implicit",
   "severity" : "WARNING",
   "code" : "SPL_LINE_OPERATOR_VISITOR",
   "row" : 17,
   "col" : 10,
   "message" : "Addition/substraction of real and 1 / ms. Assuming: 1 / ms.(<17,10>)"
   }, {
   "filename" : "sub_example.nestml",
   "neuronName" : "iaf_cond_alpha_implicit",
   "severity" : "WARNING",
   "code" : "SPL_LINE_OPERATOR_VISITOR",
   "row" : 18,
   "col" : 35,
   "message" : "Addition/substraction of real and mV. Assuming: mV.(<18,35>)"
   }]

Greetings everyone,

I have successfully installed and used NESTML in my personal computer, but as I want to try new simulations of my model in our laboratory's cluster, I was thinking whether it was possible to do so without installing NESTML on said computer and re-compiling everything.

I have tried so but, and after cmake / make / make install (with no errors), I tried to load my model both in SLI and PyNEST and I get an error as the following:

Nov 17 15:04:25 Install [Error]: DynamicModuleManagementError
Module 'mat2_cond_exp' could not be opened.
The dynamic loader returned the following error: 'file not found'.

Please check LD_LIBRARY_PATH (OSX: DYLD_LIBRARY_PATH)!

Now, my nest_vars.sh is already exporting my user model directory (export NEST_MODULE_PATH=$NEST_INSTALL_DIR/lib64/nest), and I've also manually added that directory to LD_LIBRARY_PATH without success. As expected, this directory includes two files: libmat2_cond_exp.so and mat2_cond_exp.so.

After trying many different things, I wondered whether during compilation, NESTML uses the paths of the current PC/current NEST installation to index something in the compiled code, and if a conflict could be occurring when I copied only the build folder to a new PC and tried to run it there.

Thank you very much for your attention.

P.S.: Besides avoiding the process of installing NESTML everywhere I want to use it, I am particularly interested in this topic because as I want to share my studies in the future, I don't want to force prospective users to install both NEST and NESTML, as the latter's installation is not trivial currently

Is there the same in NestML? For example in Nernst equation we use constants as R(gas constant), F(faraday constant). Now we need to state their exact units which are enormous although these are used only in Nernst equation. In Neuron we can escape this by putting the equation inside UnitsOff block.
Btw I'm not proposing it. I'm just asking.

For implicit alpha-shaped functions, we need to initialize the derivative.
However, currently:

I_ex' pA/ms = 0. pA/ms

or

g_ex' nS/ms = 0. nS/ms

Leads to the following error:

ERROR: The artifact is unparsable: <Optional[aeif_cond_alpha_implicit.nestml:<40,8>]>: extraneous input ''' expecting {'void', 'boolean', 'integer', 'real', 'string', '(', ',', '-', Name, Num_Int}

In order to make shape declarations more generic and re-usable, I think it would be nice to support a new notation in addition to the existing notation. The new notation should allow to parametrize the shape with one or more variables. Here is an example of what this could look like:

equations:
  shape alpha<tau> = (e / tau) * t * exp( -t / tau)
  function I_syn_ex pA = convolve(alpha<tau_syn_ex>, spikes_ex)
  function I_syn_in pA = convolve(alpha<tau_syn_in>, spikes_in)
  V_m' = - (I_syn_ex + I_syn_in) / C_m

@ingablundell, @DimitriPlotnikov, @Silmathoron

With latest master, docker installation runs fine, but when using docker run [options] nestml_release, I get the following error:

adduser: invalid number '-D'
sudo: unknown user: nestml
sudo: unable to initialize policy plugin

I guess the nestml user was not created, but I have no idea what went wrong... my guess is that it's the $UID in entrypoint.sh but I'm not sure.
I manually changed it to adduser -D nestml, which seems to work.

Docker: 1.12.3
System: Manjaro (Arch-based)

As previously discussed, the current code automatically converts variables of e.g. type s to the respective NEST unit (here: ms).

This is fine for expressions that directly resolve to a higher/lower magnitude of one of the defined "neuroscience" units:
nS, Gohm, ms, pF, mV, pA

In the generated code, NESTML variables of e.g. type s are then subject to a factor of 1000 to convert the runtime value in seconds to the corresponding amount of milliseconds.
At the same time, a NESTML variables of type ns would, in the corresponding C++ code, be multiplied by 0.000001.

However a variable of e.g. type coulomb (C= s*A) would not be subject to such a conversion since no "neuroscience" target is defined for coulomb. In my understanding it should be subject to a conversion, in this case we could simply multiply the factors for each of the constituting SI base units (s and A) which would result in 10^3 * 10^12. While this would be a solution, it does not make much sense to me.

Should we handle units like coulomb, newton, etc which are not themselves "neuroscience" units in any way?
@heplesser @jougs @DimitriPlotnikov @Silmathoron

Currently, there are some problems with _sum functions in NESTML:

• spikes.get_sum() delivers pA, whereas it should deliver real
• cond_sum seems not to deliver nS (I don't know what it does)
• neither does curr_sum() seem to deliver pA

Maybe I should be more explicit about the first problem:

• we use normalization functions for the alpha model to make sure the peak is at 1 pA times the "synaptic weight" (dimensionless)
• for _exp models, the dimensionless property can either be handled by the Unit+primitive=unit property of #317 or if we treat dimension mismatches as errors, the user will have to specify by hand g += 1 nS * spikes.get_sum()

Hello,

I tried installing pynestML (both the master and pynestml branches) in a virtualenv using the following commands:

python3 setup.py install --prefix=/Users/Tom/.virtualenvs/nestml/
pip3 install -r requirements.py

The tests run well except a warning saying that PyGSL is not available. However I run into errors when trying to generate some of the test models.

Some of the models (hh_psc_alpha, izhikevich, ...) give me type errors.

python3 pynesTML.py -path models/izhikevich_psc_alpha.nestml -target ../nestml-testdir
Warning: PyGSL is not available. The stiffness test will be skipped.
Warning: No module named 'pygsl'


Generates code for the neuron izhikevich_psc_alpha.
Validating input...
Analyzing shapes...
  I_syn_in is a linear homogeneous ODE
  I_syn_ex is a linear homogeneous ODE
Only shapes provided. Return ODE representation with IV.
Generates code for the neuron izhikevich_psc_alpha_implicit.
[35,izhikevich_psc_alpha_implicit, ERROR, <ADDED_BY_SOLVER>]: Actual type different from expected. Expected: 'pA', got: 'integer'!
[36,izhikevich_psc_alpha_implicit, ERROR, <ADDED_BY_SOLVER>]: Actual type different from expected. Expected: 'pA / ms', got: 'integer'!
[37,izhikevich_psc_alpha_implicit, ERROR, <ADDED_BY_SOLVER>]: Actual type different from expected. Expected: 'pA', got: 'integer'!
[38,izhikevich_psc_alpha_implicit, ERROR, <ADDED_BY_SOLVER>]: Actual type different from expected. Expected: 'pA / ms', got: 'integer'!

The ht_neuron model gives me other errors (it seems the syntax is not recognized)

python3 pynesTML.py -path models/ht_neuron.nestml -target ../nestml-testdir
Warning: PyGSL is not available. The stiffness test will be skipped.
Warning: No module named 'pygsl'


[13,ht_neuron_nestml, ERROR, [87:16;87:16]]: Variable 'I_Na' used before declaration!
[14,ht_neuron_nestml, ERROR, [87:23;87:23]]: Variable 'I_K' used before declaration!
[31,ht_neuron_nestml, ERROR, [55:4;55:4]]: Function variable 'g_AMPA' has no right-hand side!
[32,ht_neuron_nestml, ERROR, [55:4;55:4]]: Initial value of ode variable 'g_AMPA' not provided!
[33,ht_neuron_nestml, ERROR, [55:12;55:12]]: Function variable 'g_NMDA' has no right-hand side!
[34,ht_neuron_nestml, ERROR, [55:12;55:12]]: Initial value of ode variable 'g_NMDA' not provided!
[35,ht_neuron_nestml, ERROR, [55:20;55:20]]: Function variable 'g_GABAA' has no right-hand side!
[36,ht_neuron_nestml, ERROR, [55:20;55:20]]: Initial value of ode variable 'g_GABAA' not provided!
[37,ht_neuron_nestml, ERROR, [55:29;55:29]]: Function variable 'g_GABAB' has no right-hand side!
[38,ht_neuron_nestml, ERROR, [55:29;55:29]]: Initial value of ode variable 'g_GABAB' not provided!
[39,ht_neuron_nestml, ERROR, [55:38;55:38]]: Function variable 'IKNa_D' has no right-hand side!
[40,ht_neuron_nestml, ERROR, [55:38;55:38]]: Initial value of ode variable 'IKNa_D' not provided!
[41,ht_neuron_nestml, ERROR, [55:46;55:46]]: Function variable 'IT_m' has no right-hand side!
[42,ht_neuron_nestml, ERROR, [55:46;55:46]]: Initial value of ode variable 'IT_m' not provided!
[43,ht_neuron_nestml, ERROR, [55:52;55:52]]: Function variable 'IT_h' has no right-hand side!
[44,ht_neuron_nestml, ERROR, [55:52;55:52]]: Initial value of ode variable 'IT_h' not provided!
[45,ht_neuron_nestml, ERROR, [55:58;55:58]]: Function variable 'Ih_m' has no right-hand side!
[46,ht_neuron_nestml, ERROR, [55:58;55:58]]: Initial value of ode variable 'Ih_m' not provided!
[47,ht_neuron_nestml, ERROR, [56:4;56:10]]: Function variable 'g_AMPA__d' has no right-hand side!
[48,ht_neuron_nestml, ERROR, [56:4;56:10]]: Initial value of ode variable 'g_AMPA__d' not provided!
[49,ht_neuron_nestml, ERROR, [56:13;56:19]]: Function variable 'g_NMDA__d' has no right-hand side!
[50,ht_neuron_nestml, ERROR, [56:13;56:19]]: Initial value of ode variable 'g_NMDA__d' not provided!
[51,ht_neuron_nestml, ERROR, [56:22;56:29]]: Function variable 'g_GABAA__d' has no right-hand side!
[52,ht_neuron_nestml, ERROR, [56:22;56:29]]: Initial value of ode variable 'g_GABAA__d' not provided!
[53,ht_neuron_nestml, ERROR, [56:32;56:39]]: Function variable 'g_GABAB__d' has no right-hand side!
[54,ht_neuron_nestml, ERROR, [56:32;56:39]]: Initial value of ode variable 'g_GABAB__d' not provided!

Am I doing something wrong? Are we supposed to use the java/docker releases of nestML (which I have trouble installing)?
Thanks,
Tom

exp, alpha, delta

Currently, invariants in NESTML models are defined at the end of declarations double square braces, e.g.

V_m mV = -70 [[V_m > -100 and V_m <= 0]]

This notation is confusing and error prone (intuitively the constraint is useless, since V_m has the value -70 (user feedback))

invariants:
  -90 <= V_m <= 0 # This is an invariant. It is in-forced at anytime
  gls_err_tol > 0 # this is a guard. it is checked in SetStatus-call only.
end

Invariants should enforce state variables to be in the range during simulation (e.g. STATE_VAR is actively set to its lower or upper bound). Syntactically an invariant is always of the form lower_bound < STATE_VAR< upper_bound. An exception is thrown in SetStatus, if a value s being set is out of the range.

Guards is an arbitrary boolean expression (just an example) E_in + E_ex <= 42.. It can only be checked. Guards can be defined for all variables/expression, but they are checked only in SetStatus.

Currently, there seems to be a problem with the middleware which is responsible for solving of shapes. Whenever we hand in a model containing a shape, e.g.
shape g_ex = (e/tau_syn_ex) * t * exp(-1/tau_syn_ex*t)
it is resolved to a state variable g_in without any dimension but the primitive data type real. This problem leads to wrongly typed expressions, e.g.
function I_syn_exc pA = cond_sum(g_ex, spikeExc)*(V_m-E_ex)
where the left-hand side is pA, while the right-hand side is mV.

The goal of this discussion is to define a list with "neuroscience" magnitudes of SI in NEST/NESTML. E.g. all variables in NESTML models of the SI unit will be automatically converted to a proper magnitued during the NEST code generation workflow. The current status is. @Silmathoron, @heplesser. @PTraeder: can you update/extend the list since you know what is really supported.

milli seconds - ms
pico farad   - pF
milli volt    - mV
pico ampere  - pA
nano siemens - nS
mega ohm     - MOhm

Hi, dear Nestml contributors. Please share your wisdom when you have a spare minute.

I want to implement a simple model of IAF neuron from Neuron simulator: IntFire1
It has a very simple math.

• When it does not receive any input it decreases its voltage according to this:

  V_1 = V_0 * exp(-(t_1 - t_0)/tau), V_0 - previous value of voltage, V_1 - new value of voltage.
  

• When it receives a spike, it just adds its weight

  V = V + spikes
  

What block would be appropriate to choose? Would be update enough? I can't access t there. Also I can't access t in equations directly, only as a part of shape.

This was formerly known as nest/nest-simulator#248 and before that as nest.trac.577

GetStatus and SetStatus are complementary functions and it is reasonable to expect that the result of GetStatus can be used as input to SetStatus:

nest.SetStatus(nodes, nest.GetStatus(nodes))
nest.SetDefaults(model, nest.GetDefaults(model))

should work. Currently, it does not work (for almost all models). One reason for this is that GetStatus returns a number of read-only values; when these are sent to SetStatus, they are not read out and an UnaccessedDictionaryItem exception is raised.

Note: SetStatus does not provide a full reset!

old_status = nest.GetStatus(nodes)
... do something ...
nest.SetStatus(nodes, old_status)

will not fully reset the nodes, since SetStatus does not change the contents of buffers for incoming spikes and possibly other variables representing the history of the neuron.

Test to reproduce: org.nest.integration.NestmlFrontendIntegrationTest#testTutorialModels
Issue:
32_rc_alpha : WARNING: NESTML_LITERALS_MUST_HAVE_TYPES: Assignment of a literal to a UNIT type variable must carry a Unit Symbol at 32_rc_alpha.nestml:<56,4>

@PTraeder Can you fix the type of the variable PSConInit_E (line 34) s.t. the assignment at line 56 becomes correct?

Users easily make spelling mistakes when specifying parameters for models in SetStatus calls. It is therefore important that NEST checks that all keys in the dictionary are valid names of parameters or state variables that can be set in a model or model instance.

NEST currently does this by setting an "accessed" flag in the SLI dictionary token when a value is read out and then checks at the end whether all parameters have been read (had their "accessed" flag set). This has three disadvantages:

• It is inefficient, especially when the same dictionary is passed to many instances.
• An illegal name will be detected only after all legal parameters have been changed on all instances.
• It is not entirely deterministic in threaded contexts (see NEST PR 725).

The main reason for the current solution is that NEST cannot introspect models to discover legal parameter names. NESTML on the other hand can know all legal names of modifiable quantities and could thus implement a direct check on dictionary keys, removing the need to maintain accessed flags.

I thus propose to implement such name checking as part of NESTML code generation.

Hi! I'm trying to implement a dual exponential waveform of synaptic conductance that looks like:

some_constant * (exp(-t/tau1) - exp(-t/tau2))

I'm doing this in the equations block.

shape I_shape_in = pA * tau_syn_in * (exp(-1/tau_syn_in_fall*t) - exp(-1/tau_syn_in_rise*t))
function I_syn pA = convolve(I_shape_in, in_spikes) + convolve(I_shape_ex, ex_spikes) + I_e + currents

receive an error:

/home/vogdb/workspace/xxx/neuron-intfire-nestml/build/int_fire4.cpp: In member function ‘virtual void int_fire4::update(const nest::Time&, long int, long int)’:
/home/vogdb/workspace/xxx/neuron-intfire-nestml/build/int_fire4.cpp:272:7: error: ‘__t’ was not declared in this scope
       __t = 0;
       ^

The current solution I use is to split this declaration into two shape functions. Is it correct?

    shape I_shape_in_rise = pA * tau_syn_in * -exp(-1/tau_syn_in_rise*t)
    shape I_shape_in_fall = pA * tau_syn_in * exp(-1/tau_syn_in_fall*t)
    function I_syn pA = convolve(I_shape_in_rise, in_spikes) + convolve(I_shape_in_fall, in_spikes) + convolve(I_shape_ex, ex_spikes) + I_e + currents

Full model description:

neuron int_fire4:

  state:
    r integer # counts number of tick during the refractory period
  end

  initial_values:
    V_m mV = 0mV
  end

  equations:
    shape I_shape_ex = pA * exp(-1/tau_syn_ex*t)
    shape I_shape_in = pA * tau_syn_in * (exp(-1/tau_syn_in_fall*t) - exp(-1/tau_syn_in_rise*t))
    function I_syn pA = convolve(I_shape_in, in_spikes) + convolve(I_shape_ex, ex_spikes) + I_e + currents
    V_m' = -1/tau_m * V_m + 1/1pF * I_syn
  end

  parameters:
    tau_m            ms = 10ms # Membrane time constant.
    tau_syn_in_rise  ms = 2ms  # Time constant of inhibitory synaptic current. Rise phase.
    tau_syn_in_fall  ms = 2ms  # Time constant of inhibitory synaptic current. Fall phase.
    tau_syn_ex       ms = 2ms  # Time constant of excitatory synaptic current.
    t_ref            ms = 2ms  # Duration of refractory period
    V_reset          mV = 0mV  # reset value of the membrane potential
    V_threshold      mV = 1mV  # Threshold value of V_m for spike
    I_e              pA = 0pA  # External current.
  end

  internals:
    RefractoryCounts integer = steps(t_ref) # refractory time in steps
    tau_syn_in real = tau_syn_in_rise * tau_syn_in_fall / (tau_syn_in_fall - tau_syn_in_rise)
  end

  input:
    ex_spikes pA <- excitatory spike
    in_spikes pA <- inhibitory spike
    currents    <- current
  end

  output: spike

  update:
    if r == 0: # neuron not refractory
      integrate_odes()
    else: # neuron is absolute refractory
      r = r - 1
    end

    if V_m >= V_threshold: # threshold crossing
      r = RefractoryCounts
      V_m = V_reset
      emit_spike()
    end

  end

end

Hi! I created a model in NESTML, compiled and installed it and then went through the C++ code for modifying the synapses. I compiled the new model in NESTML (and I got no errors), but when installing it in PyNEST (through nest.Install("models")), I get a "segmentation fault" error related to my new model. The problem is that I keep on getting the error on the same model even if I go back to the previous version without synaptic input that was working.
Do you know what this could depend on?
Thanks!!!
Alice

Hi,
I am having problem with defining a variable in my nestml script. In the attached file, I define the variable H which essentially represents the output of the Heaviside function. Its value is computed in every update step in the update block. So, I though that I have to initialize this variable in the state block, as done in the attached file. However, nestml then complains that

The variable H is defined multiple times.

If I remove the line initializing H in the state block, nestml does not complain.
However, when I then try to compile the generated c++ Files, the compiler complains that

error: 'H' was not declared in this scope`

I also tried putting the initialization of H in the initials block but this does not work either. What is the correct way to go?

teste.txt

In mat2_psc_exp.nestml, current implementation leads to the following error:

mat2_psc_exp : WARNING: SPL_ILLEGAL_EXPRESSION <118,4> : Attempting to assign real to variable V_th_alpha_1 with type mV
mat2_psc_exp : WARNING: SPL_ILLEGAL_EXPRESSION <119,4> : Attempting to assign real to variable V_th_alpha_2 with type mV

which corresponds to lines

V_th_alpha_1 *= P11th
V_th_alpha_2 *= P22th

Which seems to mean (given that both P11th and P22th are of type real) that unit check for *= is not handled correctly

Can we use E_L mV = -55 instead of E_L mV = -55mV?
Now I have a problem with Ideal Gas Constant R in parameters block:

  parameters:
    t_ref ms = 2.0ms         # Refractory period
    ...
    R_const (kg*m**2)/(s**2*K*mol) = 8.314472[(kg*m**2)/(s**2*K*mol)]
  end

I receive an error

[ {
  "filename" : "hh_moto_5ht.nestml",
  "neuronName" : "",
  "severity" : "ERROR",
  "code" : "NESTML_PARSER",
  "row" : 121,
  "col" : 42,
  "message" : "mismatched input '[' expecting {'end', 'and', 'or', 'recordable', 'function', '**', '<<', '>>', '<=', '<>', '^', '==', '[[', '%', '&', '*', '+', '-', '/', '|', '<', '!=', '>', '>=', '?', Name, NEWLINE}"
} ]

I don't receive an error in either of cases below

  parameters:
    R_const (kg*m**2)/(s**2*K*mol) = 8.314472 * ((kg*m**2)/(s**2*K*mol))
  end

  parameters:
    R_const (kg*m**2)/(s**2*K*mol) = 8.314472
  end

It's not a serious issue. I just wanted to give some feedback. I couldn't make the docker container to provision.

sudo ./nestml_docker.sh provision

The latest master just hangs infinitely on the step:

(10/11) Installing python (2.7.12-r0)

The version 2.1.0 hangs on the step:

(2/4) Installing clang-libs (3.8.0-r0)

My setup is Ubuntu 16.04 guest on VirtualBox with Mac host. I was able to install the latest master from sources with Maven though. If there is a way to extract verbose logs from provisioning, I would gladly provide them.

Since the LHS of an ODE can be typed "dynamically" to some extend ( magnitude information can be modified depending on the defining ODE) it might be sensible to create symbols for each and every occurring differential order of a given variable, not just all but the highest one.

This would help me shut up the warnings from issue#291 in cases where a suitable type can be inferred.
Otherwise a switch for typechecks that ignores magnitude is the only option.

@DimitriPlotnikov What do you think?

Hi,

I am trying to compile a neuron model with two state variables. I initialize the state variables in an initial_values block and then define their time evolution in an equations block. I then expected these state variables to appear in the Status Dictionary of the neuron model in PyNEST. That is, I would like to set their value manually by executing
SetStatus(neuron, {'v': -60., 'g_k': 0.})

However, the state variables do not appear in the status dictionary when I call
GetStatus(neuron) and I cannot set them using the command above, and I receive the usual error message

NESTError: DictError in SetStatus_id: Unused dictionary items: v g_k

Do I have to define these state variables differently or how does this work?
Thanks.

We are planning to add typing to buffers.
Current buffers are intended to carry the type pA.
Concerning spike buffers, we would like to have feedback for types you consider probable/useful.
For example, would you like to see just a specific subset of units? All of the "native" NEST units?
Compound units such as mV/ms? Primitive types?

Additionally, your ideas about possible syntax for these types would be welcome.

Currently buffers are defined thusly:

bufferName <- (inhibitory | exitatory)* (spike | current) 

My proposition, in accordance with suggestions made by @heplesser, would be to simply add the respective type after the buffer name. Similarly to variable definitions.

someBuffer1 mV  <- exitatory spike 
someBuffer2 nS  <- exitatory spike 

for a buffer of type ms.

I am trying to compile a NESTML (attached) using the Python branch PyNestML with the following command:
python3 PyNestML.py -path macgregor_neuron/.

teste.txt
However, I receive the following error message, which I cannot make sense of:

File "PyNestML.py", line 28, in
main(sys.argv[1:])
File "/home/schmidt/opt/nest/nestml/pynestml/frontend/PyNestMLFrontend.py", line 50, in main
parsedUnit = ModelParser.parseModel(file)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelParser.py", line 68, in parseModel
ASTSymbolTableVisitor.ASTSymbolTableVisitor.updateSymbolTable(neuron)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTSymbolTableVisitor.py", line 57, in updateSymbolTable
ASTSymbolTableVisitor.visitNeuron(_astNeuron)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTSymbolTableVisitor.py", line 88, in visitNeuron
CoCosManager.postSymbolTableBuilderChecks(_neuron)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/CoCosManager.py", line 490, in postSymbolTableBuilderChecks
cls.checkExpressionCorrect(_neuron)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/CoCosManager.py", line 437, in checkExpressionCorrect
cls.__expressionCorrect(_neuron)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/CoCoIllegalExpression.py", line 43, in checkCoCo
_neuron.accept(CorrectExpressionVisitor())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 899, in traverse
self.traverseNeuron(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1228, in traverseNeuron
_node.getBody().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 842, in traverse
self.traverseBody(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1092, in traverseBody
subnode.accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 932, in traverse
self.traverseUpdateBlock(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1300, in traverseUpdateBlock
_node.getBlock().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 836, in traverse
self.traverseBlock(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1080, in traverseBlock
subnode.accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 848, in traverse
self.traverseCompoundStmt(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1100, in traverseCompoundStmt
_node.getIfStmt().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 881, in traverse
self.traverseIfStmt(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1195, in traverseIfStmt
_node.getIfClause().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 878, in traverse
self.traverseIfClause(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1190, in traverseIfClause
_node.getBlock().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 836, in traverse
self.traverseBlock(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1080, in traverseBlock
subnode.accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 694, in handle
self.getRealSelf().traverse(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 923, in traverse
self.traverseSmallStmt(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 1274, in traverseSmallStmt
_node.getAssignment().accept(self.getRealSelf())
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ASTNode.py", line 158, in accept
_visitor.handle(self)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 693, in handle
self.getRealSelf().visit(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/ModelVisitor.py", line 708, in visit
self.visitAssignment(_node)
File "/home/schmidt/opt/nest/nestml/pynestml/modelprocessor/CoCoIllegalExpression.py", line 105, in visitAssignment
code, message = Messages.getImplicitCastRhsToLhs(_assignment.getExpr(),
AttributeError: 'ASTAssignment' object has no attribute 'getExpr'

How can the following buffer declaration be interpreted:

 input:
    spikes1[receptors]   <- spike
    spikes2[receptors]   <- spike
    currents <- current
  end

Or the following situation valid?

input:
    spikes1[receptors]   <- excitatory spike
    spikes2[receptors]   <- inhibitory spike
    currents <- current
end

Dear NESTML community,
I have 2 questions on NESTML use:

1. Is there any possibility to initialize a state variable to a parameter value so that I can modify the initialization value in NEST for different types of neurons? For example, I have the threshold potential as a state variable and the initialization value is different for different neuron types, but if I define it as a parameter and use it in the state block (e.g.: in the 'state' block: 'V_th mV = V_th_init'; in the 'parameters' block: V_th_init mV = -70.0mV), I receive an error.

2. Is there any built-in function to check if a buffer is empty? For example, how can I check if the currents' buffer is empty to use it as a condition?

Thanks a lot!

@DimitriPlotnikov You have remarked on how you want to enable literals to occur in the nominator of unit declarations, i.e. instead of writing:

SomeVar ms**-1 = 5/ ms

we could then write:

SomeVar 1/ms = 5/ms

After finishing up my refactoring of the prettyprinting of units, the generated output has this format in case no nominator can be identified.
I would now have to implement changes to the grammar resulting in the above behaviour in order to have models with generated nestml portions be parsable.

I propose the following change to the UnitType Nonterminal in Units.mc4:

UnitType = leftParentheses:"(" UnitType rightParentheses:")"
| base:UnitType pow:["**"] exponent:IntLiteral
| left:UnitType (timesOp:["*"] | divOp:["/"]) right:UnitType
| unitlessLiteral:"1" divOp:["/"] right:UnitType
| unit:Name;

(only the second to last option has been added)

As far as my understanding of MC goes, this should enable us to use declarations of the mentioned style while simultaneously ensuring that the literal used will always only be "1" without the need for an additional CoCo.

What do you think?

NestML installation via Docker will not run any of the models provided as examples. Error list is extensive and I've only listed the outputs for three models below.

System: Antergos (Arch Linux) and MacOS Sierra
Branch: master (last commit 0e5ad3c)

Running docker image 'nestml_release'
INFO: The input modelpath: /models
INFO: The base output path: /models/build
INFO: Correct python version is installed
INFO: Correct SymPy is installed.
06:05:35.169 [main] ERROR ROOT - iaf_cond_exp.nestml:<36,13>: mismatched input 'I_syn_exc' expecting {''', '.', '='}
06:05:35.181 [main] ERROR ROOT - iaf_cond_exp.nestml:<37,13>: mismatched input 'I_syn_inh' expecting {''', '.', '='}
06:05:35.183 [main] ERROR ROOT - iaf_cond_exp.nestml:<38,13>: mismatched input 'I_leak' expecting {''', '.', '='}
06:05:35.268 [main] ERROR ROOT - iaf_cond_beta.nestml:<38,15>: mismatched input 'I_syn_exc' expecting {''', '.', '='}
06:05:35.270 [main] ERROR ROOT - iaf_cond_beta.nestml:<39,15>: mismatched input 'I_syn_inh' expecting {''', '.', '='}
06:05:35.271 [main] ERROR ROOT - iaf_cond_beta.nestml:<40,15>: mismatched input 'I_leak' expecting {''', '.', '='}
06:05:35.301 [main] ERROR ROOT - iaf_neuron.nestml:<78,4>: extraneous input 'function' expecting {'end', 'recordable', 'alias', Name, NEWLINE}
06:05:35.304 [main] ERROR ROOT - iaf_neuron.nestml:<78,17>: missing '(' at 'mV'
06:05:35.307 [main] ERROR ROOT - iaf_neuron.nestml:<78,20>: no viable alternative at input '='
06:05:35.307 [main] ERROR ROOT - iaf_neuron.nestml:<82,2>: extraneous input 'equations' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.308 [main] ERROR ROOT - iaf_neuron.nestml:<83,4>: extraneous input 'shape' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.308 [main] ERROR ROOT - iaf_neuron.nestml:<84,4>: extraneous input 'V_abs' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.308 [main] ERROR ROOT - iaf_neuron.nestml:<85,2>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.309 [main] ERROR ROOT - iaf_neuron.nestml:<88,2>: extraneous input 'parameters' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.309 [main] ERROR ROOT - iaf_neuron.nestml:<89,4>: extraneous input 'C_m' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.309 [main] ERROR ROOT - iaf_neuron.nestml:<90,4>: extraneous input 'Tau' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.310 [main] ERROR ROOT - iaf_neuron.nestml:<91,4>: extraneous input 'tau_syn' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.310 [main] ERROR ROOT - iaf_neuron.nestml:<92,4>: extraneous input 't_ref' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.310 [main] ERROR ROOT - iaf_neuron.nestml:<93,4>: extraneous input 'E_L' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.310 [main] ERROR ROOT - iaf_neuron.nestml:<94,4>: extraneous input 'function' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.311 [main] ERROR ROOT - iaf_neuron.nestml:<95,4>: extraneous input 'function' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.311 [main] ERROR ROOT - iaf_neuron.nestml:<96,4>: extraneous input 'I_e' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.311 [main] ERROR ROOT - iaf_neuron.nestml:<97,2>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.311 [main] ERROR ROOT - iaf_neuron.nestml:<100,2>: extraneous input 'internals' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.312 [main] ERROR ROOT - iaf_neuron.nestml:<102,4>: extraneous input 'RefractoryCounts' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.312 [main] ERROR ROOT - iaf_neuron.nestml:<104,4>: extraneous input 'r' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.312 [main] ERROR ROOT - iaf_neuron.nestml:<105,2>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.313 [main] ERROR ROOT - iaf_neuron.nestml:<108,2>: extraneous input 'input' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.313 [main] ERROR ROOT - iaf_neuron.nestml:<109,4>: extraneous input 'spikes' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.313 [main] ERROR ROOT - iaf_neuron.nestml:<110,4>: extraneous input 'currents' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.313 [main] ERROR ROOT - iaf_neuron.nestml:<111,2>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.317 [main] ERROR ROOT - iaf_neuron.nestml:<114,2>: extraneous input 'output' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.317 [main] ERROR ROOT - iaf_neuron.nestml:<117,2>: extraneous input 'update' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.318 [main] ERROR ROOT - iaf_neuron.nestml:<118,4>: extraneous input 'if' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.318 [main] ERROR ROOT - iaf_neuron.nestml:<119,6>: extraneous input 'integrate_odes' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.318 [main] ERROR ROOT - iaf_neuron.nestml:<120,6>: extraneous input 'if' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.318 [main] ERROR ROOT - iaf_neuron.nestml:<121,8>: extraneous input 'r' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.319 [main] ERROR ROOT - iaf_neuron.nestml:<122,8>: extraneous input 'V_abs' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.319 [main] ERROR ROOT - iaf_neuron.nestml:<127,8>: extraneous input 'emit_spike' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.319 [main] ERROR ROOT - iaf_neuron.nestml:<128,6>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.319 [main] ERROR ROOT - iaf_neuron.nestml:<129,4>: extraneous input 'else' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.320 [main] ERROR ROOT - iaf_neuron.nestml:<130,6>: extraneous input 'r' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.320 [main] ERROR ROOT - iaf_neuron.nestml:<131,4>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.320 [main] ERROR ROOT - iaf_neuron.nestml:<133,2>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
06:05:35.320 [main] ERROR ROOT - iaf_neuron.nestml:<135,0>: extraneous input 'end' expecting {, 'neuron', 'component', NEWLINE}
...

This proposal tries to provide a way to minimize the amount of code necessary to manage spike arrival and spike effect while also providing a unique interface for the ODE vs shape definition.

This would only involve one apply_spikes function taking as parameters:

• the recordable (e.g. I_syn_ex)
• the spike buffer (e.g. spikesEx)
• an optional shape function if we use the function definition.

In the update block, you would then call:
apply_spikes(I_syn_ex, spikesEx) or apply_spikes(I_syn_ex, spikesEx, I_shape)

Attached examples in the zip file.
spike_proposal.zip