> On Feb 6, 2015, at 9:40 PM, Jed Brown <[email protected]> wrote: > > Manav Bhatia <[email protected]> writes: >> I am not sure if I understand your point. Are you saying that using a >> fill-reducing ordering for the dofs would not change the performance >> of a direct solver? > > Correct. The solver is already computing an ordering (e.g., with nested > dissection). You can change the ordering algorithm as a run-time option > to most solvers. "Natural" ordering is an option with the PETSc > solvers, but it's pretty much always super slow. > > Either ABAQUS is building a different matrix (e.g., different > discretization) or using a different ordering algorithm, but there is no > point reordering your dofs to "help out".
Ok. Then how does the discussion about the fill-reduction using something like metis fit into this: http://en.wikipedia.org/wiki/Sparse_matrix#Reducing_fill-in <http://en.wikipedia.org/wiki/Sparse_matrix#Reducing_fill-in> http://matrixprogramming.com/2008/05/metis <http://matrixprogramming.com/2008/05/metis> Does that not qualify as a reordering algorithm? Or are you talking about a matrix that is already available in dense format and the dof connectivity is not know? One could still deduce some connectivity information from the sparse matrix storage, and use that to run through METIS. Or not? -Manav ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
