On Fri, Jul 20, 2012 at 10:19 PM, Roy Stogner <email@example.com> wrote:
What's weird is that I don't feel as tired this time as I did when my
On Fri, 20 Jul 2012, Kirk, Benjamin (JSC-EG311) wrote:
> On 7/20/12 3:17 PM, "Roy Stogner" <firstname.lastname@example.org> wrote:
>>> Why not print a trace to the screen when encountering an error and
>>> running serially, but failing back to the current trace files
>>> behavior when running in parallel?
>> I can't *believe* I didn't think of that.
> Don't be so hard on yourself - based on my memory both you and John should
> still be asymptoting back to your pre-offspring sensibilities.
eldest was a month and a half old and I was afraid of falling asleep
on the commute to work... but if I actually count up all the stupid
things I've done in just the past couple weeks, it's significantly
worse than before; I'm forced to conclude that my intelligence has
fallen so low that it's not even competent at self-estimation anymore.
And much easier and safer than trying to make OStreamProxy MPI-aware.
> Agree that's a great solution.
I don't think there'd be any *real* obstacles making that solution
thread-safe and properly memory-managed, but there would certainly be
places we could slip up.
On the subject of sleep-deprivation-stupidity and tricky memory
management: if anyone wants to code review the Parallel:: tricks I
added a couple weeks ago, I would appreciate it.
Parallel::Request::add_post_wait_work() is for allowing arbitrary
callback functors to be attached to a Request object so that the
wait() can do things like cleaning up temporary buffers after an
asynchronous send. We had a nasty race condition there before.
For the other new code (which is also now on a critical path:
MeshInput of a serial format in a parallel run) search parallel.h and
mesh_communication.C for "packed_range", and see the specializations
in packed_node.C and packed_elem.C and the utility class in
mesh_inserter_iterator.h. Basically this let us shave mesh broadcasts
down to 50 lines with sexy code like:
for (unsigned int l=0; l != n_levels; ++l)
Oh wow, very nice. I could actually use something like this in a couple of classes I recently built. Except my needs are even more straightforward. I just have lists of nodes (std::vector<Node *>) that I'd like to gather on all processors. Right now I'm just passing Ids and extracting them on each processor but it sounds like with the right function call, I could avoid that with all the fancy broadcast stuff you've built. Will this work outside of the mesh? I haven't really looked into it yet.
which handles communicating everything from boundary conditions to
neighbor topology to element DoF indices, using generic code that
ought to be easily extensible to other variable-size data types too.
I left PackedNode and PackedElem around for backwards compatibility,
but they could be eliminated if/when the Idaho folks want to use
packed_range based code instead.I bet we can take a look so that we can do some housekeeping here. We don't have this code scattered too far and wide.Cody
In hindsight I should have posted such a significant patch to
libmesh-devel before committing, despite it passing my tests. It was
originally only going to be affecting distributed ParallelMesh code
paths, and after realizing that it could greatly simplify SerialMesh
communication too I forgot to reconsider the question of whether or
not I should get additional eyes on it.
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
Libmesh-devel mailing list