On Thu, 26 Mar 2009, Tim Kroeger wrote: > Oops... at which line does your g++ complain if you don't include stdlib.h?
exit() was undefined. > This non-reproducibility complicates the check whether the ghosted > vectors change the code behaviour a lot, because it is no longer > clear what "change the behaviour" means. That is pretty annoying from a verification standpoint. But I'm not sure how easy it is to get around. Google tells me that the very MPI standard itself doesn't guarantee a deterministic MPI_SUM. Plus, Jed Brown's email just came in, and the thought of overriding MatAssembly scares me. Although, the sequentialized MatAssembly hack he suggested was pretty interesting. I'd be tempted to add that behavior as a very-non-default option to FEMSystem... except, for it to really be useful you'd need a deterministic solve() too, and I'm sure the same distributed FP ordering problems come up there. > Perhaps I should just run both the ghosted and the non-ghosted version of my > application two times each and look whether the final results between > ghosted/non-ghosted differ consderably more than within these groups. Not > really convincing, but the best thing I can think of. (Unfortunately, I > deleted the results that I had from the runs some days ago since I thought of > a bug...) That's better than nothing. You could also try comparing the unassembled element residuals and matrices, written out to files like you did in this test problem setup. They won't be comparable after even one timestep (because a non-deterministic assembly leads to a differing solve() result leads to different initial conditions at the next timestep), but you could save a restart file from either version of the code, then load and test it in both versions. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
