I am in agreement with that. However my situation is more rudimentary than that.
If I run the same problem in ABAQUS, it uses a multifraontal direct solver and gets done in two minutes. If I use the -ksp_type preonly -pc_type lu on my code built on libmesh and petsc, it takes ~16GB in storage and half hour for solution. I am looking for ways to bring my solvers performance to that of ABAQUS, snd I think dof numbering is key. Hence this discussion. -Manav > On Feb 6, 2015, at 9:15 PM, Jed Brown <j...@jedbrown.org> wrote: > > David Knezevic <david.kneze...@akselos.com> writes: >> One of my colleagues has used it. Apparently it works, but it's very slow >> (not surprising). > > I propose that global storage as an algorithmic device (out-of-core > factorization, checkpointing to disk for transient adjoints, etc) is > nearly dead and will be soon. The time required to write the full > contents of memory to disk and read it back is about an hour on today's > large machines. > > If you don't have enough memory, use more nodes, up to the entire > machine; it will be more efficient than writing to global storage. If > you are running on the entire machine and still don't have enough > memory, you also don't have enough time in your allocation to run an > out-of-core algorithm (unless you're going to burn the entire annual > budget of an INCITE award on a single run). ------------------------------------------------------------------------------ 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
