On Fri, Jan 25, 2013 at 6:37 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:
Ominous only in the sense that the old assert()->libmesh_assert()
change was ominous: it touches a ton of lines.  I'm finishing up the
implementation of that processor_id_type and dof_id_type stuff, so
soon we won't have to be incompatible with >32K processor or >2G dof
systems.

Sounds reasonable.
 
I actually was making one API-incompatible change while I was at it,
though - passing a vector<dof_id_type> (default unsigned int) rather
than a vector<int> to SparseMatrix::zero_rows.  The original design
appears to have been motivated by "Petsc uses int, and static_cast is
unpleasant", which are both true but not really good enough reason to
have an API which uses different index signed-ness from the whole rest
of the library.

Hehe... I wrote that function... and it wasn't "designed" so much as I needed it to work and I implemented it in a way that works ;-)

Now - I have a question.  I was going to call this new system "MeshTransfer"... but I'm now thinking that might not be the best name (we're not transferring meshes... we're transferring/mapping values).  So how about "SolutionTransfer" and I'll put it in src/solution_transfer and include/solution_transfer.

Anyone have a preference?

BTW - I'm done with the interface... and I did go ahead and add System to Variable... it made the interface nice and tidy!

Derek