Detailed Program Flow - Revision history

Markdayel: moved Implementation to Detailed Program Flow

2009-04-27T00:57:10Z

moved Implementation to Detailed Program Flow

Markdayel: /* Implementation */

2009-04-27T00:55:55Z

‎Implementation

Markdayel: /* Implementation */

2009-04-27T00:55:37Z

‎Implementation

Markdayel: Replaced content with '=Implementation= The flowchart below shows a detailed view of the how the program works (click for full size image). [[file:Overview_complex.png|800px|Figure 2: Comet progr...'

2009-04-27T00:38:45Z

Replaced content with '=Implementation= The flowchart below shows a detailed view of the how the program works (click for full size image). [[file:Overview_complex.png|800px|Figure 2: Comet progr...'

Markdayel at 00:36, 27 April 2009

2009-04-27T00:36:51Z

Markdayel at 23:46, 17 April 2009

2009-04-17T23:46:08Z

Markdayel: Created page with '=Implementation in C++= The code is written in C++ for speed. We attempt to use an somewhat object-based approach, but a good many of the member variables are declared as stati...'

2009-04-13T20:07:18Z

Created page with '=Implementation in C++= The code is written in C++ for speed. We attempt to use an somewhat object-based approach, but a good many of the member variables are declared as stati...'

New page

=Implementation in C++=

The code is written in C++ for speed. We attempt to use an somewhat object-based approach, but a good many of the member variables are declared as static global to allow their access across threads.

Here is a breakdown of the main classes and functions in the program. There are numerous other functions but this is the core of the program:

