David,
Superlu_dist seems sligtly better.
Does mumps crashes during numeric factorization due to memory limitation?
You may try the option
'-mat_mumps_icntl_14 ' with num>20
(ICNTL(14): percentage of estimated workspace
increase, default=20).
Run your code with '-help' to see all available
optio
On Sat, 14 Mar 2009, Hong Zhang wrote:
>
> David,
>
> Yes, MatMatSolve dominates. Can you also send us the output of
> '-log_summary' from superlu_dist?
>
> MUMPS only suppports centralized rhs vector b.
> Thus, we must scatter petsc distributed b into a seqential rhs vector (stored
> in root pro
David,
Yes, MatMatSolve dominates. Can you also send us the output of
'-log_summary' from superlu_dist?
MUMPS only suppports centralized rhs vector b.
Thus, we must scatter petsc distributed b into a seqential
rhs vector (stored in root proc) in the petsc interface, which
explains why the root
Thanks a lot Hong,
The switch definitely seemed to balance the load during the SuperLU matmatsolve.
Although I'm not completely sure what I'm seeing. Changing the #dof
also seemed to affect the load balance of the Mumps MatMatSolve.
I need to investigate a bit more.
Looking in the profile. The ma
David,
You may run with option '-log_summary ' and
check which function dominates the time.
I suspect the symbolic factorization, because it is
implemented sequentially in mumps.
If this is the case, you may swich to superlu_dist
which supports parallel symbolic factorization
in the latest releas
The majority of time in my code is spent in the MatMatSolve.
I'm running MatMatSolve in parallel using Mumps as the factored matrix.
Using top, I've noticed that during the MatMatSolve
the majority of the load seems to be on the root process.
Is this expected? Or do I most likely have a problem
