On Thu, 12 May 2011, Derek Gaston wrote: > Sent from my iPad > > On May 12, 2011, at 5:22 PM, Roy Stogner <[email protected]> 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() probably doesn't even work correctly for Petsc+MPI >> when --enable-ghosted-vectors is off. > > Why would that be? It would just run the old code with the > localize().... if it worked before it would still work now.
Ah, you're right - I wasn't thinking about the other half of the ifdef in the new update. That would explain why my "disable MPI" test failed but my "disable everything" test succeeded. But in that case I have no idea *what* is going on with PETSc w/o MPI, just that it's now dying in ex0 when the libmesh_assert at petsc_vector.C:619 fails. > As for operator=, David and I shored it up for ghosted = parallel a > while ago. Sure, for PETSc. Trilinos is now throwing exceptions, though. (Barely... "terminate called after throwing an instance of 'int'", guys, seriously?). Don't we basically fall back to SERIAL there when GHOSTED is requested? And then System::update doesn't check whether current_local_solution is ghosted, just whether it could have been ghosted? > All of our regression tests pass with the new System::update()... > > Can you pinpoint a problem that doesn't work properly? We might be > able to take a look at it. > > I do agree that there might be better ways... and I'm committed to > looking into them... but we need to understand why this wouldn't work > because that would mean there is a serious implementation issue with > operator=. I don't think it's going to hit anything you're using; most of our stuff still passes. Here's our two tested configurations that are now failing: module load intel/10.1 tbb mkl-pecos petsc-nompi glpk vtk && ./configure --enable-everything --disable-mpi module load intel/11.1-ubuntu tbb mpich2/1.2.1 mkl-pecos petsc slepc trilinos glpk vtk &&./configure --enable-everything --enable-mpi --with-mpi=$MPI_DIR --disable-petsc --disable-laspack I'm sure it's harder, but could you answer the same question? Is it possible to get a simple app (ex19 with --enable-parmesh and the refinement level cranked way up??) to fail with the old System::update()? I just finished fixing some (app-level) bugs that only triggered on several dozen nodes, which was quite an unpleasant experience. If there's a possible gotcha that only shows up on several hundred nodes then I'd like to figure out how to assert (and/or better, regression test) the hell out of it. --- Roy ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
