I. Need to create a list of 'unit tests' -- cases that MUST be handled by any Sieve interface.
   These should probably be documented with pictures and all, and done as a Tech Report. 
   This way we can test the feasibility of any design changes against this list.
   We should put common test components in a namespace so that we can build more complicated
   tests on top of simpler ones. When a test is completed, it is added to the line in parentheses.

   Sifter:
   -------
   - Performance stress tests
     - Many cone/supports (sifter1)
   Sieve:
   -------
   - Memory stress tests
     - Largest cell-vertex mesh
     - Largest full 2D and 3D, tet and hex meshes
   - Performance stress tests
     - Many closure/stars
     - Many meet/joins
   - Distribution via Overlap/Fusion
   - Global numbering of points
   - Stratification (topology1)
   Mesh (Topology + Coordinates):
   ------------------------------
   - Reading other mesh formats
     - PCICE
     - PyLith
     - VTK?
   - Interpolation of missing elements
     - Tet and hex meshes
   - Calculation of a mesh partition
     - With and without intermediate elements
   - Independent mesh point insertion on different procs
     - Collision resolution via Overlap/Fusion
   - Ordered data retrieval, or restrict
     - Element Geometry Computation (mesh1 only for P1 w/o interpolation)
   Section:
   --------
   - Data preallocation
     - Linear and cubic Lagrange (section1)
   - Raw pointer extraction
     - Linear and cubic Lagrange (section1)
   - Ordered data retrieval, or restrict
     - Linear and cubic Lagrange (section1)
   - Performance stress tests
     - Many getIndex
     - Many restrict/update
   - Memory stress tests
     - Largest linear and cubic Lagrange fields
     - Shared indices
   - Distribution via Overlap/Fusion
   - Multicomponent fields.
   - Faults a la Pylith via a suitable chart mechanism.
   - Global numbering of dofs
   Overlap & Fusion:
   -----------------
   - Identify shared points between two patches
   - Identify dependent points between two patches
   - Construct outgoing messages for receiving points
     - sizes
     - buffers?
     - fillup
   - Process incoming messages for sent points
     - sizes
     - buffers?
     - update
   - Distribute a sifter
   - Distribute a sieve
   - Distribute a section

II. Coding guidelines

  - Mark EVERYTHING const that can be
  - Try to make Obj<> returns references to prevent extra creations
  - Have a format for each class:

    - public typedefs
    - protected data
    - public constructor/destructor
    - public data accessors
    - public/private methods

III.  Traversals and orderings vs storage efficiency.
   0. We propose that the efficiency of a data structure (in terms of storage) should be measured by the 
      modes of orderings (and implied traversals) that the structure allows on the underlying data.
      Certain objects require fewer modes of traversal, and therefore can use a simpler data structure.
      For instance, an STL 'Map' allows easy traversals on keys, while a 'BiMap' would allow easy traversals
      both on keys and values, consuming more memory for the additional index.  If a traversal on values 
      is not needed,  'Map' is to be preferred over a 'BiMap'.  A Sifter takes it a step up, allowing, in principle,
      3 modes of traversal (and implied ordering).
   1. If we assume that charts are groupings of largest granularity, they should not be included
      at the level of arrows, as it means significant storage penalties. In other words, if there are too 
      many arrows with the same chart marker, perhaps all these arrows should be held in a separate arrow container.
      In particular, all arrows on a given proc ARE held in a separate container by virtue of distinct memory spaces.
   2. This implies that any efficient traversal of an arrow container (a nested 'for-loop') must enter each chart at 
      the very top.  Deeper iterations must be over the arrows within the same chart.
   3. This also implies, in the case of cone ordering, for instance,  a lexicographic ordering on the chart first,
      then on the target and, finally, on the source.  This eliminates the possibility of orderings that, for instance,
      'pull out' each target out and order the corresponding cone using charts (and source, if necessary).
   4. Colored Sifters in principle allow orderings three different ways (many more are possible, but become infeasible):
      a) starting with the source, b) starting with the target, c) starting with the color.
      Thinking in terms of matrices (or rank-3 tensors), this allows the outer traversals to be either on rows, or on columns
      (or even on 'planes'). 
   5. The above discussion appears to imply that using color for ordering only is not 'cost-effective'.  
      More specifically, the third index on the arrow set is not 'cost-effective', unless it allows ordering on the
      color first.
   6. At the moment, Sifter employs three indices -- cone, support, and 'arrows'.  The 'arrows' index does not seem to
      be cost effective: it does not allow to order on the color first and is used very infrequently -- only to remove
      arrows.  In principle this can be done, perhaps slower, but traversing a suitable cone or support.
      This frees up an index (which costs memory) for color-first traversals.

