Anton, I guess, when you reuse matrix and its symbolic factor with updated numerical values, superlu_dist requires this option. I'm cc'ing Sherry to confirm it.
I'll check petsc/superlu-dist interface to set this flag for this case. Hong On Tue, Oct 25, 2016 at 8:20 AM, Anton Popov <[email protected]> wrote: > Hong, > > I get all the problems gone and valgrind-clean output if I specify this: > > -mat_superlu_dist_fact SamePattern_SameRowPerm > What does SamePattern_SameRowPerm actually mean? > Row permutations are for large diagonal, column permutations are for > sparsity, right? > Will it skip subsequent matrix permutations for large diagonal even if > matrix values change significantly? > > Surprisingly everything works even with: > > -mat_superlu_dist_colperm PARMETIS > -mat_superlu_dist_parsymbfact TRUE > > Thanks, > Anton > > On 10/24/2016 09:06 PM, Hong wrote: > > Anton: >> >> If replacing superlu_dist with mumps, does your code work? >> >> yes >> > > You may use mumps in your code, or tests different options for > superlu_dist: > > -mat_superlu_dist_equil: <TRUE> Equilibrate matrix (None) > -mat_superlu_dist_rowperm <LargeDiag> Row permutation (choose one of) > LargeDiag NATURAL (None) > -mat_superlu_dist_colperm <METIS_AT_PLUS_A> Column permutation (choose > one of) NATURAL MMD_AT_PLUS_A MMD_ATA METIS_AT_PLUS_A PARMETIS (None) > -mat_superlu_dist_replacetinypivot: <FALSE> Replace tiny pivots (None) > -mat_superlu_dist_parsymbfact: <FALSE> Parallel symbolic factorization > (None) > -mat_superlu_dist_fact <SamePattern> Sparsity pattern for repeated > matrix factorization (choose one of) SamePattern SamePattern_SameRowPerm > (None) > > The options inside <> are defaults. You may try others. This might help > narrow down the bug. > > Hong > >> >> Hong >>> >>> On 10/24/2016 05:47 PM, Hong wrote: >>> >>> Barry, >>> Your change indeed fixed the error of his testing code. >>> As Satish tested, on your branch, ex16 runs smooth. >>> >>> I do not understand why on maint or master branch, ex16 creases inside >>> superlu_dist, but not with mumps. >>> >>> >>> I also confirm that ex16 runs fine with latest fix, but unfortunately >>> not my code. >>> >>> This is something to be expected, since my code preallocates once in the >>> beginning. So there is no way it can be affected by multiple >>> preallocations. Subsequently I only do matrix assembly, that makes sure >>> structure doesn't change (set to get error otherwise). >>> >>> Summary: we don't have a simple test code to debug superlu issue anymore. >>> >>> Anton >>> >>> Hong >>> >>> On Mon, Oct 24, 2016 at 9:34 AM, Satish Balay <[email protected]> wrote: >>> >>>> On Mon, 24 Oct 2016, Barry Smith wrote: >>>> >>>> > >>>> > > [Or perhaps Hong is using a different test code and is observing >>>> bugs >>>> > > with superlu_dist interface..] >>>> > >>>> > She states that her test does a NEW MatCreate() for each matrix >>>> load (I cut and pasted it in the email I just sent). The bug I fixed was >>>> only related to using the SAME matrix from one MatLoad() in another >>>> MatLoad(). >>>> >>>> Ah - ok.. Sorry - wasn't thinking clearly :( >>>> >>>> Satish >>>> >>> >>> >>> >> >> > >
