On Tue, 15 Sep 2015, John Peterson wrote: > We should probably try to prevent this type of configuration from getting > run by throwing an error if the Eigen sparse solvers are invoked when > n_processors() > 1. > > @roystgnr any preferences for how to do this?
How are we not already throwing an error? This is probably my fault for dropping work on the FAQ I was going to add to the website, where "run in devel or debug mode!" was entry #1. In all the EigenSparseVector constructors: libmesh_assert_equal_to (n, n_local); I'm sometimes tempted to go the PETSc route and configure to only build devel mode by default, but I suspect that would just make the learning curve problem *worse*. At least when a new user sees weird results they're likely to ask the mailing list; when a new user sees slow results they may just assume the code is slow and silently move on. Perhaps this particular error is bad enough to be worth screaming about in opt mode? Maybe even adding the libmesh_opt_assert() macro(s) I wanted once upon a time, to get us in the habit of adding such asserts when they're valuable and cheap? The vector constructors are (pretty much by definition) not called in innermost loops, and if even that's too bad we could put the opt-assertion in the solver constructors and it won't even be in any outer loops. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
