Xdmf::New()

After some discussion with several interested parties, we've decided to re-work Xdmf a bit. Most of the changes involve the API, particularly moving to smart pointers and a more full featured and customizable API for producing Xdmf in parallel.

The existing XML format will most likely stay the same with a few additions. So if you're currently producing Xdmf data outside the API this will have minimal impact. Also if you're just reading Xdmf as a file format this will have minimal impact as well.

Smart Pointers

 Smart pointers in C++ will help eliminate memory leaks and double free problems.
 Most likely the implementation will be intrusive smart pointers with reference counting.
 It is expected that moving to smart pointers will have minimal effect on performance while
 greatly increasing the efficiency of resource management.

API changes/additions for sharing and producing data in parallel

  While reading Xdmf is well defined and straight forward in the current API, producing and sharing
  the underlying geometric and computed data can become complex (particularly in a parallel computation).
  Since there can be several ways to represent the same data (a single large uniform grid, collections, etc.)
  it is best to allow the application to determine the proper representation and the most efficient method to
  achieve the result (generate the heavy data and collect the associated XML). What is needed is a more flexible 
  mechanism.

  Will Dicharry (Stellar Science Ltd Co) has proposed an API that looks very promising. If you'd like to take a look, the code is available at:
  [1]

Remove libxml2 dependencies from base objects - use containers

  Currently, Xdmf is tightly tied to libxml2, actually using the library to store state information. This leads to
  instances where data in the Xdmf objects can become out of sync with the data in the XML representation in libxml2.
  A better approach is probably to let the Xdmf objects store all necessary data internally using C++ containers and 
  decouple the generation of the XML using a visitor pattern. This would also allow for various other representations
  of the light data as they become necessary. 

Better Fortran Support

  Xdmf is currently 'C'-centric in that array dimensions are assumed to be row-major and data is accessed in that fashion.
  To properly use Xdmf with arrays in Fortran, which is column-major, the arrays need to be transposed on one end or the other.
  Transposing in memory may not work for huge arrays and transposing during I/O may incur significant overhead. At very least 
  there should be transposing support with options.

Additional Topology Support

  Additional Topology types

Static Geometry, Dynamic Attribute Support

  If the Topology and/or Geometry does not change over time, it would be more efficient to cache that information. The
  current implementation assumes that every <Grid> is independent and re-reads the Topo/Geo. One idea to use 
  XPointers in XML and mark the <Grid> with an XML attribute that tells Xdmf that it's possible to cache. Another idea
  is to cache the CData of the <DataItem> (from Dominik Szczerba) to flag identical heavy data items.

Active Grid an/or Attribute

  Some mechanism to mark a Grid or an Attribute as "active" so, by default, only that one is read. Very efficient, particularly
  during debugging.

Much more testing, example code, and example datasets

  CTest as much as possible. Take more advantage of the existing dashboards. Provide many more example datasets and code for things
  such as parallel I/O, ghost cells, Collections, etc.