* Main()
** Spawns threads: <code>collisiondetectionthread</code> , <code>linkforcesthread</code> and <code>applyforcesthread</code> depending on the <code>USETHREAD_COLLISION</code> , <code>USETHREAD_LINKFORCES</code> and <code>USETHREAD_APPLYFORCES</code> parameters.
** Parses the <code>comet_params.ini</code> file to read parameters. All of the parameters are implemented as globals (should fix at some point)
** Creates the main <code>theactin</code> and <code>nuc_object</code> objects.
** Runs through the main iteration loop, calling <code>theactin.iterate()</code> and saving snapshots every so often.
* Actin class
** There is only one actin object, <code>theactin</code> , which constitutes the network, i.e.~contains the nodes and the functions that deal with them.
** The <code>iterate()</code> function does one iteration pass, calling:
***<code>nucleator_node_interactions()</code> displaces any nodes out of the nucleator object along a normal to the nucleator surface
***<code>nucleate()</code> adds new harbinger nodes to the surface of the nucleator
***<code>crosslinknewnodes()</code> crosslinks harbingers once they are ready
***<code>sortnodesbygridpoint()</code> orders nodes by gridpoint. The {\it only} reason for this is for the division of labor when using threads: We do repulsion by gridpoint to save re-calculating nearby nodes if there are multiple nodes on one gridpoint, and we do not want to divide nodes on one gridpoint across multiple threads.
***<code>collisiondetection()</code> detects whether nodes are within <code>NODE_REPULSIVE_RANGE</code> of one another and adds the repulsive force to <code>rep_force_vec[]</code> .
***<code>linkforces()</code> Calculates the forces between nodes due to links and puts into <code>link_force_vec[]</code> . If a link goes above a certain threshold force, marks it as broken and removes next time (again to prevent thread problems---since a link is removed both ways and we can't guarantee that both nodes are being processed by same thread)
***<code>applyforces()</code> updates the positions of all the nodes. Sums over the threads for <code>rep_force_vec[]</code> , <code>link_force_vec[]</code> and <code>repulsion_displacement_vec[]</code> .
***Numerous other functions for things like saving bmps, vrml etc.
**Nucleator class
*** There is only one nucleator object at the moment, <code>nuc_object</code> , which is closely linked to the actin object
*** The nucleator is either a sphere, a capsule (i.e.~a sphere with a cylindrical segment stuck in the middle) or ellipsoid
*** <code>addnodes()</code> adds harbingers to the surface of the nucleator. The probablility of addition of nodes is normalized by surface area and is symmetric if <code>ASYMMETRIC_NUCLEATION</code> is zero, or asymmetric if 1 or 2 (stepped or linear bias)
*** <code>definenucleatorgrid()</code> sets a list of gridpoints to check in case of nodes entering the nucleator. Called once at the beginning.
*** <code>iswithinnucleator()</code> returns true if the node is within the nucleator
*** <code>collision()</code> moves a node out of the nucleator along a normal vector
** Nodes class
*** Nodes exist only as members of the actin object
*** <code>nodegrid</code> is a 3 dimensional C++ vector of node pointers. Each nodegrid entry starts a circularly linked list of nodes representing the nodes within that gridpoint voxel.
*** The actin class contains a vector of nodes. Each node has an associated <code>nodenum</code> , <code>x</code> <code>y</code> and <code>z</code> position, <code>nextnode</code> and <code>prevnode</code> node pointers for the nodegrid linked list, <code>rep_force_vec[]</code> , <code>link_force_vec[]</code> and <code>repulsion_displacement_vec[]</code> as described above, the grid position of the node, <code>harbinger</code> and <code>polymer</code> flags and a <code>listoflinks</code> i.e. a vector of link object which attach this node to other nodes.
*** <code>polymerize()</code> Creates a node as a harbinger. Adds its pointer to the gridpoint linked list.
*** <code>depolymerize()</code> Removes a node, deletes all links and removes from grid.
*** <code>setgridcoords()</code> Calculates new grid co-ordinates based on x,y,z position
*** <code>addtogrid()</code> adds the node to the current gridpoint
*** <code>removefromgrid()</code> removes node from the grid
*** <code>updategrid()</code> checks to see if node has moved gridpoints, and updates grid is needs to
*** <code>removelink()</code> removes the specified node from the list of links
** Links class
*** Links exist only as members of the node objects
*** Each link has an associated <code>linkednodeptr</code> which points to the target node that the link is to and a <code>broken</code> flag which is read by <code>actin::linkforces()</code> and tells it to delete the link if it broke.
*** <code>orig_dist</code> and <code>orig_distsqr</code> store the original distance of the link (and the square of that in a misguided attempt to avoid taking square roots.)
*** <code>breakcount</code> stores the number of consecutive iterations the link force has been above <code>LINK_BREAKAGE_FORCE</code> and is used to increase the probability of breakage
*** <code>getlinkforces()</code> returns the force acting on the link. Also sets the <code>broken</code> flag and increments <code>breakcount</code> if appropriate

← Older revision		Revision as of 00:55, 27 April 2009
Line 1:		Line 1:
−	~~=Implementation=~~

	The flowchart below shows a detailed view of the how the program works.		The flowchart below shows a detailed view of the how the program works.

	[[file:Overview_complex.png\|800px\|Figure 2: Comet program flow (detailed)]]		[[file:Overview_complex.png\|800px\|Figure 2: Comet program flow (detailed)]]

@@ Line 1: / Line 1: @@
 =Implementation=
-The flowchart below shows a detailed view of the how the program works (click for full size image).
+The flowchart below shows a detailed view of the how the program works.
 [[file:Overview_complex.png|800px|Figure 2: Comet program flow (detailed)]]

← Older revision		Revision as of 00:36, 27 April 2009
Line 46:		Line 46:
	*** <code>getlinkforces()</code> returns the force acting on the link. Also sets the <code>broken</code> flag and increments <code>breakcount</code> if appropriate		*** <code>getlinkforces()</code> returns the force acting on the link. Also sets the <code>broken</code> flag and increments <code>breakcount</code> if appropriate

−	[[file:Overview_complex.~~svg~~\|~~frame\|right~~\|Figure 2: Comet program flow (detailed)]]	+	[[file:Overview_complex.png\|800px\|Figure 2: Comet program flow (detailed)]]

← Older revision	Revision as of 00:57, 27 April 2009
(No difference)

@@ Line 1: / Line 1: @@
-=Implementation in C++=
+=Implementation=
-The code is written in C++ for speed. We attempt to use an somewhat object-based approach, but a good many of the member variables are declared as static global to allow their access across threads.
+The flowchart below shows a detailed view of the how the program works (click for full size image).
-−
-Here is a breakdown of the main classes and functions in the program. There are numerous other functions but this is the core of the program:
-−
-* Main()
-** Spawns threads: <code>collisiondetectionthread</code> , <code>linkforcesthread</code> and <code>applyforcesthread</code> depending on the <code>USETHREAD_COLLISION</code> , <code>USETHREAD_LINKFORCES</code> and <code>USETHREAD_APPLYFORCES</code> parameters.
-** Parses the <code>comet_params.ini</code> file to read parameters. All of the parameters are implemented as globals (should fix at some point)
-** Creates the main <code>theactin</code> and <code>nuc_object</code> objects.
-** Runs through the main iteration loop, calling <code>theactin.iterate()</code> and saving snapshots every so often.
-* Actin class
-** There is only one actin object, <code>theactin</code> , which constitutes the network, i.e.~contains the nodes and the functions that deal with them.
-** The <code>iterate()</code> function does one iteration pass, calling:
-***<code>nucleator_node_interactions()</code> displaces any nodes out of the nucleator object along a normal to the nucleator surface
-***<code>nucleate()</code> adds new harbinger nodes to the surface of the nucleator
-***<code>crosslinknewnodes()</code> crosslinks harbingers once they are ready
-***<code>sortnodesbygridpoint()</code> orders nodes by gridpoint. The {\it only} reason for this is for the division of labor when using threads: We do repulsion by gridpoint to save re-calculating nearby nodes if there are multiple nodes on one gridpoint, and we do not want to divide nodes on one gridpoint across multiple threads.
-***<code>collisiondetection()</code> detects whether nodes are within <code>NODE_REPULSIVE_RANGE</code> of one another and adds the repulsive force to <code>rep_force_vec[]</code> .
-***<code>linkforces()</code> Calculates the forces between nodes due to links and puts into <code>link_force_vec[]</code> . If a link goes above a certain threshold force, marks it as broken and removes next time (again to prevent thread problems---since a link is removed both ways and we can't guarantee that both nodes are being processed by same thread)
-***<code>applyforces()</code> updates the positions of all the nodes. Sums over the threads for <code>rep_force_vec[]</code> , <code>link_force_vec[]</code> and <code>repulsion_displacement_vec[]</code> .
-***Numerous other functions for things like saving bmps, vrml etc.
-**Nucleator class
-*** There is only one nucleator object at the moment, <code>nuc_object</code> , which is closely linked to the actin object
-*** The nucleator is either a sphere, a capsule (i.e.~a sphere with a cylindrical segment stuck in the middle) or ellipsoid
-*** <code>addnodes()</code> adds harbingers to the surface of the nucleator. The probablility of addition of nodes is normalized by surface area and is symmetric if <code>ASYMMETRIC_NUCLEATION</code> is zero, or asymmetric if 1 or 2 (stepped or linear bias)
-*** <code>definenucleatorgrid()</code> sets a list of gridpoints to check in case of nodes entering the nucleator. Called once at the beginning.
-*** <code>iswithinnucleator()</code> returns true if the node is within the nucleator
-*** <code>collision()</code> moves a node out of the nucleator along a normal vector
-** Nodes class
-*** Nodes exist only as members of the actin object
-*** <code>nodegrid</code> is a 3 dimensional C++ vector of node pointers. Each nodegrid entry starts a circularly linked list of nodes representing the nodes within that gridpoint voxel.
-*** The actin class contains a vector of nodes. Each node has an associated <code>nodenum</code> , <code>x</code> <code>y</code> and <code>z</code> position, <code>nextnode</code> and <code>prevnode</code> node pointers for the nodegrid linked list, <code>rep_force_vec[]</code> , <code>link_force_vec[]</code> and <code>repulsion_displacement_vec[]</code> as described above, the grid position of the node, <code>harbinger</code> and <code>polymer</code> flags and a <code>listoflinks</code> i.e. a vector of link object which attach this node to other nodes.
-*** <code>polymerize()</code> Creates a node as a harbinger. Adds its pointer to the gridpoint linked list.
-*** <code>depolymerize()</code> Removes a node, deletes all links and removes from grid.
-*** <code>setgridcoords()</code> Calculates new grid co-ordinates based on x,y,z position
-*** <code>addtogrid()</code> adds the node to the current gridpoint
-*** <code>removefromgrid()</code> removes node from the grid
-*** <code>updategrid()</code> checks to see if node has moved gridpoints, and updates grid is needs to
-*** <code>removelink()</code> removes the specified node from the list of links
-** Links class
-*** Links exist only as members of the node objects
-*** Each link has an associated <code>linkednodeptr</code> which points to the target node that the link is to and a <code>broken</code> flag which is read by <code>actin::linkforces()</code> and tells it to delete the link if it broke.
-*** <code>orig_dist</code> and <code>orig_distsqr</code> store the original distance of the link
-*** <code>breakcount</code> stores the number of consecutive iterations the link force has been above <code>LINK_BREAKAGE_FORCE</code> and is used to increase the probability of breakage
-*** <code>getlinkforces()</code> returns the force acting on the link. Also sets the <code>broken</code> flag and increments <code>breakcount</code> if appropriate
 [[file:Overview_complex.png|800px|Figure 2: Comet program flow (detailed)]]