Eric: The nonscalable implementation is robust, and faster for small to medium size problems, thus we set it as the default. You can switch with option '-matmatmult_via scalable', which requires estimate of nonzeros A*B. The estimate was buggy, not well-tested. If you encounter any problem, let us know.
Hong On Mon, Jun 20, 2016 at 10:49 PM, Eric Chamberland < [email protected]> wrote: > > > Le 2016-06-20 23:37, Barry Smith a écrit : > >> On Jun 20, 2016, at 10:32 PM, Eric Chamberland < >>> [email protected]> wrote: >>> >>> ok, but what about -matmatmult_via scalable? >>> >> Both should work. It just may be one is faster or slower than the >> other depending on the problem size. >> > ok, digging further, I found this into blaming the code: > > 0fc8cf34 (Hong Zhang 2013-06-27 14:04:58 -0500 696) /* same as > MatMatMultSymbolic_MPIAIJ_MPIAIJ_nonscalable(), except using LLCondensed to > avoid O(BN) memory requirement */ > > But the commit comment says: > ... > rename MatMatMultSymbolic_MPIAIJ_MPIAIJ -> > MatMatMultSymbolic_MPIAIJ_MPIAIJ_nonscalable (non-default) > > But it *is* the default... since another commit: > > commit 0d3441ae8a080c728abf17e90308c510e39e951b > Author: Hong Zhang <[email protected]> > Date: Mon Aug 24 16:40:35 2015 -0500 > > add MatPtAPxxx_MPIAIJ_MPIAIJ_new > > which changed the behaviour programmed in 0fc8cf34. Is it normal? > > Eric > > >
