On Thu, 19 Nov 2009, Kirk, Benjamin (JSC-EG311) wrote: >> I was testing on 4, but from what I saw in Marro's test case, *one* >> processor will do it. It just takes one or two adaptive steps to >> trigger it too; I think I changed n_timesteps from 25 to 5 in ex10. >> Like I said, something is *seriously* wrong with our .xda I/O now... > > I just built trunk and enabled libHilbert, and vanilla ex10 runs fine on > one, two, three, and four processors (?) I'm not getting something...
Likewise: things work fine (for ex10) with libHilbert enabled. It appears that Marro's code was getting caught by multiple separate failures: one (which didn't catch ex10, but which in his test case still triggers an assertion error with libHilbert enabled) from the libHilbert collision bug, another (which kills ex10 too) from some bug in --disable-libHilbert, and another (which doesn't touch ex10) with --enable-libHilbetr but global renumbering commented out, which doesn't trigger an assertion failure but which does cause corrupt I/O after ~10 AMR steps. I'm reenabling libHilbert by default for now, reverting us back to "seriously broken" from "completely broken"... Gotta run for now; I'll get back to this in a couple hours. --- Roy ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
