Provide name checking for NEST SetStatus

[heplesser]

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.

[DimitriPlotnikov]

@heplesser

It sounds doable.

However, it is possible to check only names which are defined in the neuronmodel und not names, which are theoretically adjustable through the fact the the generated neuron extend Archiving_Node-class.

[heplesser]

@DimitriPlotnikov But I think names inherited from Node and ArchivingNode would be rather stable over time, so one could explicitly add them during NESTML code generation, couldn't one?

Would it also be possible in NESTML to indicate legal value ranges for parameters and maybe even conditions, such as a < b required?

[DimitriPlotnikov]

@heplesser

1. Yes, it is doable, but not fancy.
2. We are working on an extension of NESTML for a proper support of constraints and invariants (naming is a part of the discussion). E.g. adding new block with invariants and guards:

invariants:
  -90 <= V_m <= 90 # 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

[heplesser]

@DimitriPlotnikov Why is the condition on V_m an invariant, while the condition on gsl_err_tol is only a guard checked up SetStatus? Is that because V_m is a state variable, while gsl_err_tol is a parameter? Then the general logic would be that state variables have invariants, parameters have guards? But since parameters cannot change in any other way than through SetStatus, guards on parameters are also invariants.

[DimitriPlotnikov]

V_m is an invariant because a) it is a state variable b) because we want to enforce V_m to be in the range during simulation c) (syntactical form) an invariant is always of lower_bound < STATE_VAR< upper_bound. I would also through an exception in SetStatus, if a value out of the range is being set.

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

[DimitriPlotnikov]

I summarized points regarding invariants/constraints and created a new issue: #363.