Implementation choices¶

Frontend/backend communication¶

DeNSE uses a Python frontend to provide easy programming on the user part (see the DeNSE) but a C++ backend to ensure fast simulations.

The communication between the two relies on a conversion between Python and C++ objects using Cython.

Information container¶

More precisely, the parameters are passed by the user as Python dict, then converted to statusMap objects in C++:

Warning

doxygentypedef: Cannot find typedef “growth::statusMap” in doxygen xml output for project “DeNSE” from directory: /home/docs/checkouts/readthedocs.org/user_builds/dense/checkouts/latest/docs/doxyfiles/xml

which is a map of Property objects that serve as heterogeneous containers.

Warning

doxygenclass: Cannot find class “growth::Property” in doxygen xml output for project “DeNSE” from directory: /home/docs/checkouts/readthedocs.org/user_builds/dense/checkouts/latest/docs/doxyfiles/xml

Each objects then calls set_status on the statusMap to obtain its specific parameters.

Calling the C++ backend¶

The calls to the C++ operations is made through the user-oriented functions present in module.hpp. This avoids the redeclaration of the whole hierarchy in Cython.

Object creation¶

For large networks, objects (and especially growth::Neuron objects) should be created in parallel.

This is ensured by the create_neurons and create_objects functions in module.hpp/cpp:

Warning

doxygenfunction: Cannot find function “growth::create_neurons” in doxygen xml output for project “DeNSE” from directory: /home/docs/checkouts/readthedocs.org/user_builds/dense/checkouts/latest/docs/doxyfiles/xml

Warning

doxygenfunction: Cannot find function “growth::create_objects” in doxygen xml output for project “DeNSE” from directory: /home/docs/checkouts/readthedocs.org/user_builds/dense/checkouts/latest/docs/doxyfiles/xml

Graph Structure¶

Each Neurite is a binary tree of ‘TopologicalNode’ elements. In order to have a standard algorithm, without IF statement to check wheter we are dealing with the soma Node or not, each ‘Neurite’ has a ghost-soma Node, wich is fixed and is identified with ‘firstNode_’, the most awfull problem this implementation resolves is relative to the branching algorithm. At each branch event it will generally require to change the children of the root or other Nodes, keeping the Soma node (owned by Neuron) as father of the neurites will provide an easy management of this.

std::string growth::Neuron::new_neurite(const std::string &name, const std::string &neurite_type, const GCPtr gc_model, mtPtr rnd_engine)¶

Set & Get Status¶

The possibility to set & get the status of each neuron during the simulation is a key feature of DeNSE. The set status follows this schema.

virtual void growth::GrowthCone::set_status(const statusMap &status)¶

is implemented for each active elements, ‘Neuron’, ‘Neurite’ and ‘GrowthCone’. This function is callable from Python interface passing the Neuron identifier (gid) and a statusMap, a dictionary of parameters as described in

Warning

The procedure for neuron creation is different: it requires a rnd_enginer which is available at neuron_manager level and the proper function is

void growth::Neuron::init_status(const statusMap &status, const std::unordered_map<std::string, statusMap> &neurite_statuses, mtPtr rnd_engine)¶

the init_status takes care of setting dendrites and axons overwritting their features on the general statusMap

A full update will be computational expensive since it requires to merge list and to manage as many neurons were created.

DeNSE