On Fri, Jan 25, 2013 at 6:37 PM, Roy Stogner <royst...@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
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
