On Thu, 24 May 2012, Kirk, Benjamin (JSC-EG311) wrote: > This is great - let me know if there is anything in particular I can > do to help.
A sanity check on my upcoming refactoring would be nice; and an assurance that I'm not going to be stepping on your toes by deleting two of your helper classes. ;-) I'm going to get everything working with as few changes as possible to the PackedNode/PackedElem design first, but IMHO that's the wrong way to do things in the context of variable-length objects like a Node-with-DofObject-indices or an Elem. What I'd like to do for a final design is write Parallel:: specializations for data types T* (and containers and possibly iterator ranges of same). Parallel:: would assume methods T::packed_size() for deciding how much freed memory to preallocate, T::pack() (which currently takes a vector<int>, but would be modified to take an output iterator-to-int) to extend a container with that object's serialized representation, and T::unpack() (signature TBD - I definitely don't want to require a Mesh argument for something that ought to be otherwise pretty libMesh-independent, but Elem::unpack really needs to be able to query mesh.node_ptr()) to rebuild on the other side. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
