From: John P. <pet...@cf...> - 2006-07-27 17:03:15
|
Hi, I'm still in the process of reducing this bug to a minimal test case, but I wanted to get a discussion started. It seems reading in adaptively-refined meshes works OK in serial, but fails in parallel. To see this, go the the ex10 directory and run: ./ex10 -n_timesteps 25 -init_timestep 0 ./ex10 -read_solution -n_timesteps 25 -init_timestep 25 This should work fine. Then try with 2 CPU: mpirun -np 2 ./ex10 -n_timesteps 25 -init_timestep 0 mpirun -np 2 ./ex10 -read_solution -n_timesteps 25 -init_timestep 25 This aborts in EquationSystems::reinit(). The error message is: Solving time step 25, time=0.6500... Refining the mesh... ERROR: Elements are not neighbors! [1] /home/peterson/code/libmesh/include/geom/elem.h, line p1_22877: p4_error: : 1 This line is in the Elem::which_neighbor_am_i() function, so either the mesh connectivity is wrong or that function is being called on an element it shouldn't be. Anyone know how I can get backtraces in parallel? I don't think gdb will work, but there was mention of using backtrace() ... Thanks, John |
From: John P. <pet...@cf...> - 2006-07-27 23:12:38
|
Hello, OK, gonna reply to my own message here: I think the problem is now fixed, we weren't setting node keys correctly in the broadcast_mesh() function. Example 10 is working in parallel now. -John John Peterson writes: > Hi, > > I'm still in the process of reducing this bug to a > minimal test case, but I wanted to get a discussion started. > It seems reading in adaptively-refined meshes works OK in > serial, but fails in parallel. To see this, go the the ex10 directory and run: > > ./ex10 -n_timesteps 25 -init_timestep 0 > ./ex10 -read_solution -n_timesteps 25 -init_timestep 25 > > This should work fine. Then try with 2 CPU: > > > mpirun -np 2 ./ex10 -n_timesteps 25 -init_timestep 0 > mpirun -np 2 ./ex10 -read_solution -n_timesteps 25 -init_timestep 25 > > This aborts in EquationSystems::reinit(). The error message is: > > Solving time step 25, time=0.6500... > Refining the mesh... > ERROR: Elements are not neighbors! > [1] /home/peterson/code/libmesh/include/geom/elem.h, line p1_22877: p4_error: : 1 > > > This line is in the Elem::which_neighbor_am_i() function, so either > the mesh connectivity is wrong or that function is being called on > an element it shouldn't be. Anyone know how I can get backtraces in > parallel? I don't think gdb will work, but there was mention of using > backtrace() ... > > Thanks, > John |
From: Roy S. <roy...@ic...> - 2006-07-28 01:14:35
|
On Thu, 27 Jul 2006, John Peterson wrote: > an element it shouldn't be. Anyone know how I can get backtraces in > parallel? I don't think gdb will work, but there was mention of using > backtrace() ... There's a doc with some sample code for it here: http://www.delorie.com/gnu/docs/glibc/libc_665.html I'd like to override the C assert() with something that spits out the whole backtrace, but I'm not sure what the best way to do that would be. --- Roy |