![]() ![]() BRAHMS
User Guide » Developing Processes » Quick Start » 1258 » Taking Inputs
This documentation is offline - click here to go online
Index | Search: Go online to use Search
| ||
OverviewThe Process you've created can now be controlled, generating a dynamic behaviour dependent on the parameters we pass to it. Processes of this sort can be described as "source" processes, because their output is derived entirely from their initial state - that is, they don't take any inputs. Most processes you write will want to take some input, at least. Let's try this, now. (Aside) Adding a second process to the systemThis sort of stuff is really covered elsewhere (in Developing Systems), so we're not going to dwell on it. We're just going to add a source of numeric data to the system, that we can use as an input to our process. We're then going to Modify your test script as follows, to add the source. M Source Code (against 995)
addprocess % add source state state state state %
% execution
exe link source to our processbrahms_execution You can go ahead and run this immediately, without modifying your process. Nothing will be different - the process has been presented this input, but it has ignored it, and this is quite acceptable in BRAHMS. Validating an input is presentModify your source file as follows to check that an input named "drive" was presented, and store it amongst our state. Since we don't need to see our inputs to create our outputs, we can safely do all our input validation on the last call to EVENT_INIT_CONNECT. Run your test script afterwards to check it all works OK. M Source Code (against 1258)
% on last call
if bitand
F_LAST_CALL % check we've an input called "drive" if output return end % extract it id Notes
Once this is working, you might try temporarily changing the test script to call the input something else (e.g. Next, we should validate that the input is of the expected BRAHMS class, M Source Code (against 1258)
% extract it
% validate class of input return end Validating input StructureOften, a process will handle inputs with many different structures (number of dimensions, dimensions themselves, even different M Source Code (against 1258)
% validate class of input
% validate structure of input output return end Reading inputOK, so we've validated that (a) we got an input called "drive", (b) it was a M Source Code (against 1258)
% run dynamics
% use the input data to drive the membrane id persist persist With the input driving the membrane, you should get a plot that looks something like this. ![]() Whoops. We're not driving this neuron very hard, I don't think (though, notice it's running a little hotter than before)... New dynamicsLet's finish the job on the dynamics, by detecting threshold-crossing ( M Source Code (against 1258)
% use the input data to drive the membrane
id
% handle threshold crossing spike if persist persist spike end
% write output
outputLet's also make a modification to the parameters in our test script so that the behaviour is a bit more interesting. M Source Code (against 995)
% add source
state
state stateAnd let's update our plot commands so we can see the spiking output as well as the membrane potential. M Source Code (against 995)
% show output
figure
clf hold on plotplot axis xlabelTa-da! Our neuron is doing its thing. ![]() Now - try changing the sample rate of the execution. You should find that sample rates all the way down to 25Hz still result in oscillatory behaviour, and, of course, you can raise the sample rate as high as you like and just increase the accuracy of the integration, though you'll notice things starting to slow down a bit if you go much above 1kHz. More than one inputFinally, we're going to add a second input, just to illustrate how it's done. This neurons a bit unrealistic at the moment, so let's add some current injection noise. There's a random number generator in the Standard Library, at M Source Code (against 995)
link source to our process
sys link % add RNG state state state state state seed %
% execution
exe link RNG to our processbrahms_execution Next, we'll have to modify our source file to validate this input, read it, and use it as an additional input to the membrane. M Source Code (against 1258)
% validate structure of input
if
DOUBLE /REAL/1'% validate input "noise" if output return end in return end output return end M Source Code (against 1258)
% use the input data to drive the membrane
id
in persist![]() Nice. We've a realistic (ahem...) neuron, taking two inputs (current drive and membrane noise), maintaining internal dynamics, and outputting a two-element output for other Processes, or the user, to view. Notes
Where do I go from here?You should note that it is not necessary to name inputs. You can, rather, review what inputs you were passed by index instead. In addition, you can offer input Sets, if required, but this is not something you should adopt unless there is a real need - most processes don't need Sets. See Using Sets under Advanced Topics. To find out more about how you can interact with your inputs, review the documentation for SystemMLInterface. |
||
This is a documentation page for the BRAHMS Modular Execution (Simulation) Framework. For details of licensing and distribution, please click here. To advise of an error or omission, please click here. |