Just checking this only effects treePerCluster branch
Finished tree construction in clusters. All the clusters now have trees.
Special case made for clusters of size 1, and printing of clusters with
odd diameter since they have two root nodes and they did not appear on
graph as an edge although they count torward the cost.
The ants are not currently moving for species1, but are for species2.
We first show top 5n graph, then 5n graph with color coded vertex
clusters, next we show the trees for each cluster where the roots are
the green vertices, finally we show the top .1n of the species2 edges
along with the tree per cluster graph.

Note: We still have to take care of the first species. When we have them
move they move very sporadically and this causes unsual clusters to be
formed which are scattered vertices across the entire graph. 

Next implementation will include the code to determine the center of
each cluster tree and then store not only the cluster's tree center, but
also a list of its possible children/parent which might also be used as
the center instead.
Added a few generated graphs to have a reference as to which stage this
past commit was at in terms of visually seeing the progress.
This is the last commit before changing the cluster trees. Currently I
was working on the last stages to implement the finding of possible
centers in the cluster trees. The next thing will to be go back and
limit the tree construction of the clusters to only have one root (i.e.
only allow the trees to be built in a cluster to have even diameter.)
This was it makes the construction and manipulations of the cluster
trees much easier. Note: on the final constructed spanning tree for the
whole graph we will still be considering the odd diameter it will just
be that when dealing on the subtree level we will treat them all as even
diameter for simplicity.
Code works for finding the center for tree of each cluster. Currently we
are restricting the tree construction of a cluster to only have one root
(ie. have even diameter). 
Example: 0-0-0-0-0 has a diameter of 4 and thus we have the center 0 to
be the root. If we had 0-0-0-0 we would require 0-0 in the middle to be
the root. 
Note: Once we construct the tree if the longest path consists of an even
number of vertices (ie. odd diameter) we then allow for both centers to
be in our possible center list as well as the children/parent of both of
the two.
Adaptive Diameter given to each cluster
*Sort the clusters by avg cost of edge when considering fully connected
cluster.
*Currently just breaking clusters into 3 groups and assigning d-2 and
d-3 for each of the clusters in the top 1/3. Then next 1/3 get d-4 and
d-5 and the bottom 1/3 get d-6 and d-7. However if we drop below d/2 for
a diameter of a cluster we keep it at d/2. 
*Note: we are still only allowing the trees to have one root (ie. even
diameter)
first species is still using all of the edges...the code is written to
handle the subset of edges however the subset of edges needs to be
chosen when we initalize the pheromone for s1

second species is working and could also be switched to use the degree
of the next possible move if we want (currently not turned on since the
first species isnt working quite right)

we are finding centers and the next stage of this branch will be to
create multiple trees per cluster and to use the previous center as the
root for this construction in an iterative way to hopefully find a
better subtree for each cluster to use for the overall construction
Just thought I would make a commit here since I found the memory bug...I
was deleting the same lookup table twice by mistake in the graph
destructor.
Finished the connecting the subtrees together to form a final solution.
The subtrees are being connected in a not so good way, but they are not
breaking any diameter constraint (that I know of).
Changes Made:
*New printing function as Dr. Bui asked to have generated
*Changed S2 tabu from 5 to 10
*Changed initializeSpeciesOne: best two groups from *4 and *6 of init
phero to get current is now set to 40 and 60. Note: the else section is
never reached so its 3 groupings of sorted edges by cost instead of the
4 which was originally used even prior to the last commit.
Note: This commit has not changed anything, but was due to forgetting
to add detailed comments on last commit.

The previous commit also added the first species moving once (probably
all that is needed) and the second species moving 10 times (since we
need only little randomness from s1 and lots of movement in s2 to find
good edges).

Next step will be to update the parent/child relationships after adding
a new cluster to the overall spanning tree. This is because the new
cluster has now decided its root from the list of possible centers, thus
we can go and update the relations in this cluster. 

After this we will do the subtree level local optimization where
we move around the subtrees to find a local opt. After this we can
update the depth and subtreeHeight values for each vertex since the
clusters subtrees will be in their final locations before the vertex
level local opt.
Update to starcost when choosing center cluster of overall spanning tree
to use Dr. Bui's mentioned cost/(height of subtree at the new cluster). 

We are now using cost^3 for selection of which edge to add a new cluster
to the overall spanning tree.

Note: The parent/child relation was fixed for the newly added clusters
to the spanning tree after a root was chosen for their subtrees. This
resulted in the last overall spanning tree graph looking as it should.
Last commit of this branch for now
Moving to the branch: newSTconstruct
Which will allow for all poss center vertices to connect new clusters
even after they werent chosen before coming out of that cluster
most of the parent/child relations have been removed and replaced with
the adjacencylist for the spanning tree...the export file still needs
updated and a few others
battling the following:
multiple definition of main_savitch_8B::queue functions
in the cluster, helper, and spanning tree objects

Hopefully after this things will be complete for the move to using the
adjacencyList from the linkedlist class I implemented instead of
parent/child relations. I also started the local opt by implementing the
different types of bfs we need.

Next steps after getting this working is to update the way we store the
clusters.
Finally! The adjacency list is fully functional and the code is running.
The next stage will be to redo the clustering. The current running times
for construting just a single solution (ie spanning tree) are about 0.1s
and 4s for the 100v and 1000v graph instances respectively. Hopefully
the new clustering method will help. It will for sure help with when we
construct many iterative solutions due to the current clustering needing
separate objects for each cluster which for each solution will need to
be created and destroyed which would be very time consuming.

The BFSs are also implemented, however the local opt stages are not. So
after the new clustering gets implemented the local opt stages are next
and will hopefully not take too long since part of them are done in that
the BFSs are coded for the needed functionality.
Changed the way I was handling the clusters. Now, rather than having a
cluster class and for every iteration creating a new list of cluster
objects, I simply have one class clusters in which there are about 15
dynamic arrays holding the values that each cluster needed to have. Thus
we only create these arrays once, then keep rewriting over the same
structure for each iteration. 

Note: The files cluster.h and cluster.cpp are completely not used now. 

Note: Functions such as creatingSubtrees, clustering vertices, and
constructing the overall spanning tree have been moved from the
BDMST.cpp file and into the clusters.cpp and spanningTree.cpp files.

*dancing* Hurray! Now on to coding the local optmization.
Made a few minor code bug fixes.
Changed the graph reading function to be in the graph class instead of
in BDMST.cpp and we now have two functions for reading Euclidean and for
Random, although random is not implemented yet
Also updated the folder structure so that we have a directory for inputs
and outputs.
Merge pull request #1 from tsd5037/puttingItTogether_withoutParentChildUntilEnd

Putting it together without parent child until end