[Yt-svn] commit/yt-doc: sskory: Adding figures & discussion for the treecode.

Bitbucket commits-noreply at bitbucket.org
Wed Apr 6 10:05:52 PDT 2011


1 new changeset in yt-doc:

http://bitbucket.org/yt_analysis/yt-doc/changeset/54c3b8b26035/
changeset:   r61:54c3b8b26035
user:        sskory
date:        2011-04-06 19:05:11
summary:     Adding figures & discussion for the treecode.
affected #:  4 files (102.5 KB)

--- a/source/analysis_modules/clump_finding.rst	Tue Apr 05 22:26:24 2011 -0400
+++ b/source/analysis_modules/clump_finding.rst	Wed Apr 06 11:05:11 2011 -0600
@@ -40,10 +40,13 @@
 
   PE = \Sigma_{i=1}^N \Sigma_{j=i}^N \frac{G M_i M_j}{r_{ij}}
 
-where PE is the gravitational potential energy of N cells, G is the
-gravitational constant, M_i is the mass of cell i, and r_{ij} is the distance
-between cell i and j. The number of calculations required for this calculation
-grows with the square of N. Therefore, for large clumps with many cells, the
+where :math:`PE` is the gravitational potential energy of :math:`N` cells,
+:math:`G` is the
+gravitational constant, :math:`M_i` is the mass of cell :math:`i`, 
+and :math:`r_{ij}` is the distance
+between cell :math:`i` and :math:`j`.
+The number of calculations required for this calculation
+grows with the square of :math:`N`. Therefore, for large clumps with many cells, the
 test for boundedness can take a significant amount of time.
 
 An effective way to greatly speed up this calculation with minimal error
@@ -62,14 +65,14 @@
 ``opening_angle`` upon the remote mass. The default value is
 ``opening_angle = 1``, which gives errors well under 1%. A value of 
 ``opening_angle = 0`` is identical to the full O(N^2) method, and larger values
-will speed up the calculation and sacrifice accuracy.
+will speed up the calculation and sacrifice accuracy (see the figures below).
 
 The treecode method is iterative. Conglomerates may themselves form larger
 conglomerates. And if a larger conglomerate does not meet the ``opening_angle``
 criterion, the smaller conglomerates are tested as well. This iteration of 
 conglomerates will
 cease once the level of the original masses is reached (this is what happens
-if ``opening_angle = 0``).
+for all pair calculations if ``opening_angle = 0``).
 
 Below are some examples of how to control the usage of the treecode.
 
@@ -114,4 +117,70 @@
 To turn off the treecode, of course one should turn treecode=False in the
 example above.
 
+Treecode Speedup and Accuracy Figures
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+Two datasets are used to make the three figures below. Each is a zoom-in
+simulation with high resolution in the middle with AMR, and then lower
+resolution static grids on the periphery. In this way they are very similar to
+a clump in a full-AMR simulation, where there are many AMR levels stacked
+around a density peak. One dataset has a total of 3 levels of AMR, and
+the other has 10 levels, but in other ways are very similar.
+
+The first figure shows the effect of varying the opening angle on the speed
+and accuracy of the treecode. The tests were performed using the L=10 
+dataset on a clump with approximately 118,000 cells. The speedup of up the
+treecode is in green, and the accuracy in blue, with the opening angle
+on the x-axis.
+
+With an ``opening_angle`` = 0, the accuracy is perfect, but the treecode is
+less than half as fast as the brute-force method. However, by an
+``opening_angle`` of 1, the treecode is now nearly twice as fast, with
+about 0.2% error. This trend continues to an ``opening_angle`` 8, where
+large opening angles have no effect due to geometry.
+
+.. image:: _images/TreecodeOpeningAngleBig.png
+   :width: 450
+   :height: 400
+
+Note that the accuracy is always below 1. The treecode will always underestimate
+the gravitational binding energy of a clump.
+
+In this next figure, the ``opening_angle`` is kept constant at 1, but the
+number of cells is varied on the L=3 dataset by slowly expanding a spherical
+region of analysis. Up to about 100,000 cells,
+the treecode is actually slower than the brute-force method. This is due to
+the fact that with fewer cells, smaller geometric distances,
+and a shallow AMR hierarchy, the treecode
+method has very little chance to be applied. The calculation is overall
+slower due to the overhead of the treecode method & startup costs. This
+explanation is further strengthened by the fact that the accuracy of the
+treecode method stay perfect for the first couple thousand cells, indicating
+that the treecode method is not being applied over that range.
+
+Once the number of cells gets high enough, and the size of the region becomes
+large enough, the treecode method can work its magic and the treecode method
+becomes advantageous.
+
+.. image:: _images/TreecodeCellsSmall.png
+   :width: 450
+   :height: 400
+
+The saving grace to the figure above is that for small clumps, a difference of
+50% in calculation time is on the order of a second or less, which is tiny
+compared to the minutes saved for the larger clumps where the speedup can
+be greater than 3.
+
+The final figure is identical to the one above, but for the L=10 dataset.
+Due to the higher number of AMR levels, which translates into more opportunities
+for the treecode method to be applied, the treecode becomes faster than the
+brute-force method at only about 30,000 cells. The accuracy shows a different
+behavior, with a dip and a rise, and overall lower accuracy. However, at all
+times the error is still well under 1%, and the time savings are significant.
+
+.. image:: _images/TreecodeCellsBig.png
+   :width: 450
+   :height: 400
+
+The figures above show that the treecode method is generally very advantageous,
+and that the error introduced is minimal.
\ No newline at end of file

Repository URL: https://bitbucket.org/yt_analysis/yt-doc/

--

This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.



More information about the yt-svn mailing list