Just a heads up... I'm using all of that code extensively to do contact
ghosting with ParallelMesh. So whatever you do will probably break my
stuff. I'm not telling you this to keep you from it (my code needs a good
refactor anyway... so this will be a good opportunity to do that) just
letting you know that there are some people using those APIs...
On Fri, May 25, 2012 at 7:13 AM, Roy Stogner <roystgnr@...:
> 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.