IV. Charts.
   1.   There has been no clear definition of the term 'chart' and there seems to have been some confusion between at
      least two different kinds of charts: arrow charts and point charts.  An arrow chart is basically a sub-Sieve or
      a sub-Sifter, while a point chart is essentially a chain.  Sometimes a point chart has been called a 'patch'.  
      Arrow charts are the analog of manifold charts -- they are local pieces of topology.  At the same time,
      point charts are simply collections of points with no relations among them, which makes them similar to chains.  
   2.   In many cases point charts carry numerical data attached to their points, reinforcing the analogy with chains.
      Also, because of this both types of charts are typically encoded by Sifters, making them superficially similar 
      to arrow charts.  Semantically, arrow charts encode local yet fairly complicated arrangements of elements -- 
      pieces of topology.  Point charts can be frequently viewed simply as labelings or numberings imposed on elements. 
   3.   In order to understand what data structures are best suited for both types of charts, we should try to
      characterize them structurally and also syntactically, that is by analyzing the ordering and traversal patters
      required of the underlying Sifters, similar to what was done in (II). The relevant object here is the
      corresponding arrow Atlas or point Atlas -- a single object containing a collection of charts and allowing their
      traversals.
   4.   An arrow atlas typically has points with multiple incoming and/or outgoing arrows even within a single chart -- 
      non-singleton (and non-empty) cones and supports.  A point atlas frequently has a single tag (a number, a pair of
      numbers etc) per chart attached to each point, making it more like a collection of permutations. In particular, 
      it is reasonable to assume that within a single arrow chart both cones and supports are used, hence two types of 
      orderings and traversals are excersized, as in a 'BiMap'.  In a point atlas, given a chart, only cones are 
      typically used, retrieving the numerical data, making them analogous to 'Maps'.  The real determining factor is
      how traversal of several charts is accomplished.  In particular, whether chart loops always stay on the 'outside'.
   5.   Both types of charts are implicitly present in a parallel Sifter (or Sieve).  Specifically, the Sifter itself can 
      be viewed as a arrow atlas indexed by procs.  The Overlap algorithm produces on each proc a point atlas -- one 
      point chart for each neighboring proc --  with the size of the remote cone attached to each point. 
      After Fusion operates on the Overlap data, the result is typically an arrow atlas indexed by neighboring procs and
      containing the cones exchanged through the overlap.  
   6.   The crucial determination of a suitable structure for overlap (point) atalses comes from considering how they are
      traversed during Fusion. Since sends/receives are posted for each given neighbor all at once, the outer loop is
      inevitably on the proc-chart.  Thus, for the overlap atlas, charts do index sets of greatest granularity, hence 
      can be moved outside of the data structure and index a list of point charts; and for each point chart STL 'Map'
      functionality is sufficient.  Hence, Overlap is truely a point atlas.
 
V. Clutching construction.        
   1.   The Overlap/Fusion pair is analogous to the 'clutching' construction by which a bundle or a manifold is
      constructed out of its local pieces.  It has also found unexpected applications as a mechanism for distribution
      and general movement of Sifters among procs.  The correct idea here seems to be that of a PROCESS of 'resolution',
      'reconciliation' or 'reduction' -- FUSION -- of the 'data' (e.g., cones or supports) lying over the overlap.
   2.   This success indicates that correct ideas underly the fundamental concepts of arrow atlas and Fusion.  
      In fact, it is the result of Fusion that makes a collection of arrow charts into a real Atlas. 
      It appears natural to try to extend it to an analogous construction for local arrow atlases and Arrays 
      (aka CoSifters, Sections, etc), since Fusion is reminiscent of vector assembly, finite element matrix assembly 
      (aka direct stiffness summation),  ghost exchange, and other typical FEM procedures. The challenge is to do it
      while using the same general mechanism as that employed in Sifter Fusion, yet using economical data structures.

VI. Array supports (point charts).      
      