On Wed, 9 Feb 2011, Vetter Roman wrote: > VTK output crashes when run in parallel (mpirun -n 2 ...). The following > assertion fails: > > Assertion `it!=_global_to_local_map.end()' failed. > [...]/libmesh/include/numerics/petsc_vector.h, line 1073, [...]
Yup - the VTK support was a contribution from a non-main developer, one who only needed and only wrote support for output of serial non-adaptive data. We figured that any capability was better than none, but I suppose at the very least we should have tossed a few lines like "if (n_processors>1) libmesh_not_implemented()" to give people more comprehensible warnings. > The assertion does NOT fail when running in serial mode (without > mpirun) or when using ExodusII_IO. Since I'm bound to VTK and > parallel processing, I will need to fix this. We'd appreciate that, thanks! > The problem seems to be that current_solution.operator() is called > for ALL dofs in line 333 of vtk_io.C, instead of only the local > ones. Therefore, the global-to-local index map doesn't contain the > sought indices, when processor 0 attempts to write data owned by > processor 1. Exactly. > Solution output appears to be more sophisticated in ExodusII_IO, > where MeshOutput<MT>::_build_variable_names_and_solution_vector is > called, which does a EquationSystems::allgather(). EquationSystems::allgather() is actually a second step up in sophistication from where VTK output is - it gathers geometry data and degree of freedom numbering in the case of a distributed mesh. The gathering (and sadly, the decimation of higher-order solutions) of vector data happens in EquationSystems::build_vector(); > What's the expert's ansatz to fixing VTK output? Should I have a go > at duplicating the ExodusII output procedure, I'm not an expert on the I/O classes, but that's probably the best way. ExodusII is at least decently maintained by people who are experts. ;-) > or does anybody see a simple(r) way of fixing the problem? Perhaps a > localize_to_one() call on the solution vector? Would that compromise > parallel efficiency? Right now *every* single-file I/O we do compromises parallel efficiency; if that's a serious bottleneck for you then you'll either need to write a support for the parallel multi-file VTK format or switch to Nemesis. --- Roy ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
