Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Roy Stogner
On Thu, 12 May 2011, Derek Gaston wrote: > Sent from my iPad > > On May 12, 2011, at 5:22 PM, Roy Stogner wrote: > >> operator= is implemented correctly for src.type == dst.type, and as of >> mid-last year it's implemented correctly in PetscVector when one type >> is PARALLEL and the other is GH

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Derek Gaston
Sent from my iPad On May 12, 2011, at 5:22 PM, Roy Stogner wrote: > operator= is implemented correctly for src.type == dst.type, and as of > mid-last year it's implemented correctly in PetscVector when one type > is PARALLEL and the other is GHOSTED. That's it. The new > System::update() proba

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Roy Stogner
On Thu, 12 May 2011, Derek Gaston wrote: > On May 12, 2011, at 3:57 PM, Roy Stogner wrote: > >> Mind if I make it the default in svn? Using operator= caused >> regressions in our Petsc+noMPI and our Trilinos regression tests. > > What? That doesn't make any sense! If that's true then we need

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Derek Gaston
On May 12, 2011, at 3:57 PM, Roy Stogner wrote: > Mind if I make it the default in svn? Using operator= caused > regressions in our Petsc+noMPI and our Trilinos regression tests. What? That doesn't make any sense! If that's true then we need to figure out why like do we not have operator

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Roy Stogner
On Thu, 12 May 2011, Derek Gaston wrote: > On May 11, 2011, at 11:46 PM, Roy Stogner wrote: > >> What happens when you add the solution->close() but leave the >> communication to VecScatter rather than VecCopy? > > Dunno... I'll give it a whirl. Mind if I make it the default in svn? Using opera

Re: [Libmesh-devel] DofObject refactoring

2011-05-12 Thread Kirk, Benjamin (JSC-EG311)
> Very nice! > > I hope you got started on this because of the ParallelMesh work, not > because you were running into the same out-of-memory errors that were > killing Paul and I in FIN-S? It turned out that the root problem was > a memory leak in libablation svn trunk, now fixed there and in 0.

Re: [Libmesh-devel] DofObject refactoring

2011-05-12 Thread Roy Stogner
Very nice! I hope you got started on this because of the ParallelMesh work, not because you were running into the same out-of-memory errors that were killing Paul and I in FIN-S? It turned out that the root problem was a memory leak in libablation svn trunk, now fixed there and in 0.25.0. Any n

[Libmesh-devel] DofObject refactoring

2011-05-12 Thread Kirk, Benjamin (JSC-EG311)
I have just committed a change to the DofObject with completely restructures its internal storage. It is now using a contiguous buffer for all index information. I think this is something John wanted me to do about 5 years ago now... Two primary goals here: (1) make it more obvious to myself h

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Roy Stogner
On Thu, 12 May 2011, Derek Gaston wrote: > On May 11, 2011, at 11:46 PM, Roy Stogner wrote: > >> What happens when you add the solution->close() but leave the >> communication to VecScatter rather than VecCopy? > > Dunno... I'll give it a whirl. Thanks. >> Either way, I think we might want to a

Re: [Libmesh-devel] Change to System::update()

2011-05-12 Thread Derek Gaston
On May 11, 2011, at 11:46 PM, Roy Stogner wrote: > What happens when you add the solution->close() but leave the > communication to VecScatter rather than VecCopy? Dunno... I'll give it a whirl. > Either way, I think we might want to assert(closed) rather than adding > a usually-redundant close