Provide name checking for NEST SetStatus about nestml HOT 6 OPEN

@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.

from nestml.

@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?

from nestml.

@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

from nestml.

@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.

from nestml.

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.

from nestml.

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

from nestml.