This page was generated from docs/extension_pointers.ipynb. Interactive online version: . Download notebook.

LEMS extension: <VariableRequirement>

As we have seen in Introduction to LEMS, for each type of mechanism, there are certain quantities that it can access, whose values are provided by the nearby environment as per the NeuroML formulation. However, we (will always) need more to model uncommon, or entirely novel interactions in our mechanisms. Hence, we need a way for mechanisms to be possibly influenced by any arbitrary quantity that exists in our model.

EDEN makes this possible through the <VariableRequirement> tag. This tag may be present inside a LEMS component, among the standard <Requirement>s that are fulfilled in the classic NeuroML way.

The value that a <VariableRequirement> provides at any point in time is that of its target. That could be any state variable, that’s specified through a LEMS path.

Tip: This concept is also known as POINTER s when using the NEURON simulator, and as linked variables when using BRIAN. But there is a difference as follows:

• Under EDEN’s rules, the quantities can be observed but not modified directly, since that could cause unpredictable results between users of the variable. If modifying an observed variable is needed nonetheless, this can be achieved by firing spikes to synaptic components, that may then modify the same value through <𝚆𝚛𝚒𝚝𝚊𝚋𝚕𝚎𝚁𝚎𝚚𝚞𝚒𝚛𝚎𝚖𝚎𝚗𝚝>. (By the way, the same ‘read-only’ rule applies for CoreNEURON among other high-speed simulators.)

Usage

After specifying a <VariableRequirement> in a LEMS mechanism, all that remains to resolve its target. Since they exist beyond the classic LEMS specification, and any value that they could have depends on the model that they exist in, the target has to be specified for every single instance using <𝙴𝚍𝚎𝚗𝙲𝚞𝚜𝚝𝚘𝚖𝚂𝚎𝚝𝚞𝚙>. Instead of a numerical value with units, a LEMS path is assigned as the target (immediate “value” in a sense) of every <VariableRequirement> property that exists in the model.

Note: Any <VariableRequirement> that has not been resolved will yield a NaN value, that will propagate to all the state and derived variables that it touches. This may seem frustrating at first, but it ensures that all references are accounted for; lax tracking of references has often been a cause of difficult to trace mistakes in the past.

In later versions, EDEN may thoroughly scan for unresolved <Reference>s and refuse to run the model until they are resolved, instead reporting the locations of missing references to the user.

Examples

As <VariableRequirement>s by their nature get to be used in highly model-specific ways, it is not so easy to single out one simple and general example of use. However, they are instrumental in the functioning of many models that are included in this guide. The interested user may refer to, among others, these straightforward uses:

• Accessing the variables of a <EdenTimeSeriesReader> input stream.

• Exchanging the ball and paddle positions with the requested control forces between the playing field and the players, in the Pong example.