Re: [Libmesh-devel] reduced_basis_ex6 fails on ParallelMesh

2012-10-31 Thread David Knezevic
On 10/31/2012 05:33 PM, Roy Stogner wrote: > > And it doesn't look like it's ParallelMesh's fault. > > RBEIMConstruction::evaluate_mesh_function is querying a MeshFunction > object, and that query returns the _out_of_mesh_value (an empty > DenseVector by default) if it's asked for the value of a po

[Libmesh-devel] reduced_basis_ex6 fails on ParallelMesh

2012-10-31 Thread Roy Stogner
And it doesn't look like it's ParallelMesh's fault. RBEIMConstruction::evaluate_mesh_function is querying a MeshFunction object, and that query returns the _out_of_mesh_value (an empty DenseVector by default) if it's asked for the value of a point that's not within any active local or active ghos

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Kirk, Benjamin (JSC-EG311)
On Oct 31, 2012, at 12:30 PM, Roy Stogner wrote: > On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> redo the embarassing EquationSystems serialized I/O code path. In >> reading it last night I found some very, very poor algorithmic >> complexity I want to fix. > > If you're messing

Re: [Libmesh-devel] OS X Compilers

2012-10-31 Thread Kirk, Benjamin (JSC-EG311)
> > Bottom Line: I'm curious, does anyone have a completely working compiler > that runs all examples in optimized and debug mode on OS X? Yes, with macports gcc-4.5, macports petsc, and slepc. libmesh.automake opt & debug both pass all tests what petsc are you using? I found an issue with i

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Derek Gaston
On Wed, Oct 31, 2012 at 11:20 AM, Kirk, Benjamin (JSC-EG311) < [email protected]> wrote: > And also to redo the embarassing EquationSystems serialized I/O code path. > In reading it last night I found some very, very poor algorithmic > complexity I want to fix. > Awesome Ben! Thanks! De

Re: [Libmesh-devel] OS X Compilers

2012-10-31 Thread Cody Permann
Ben, Are you able to run all of the libMesh examples (automake branch) with GNU GCC on your mac? I've been chatting with Paul and he mentioned that misc_ex6 seg faults (which we have confirmed here), but we are also seeing a similar problem with adjoints_ex1. These problems aren't unique to the

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Roy Stogner
On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > redo the embarassing EquationSystems serialized I/O code path. In > reading it last night I found some very, very poor algorithmic > complexity I want to fix. If you're messing around in EquationSystems I/O, any chance you could excise ou

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Kirk, Benjamin (JSC-EG311)
> On Wed, 31 Oct 2012, Derek Gaston wrote: > >> Give me a bit - I'll test it in about an hour or so. > > I'll wait on you, thanks. > >> CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)? > > So far we've got Ben's, my, and Paul's votes for libMesh::CommWorld, > so I'll add t

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread John Peterson
On Wed, Oct 31, 2012 at 10:59 AM, Roy Stogner wrote: > > On Wed, 31 Oct 2012, Derek Gaston wrote: > >> Give me a bit - I'll test it in about an hour or so. > > > I'll wait on you, thanks. > >> CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)? > > > So far we've got Ben's, my, a

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Roy Stogner
On Wed, 31 Oct 2012, Derek Gaston wrote: Give me a bit - I'll test it in about an hour or so. I'll wait on you, thanks. CommWorld.sum(x)?  Comm_World.sum(x)?  Comm.sum(x)?  MPIWorld.sum(x)? So far we've got Ben's, my, and Paul's votes for libMesh::CommWorld, so I'll add that as a referenc

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Derek Gaston
Give me a bit - I'll test it in about an hour or so. Derek On Wed, Oct 31, 2012 at 10:25 AM, Roy Stogner wrote: > > On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > > > I applied this on libmesh.automake, which imposes strict namespacing, > and I had to add > > > > 'using namepace libMes

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Kirk, Benjamin (JSC-EG311)
On Oct 31, 2012, at 11:25 AM, Roy Stogner wrote: > CommWorld.sum(x)? Comm_World.sum(x)? Comm.sum(x)? MPIWorld.sum(x)? CommWorld.sum(x); gets my vote. Comm is too nebulous - easily could conflict with any other communicator that could exist in a program. The others just aesthetically off

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Roy Stogner
On Wed, 31 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > I applied this on libmesh.automake, which imposes strict namespacing, and I > had to add > > 'using namepace libMesh;' > > inside your anonymous namespace in parallel_implementation.h so that > Parallel:: was found properly. Bah - I forg

Re: [Libmesh-devel] Parallel:: refactoring

2012-10-31 Thread Kirk, Benjamin (JSC-EG311)
I applied this on libmesh.automake, which imposes strict namespacing, and I had to add 'using namepace libMesh;' inside your anonymous namespace in parallel_implementation.h so that Parallel:: was found properly. Then testing with FIN-S showed no issues! -Ben ---