Difference between revisions of "Implementation in C++"

From CometWiki
Jump to: navigation, search
m
m
 
Line 1: Line 1:
You can browse the source code here [http://www.dayel.com/git/comet.git here].  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.
+
You can browse the source code here [http://github.com/markdayel/comet here].  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:
 
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:

Latest revision as of 18:02, 21 November 2009

You can browse the source code here here. 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: collisiondetectionthread , linkforcesthread and applyforcesthread depending on the USETHREAD_COLLISION , USETHREAD_LINKFORCES and USETHREAD_APPLYFORCES parameters.
    • Parses the comet_params.ini file to read parameters. All of the parameters are implemented as globals (should fix at some point)
    • Creates the main theactin and nuc_object objects.
    • Runs through the main iteration loop, calling theactin.iterate() and saving snapshots every so often.
  • Actin class
    • There is only one actin object, theactin , which constitutes the network, i.e.~contains the nodes and the functions that deal with them.
    • The iterate() function does one iteration pass, calling:
      • nucleator_node_interactions() displaces any nodes out of the nucleator object along a normal to the nucleator surface
      • nucleate() adds new harbinger nodes to the surface of the nucleator
      • crosslinknewnodes() crosslinks harbingers once they are ready
      • sortnodesbygridpoint() 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.
      • collisiondetection() detects whether nodes are within NODE_REPULSIVE_RANGE of one another and adds the repulsive force to rep_force_vec[] .
      • linkforces() Calculates the forces between nodes due to links and puts into link_force_vec[] . 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)
      • applyforces() updates the positions of all the nodes. Sums over the threads for rep_force_vec[] , link_force_vec[] and repulsion_displacement_vec[] .
      • Numerous other functions for things like saving bmps, vrml etc.
    • Nucleator class
      • There is only one nucleator object at the moment, nuc_object , 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
      • addnodes() adds harbingers to the surface of the nucleator. The probablility of addition of nodes is normalized by surface area and is symmetric if ASYMMETRIC_NUCLEATION is zero, or asymmetric if 1 or 2 (stepped or linear bias)
      • definenucleatorgrid() sets a list of gridpoints to check in case of nodes entering the nucleator. Called once at the beginning.
      • iswithinnucleator() returns true if the node is within the nucleator
      • collision() moves a node out of the nucleator along a normal vector
    • Nodes class
      • Nodes exist only as members of the actin object
      • nodegrid 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 nodenum , x y and z position, nextnode and prevnode node pointers for the nodegrid linked list, rep_force_vec[] , link_force_vec[] and repulsion_displacement_vec[] as described above, the grid position of the node, harbinger and polymer flags and a listoflinks i.e. a vector of link object which attach this node to other nodes.
      • polymerize() Creates a node as a harbinger. Adds its pointer to the gridpoint linked list.
      • depolymerize() Removes a node, deletes all links and removes from grid.
      • setgridcoords() Calculates new grid co-ordinates based on x,y,z position
      • addtogrid() adds the node to the current gridpoint
      • removefromgrid() removes node from the grid
      • updategrid() checks to see if node has moved gridpoints, and updates grid is needs to
      • removelink() 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 linkednodeptr which points to the target node that the link is to and a broken flag which is read by actin::linkforces() and tells it to delete the link if it broke.
      • orig_dist and orig_distsqr store the original distance of the link
      • breakcount stores the number of consecutive iterations the link force has been above LINK_BREAKAGE_FORCE and is used to increase the probability of breakage
      • getlinkforces() returns the force acting on the link. Also sets the broken flag and increments breakcount if appropriate