On Sat, 21 Jul 2012, Cody Permann wrote:
for (unsigned int l=0; l != n_levels; ++l)
Parallel::broadcast_packed_range(&mesh,
mesh.level_elements_begin(l),
mesh.level_elements_end(l),
On Sat, Jul 21, 2012 at 8:17 PM, Cody Permann wrote:
>
>
> On Fri, Jul 20, 2012 at 10:19 PM, Roy Stogner wrote:
>
>>
>> On Fri, 20 Jul 2012, Kirk, Benjamin (JSC-EG311) wrote:
>>
>> > On 7/20/12 3:17 PM, "Roy Stogner" wrote:
>> >
>> >>> Why not print a trace to the screen when encountering an err
On Fri, Jul 20, 2012 at 10:19 PM, Roy Stogner wrote:
>
> On Fri, 20 Jul 2012, Kirk, Benjamin (JSC-EG311) wrote:
>
> > On 7/20/12 3:17 PM, "Roy Stogner" wrote:
> >
> >>> Why not print a trace to the screen when encountering an error and
> >>> running serially, but failing back to the current trace
On Fri, 20 Jul 2012, Kirk, Benjamin (JSC-EG311) wrote:
> On 7/20/12 3:17 PM, "Roy Stogner" 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 *belie
On 7/20/12 3:17 PM, "Roy Stogner" 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 - base
On Fri, 20 Jul 2012, Cody Permann 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.
Sounds like a pretty unform improvement, s
On Fri, Jul 20, 2012 at 1:39 PM, Roy Stogner wrote:
>
> On Fri, 20 Jul 2012, Cody Permann wrote:
>
> On Fri, Jul 20, 2012 at 12:34 PM, Roy Stogner
>> wrote:
>>
>> What's the reason why we need a separate print_trace() at
>> parameters.C:441? Shouldn't the libmesh_error() be throwing
On Fri, 20 Jul 2012, Cody Permann wrote:
On Fri, Jul 20, 2012 at 12:34 PM, Roy Stogner wrote:
What's the reason why we need a separate print_trace() at
parameters.C:441? Shouldn't the libmesh_error() be throwing an
exception which takes you to the libmesh_terminate_handler(
On Jan 10, 2011, at 11:40 AM, Roy Stogner wrote:
>
>
> On Mon, 10 Jan 2011, Cody Permann wrote:
>
>> So I've been looking into making some of the error handling stuff
>> more robust on the Mac Platform, i.e. catching NaNs better and
>> better stack traces. I was just looking through the print
On Mon, 10 Jan 2011, Cody Permann wrote:
> So I've been looking into making some of the error handling stuff
> more robust on the Mac Platform, i.e. catching NaNs better and
> better stack traces. I was just looking through the print_trace.C
> file and noticed that somebody has written wrappers
On Thu, 13 May 2010 08:40:22 -0600, Cody Permann wrote:
> On May 13, 2010, at 8:04 AM, Roy Stogner wrote:
>
> >
> > On Thu, 13 May 2010, Cody Permann wrote:
> >
> >> I'm just curious what the developers know about the "print_trace"
> >> functions in libMesh.
> >
> > It's just something I added
On Thu, 13 May 2010, Cody Permann wrote:
Actually this is exactly what I was look for: "found some code online",
"didn't have Mac libMesh builds" and "non-standardized voodoo". I just
didn't want to dive into it if it had been disabled or never enabled in the
first place if it had been done fo
On May 13, 2010, at 8:04 AM, Roy Stogner wrote:
>
> On Thu, 13 May 2010, Cody Permann wrote:
>
>> I'm just curious what the developers know about the "print_trace"
>> functions in libMesh.
>
> It's just something I added a few years back to make debugging
> unexpected assertion failures (of bot
On Thu, 13 May 2010, Cody Permann wrote:
> I'm just curious what the developers know about the "print_trace"
> functions in libMesh.
It's just something I added a few years back to make debugging
unexpected assertion failures (of both the libmesh_assert() and
libmesh_error() forms) easier. I ha
14 matches
Mail list logo
