Jed, If you are going to do this for Mat then you should do it universally for all objects. Each object prints its help messages only once. All of this can be hidden inside the PetscOptionsBegin .... infrastructure so you do not need to modify the Mat source code or any other object source code.
Now finish your dang dissertation, if we keep this up you'll have totally rewritten PETSc during the time you should have written your dissertation. Good for us but not so good for you. I'll point out that this disease is contagious, I'm finishing up the massive destructor change to PETSc when I should be working on some dang SciDAC proposals. Barry On Apr 18, 2011, at 8:15 AM, Aron Ahmadia wrote: > Agreed, the overwhelming output from -h is tremendously annoying, and I > cannot always grep because I don't know what I'm grepping for :( > > A > > On Mon, Apr 18, 2011 at 3:43 PM, Jed Brown <jed at 59a2.org> wrote: > Currently Matrix Options are printed in MatView_Private which is called from > many places, e.g. > > MatAssemblyEnd > MatZeroRowsColumns > MatZeroRows > MatLUFactorNumeric > MatCholeskyFactorNumeric > > The problem here is that in time-stepping or a multigrid solve, it's common > to have these functions called hundreds or thousands of times which is really > overwhelming to -help output. One solution would be to store on a per-matrix > basis whether help has been displayed and only view it once (this implies > caching all the -mat_view_* options in the Mat, or calling with > PetscOptionsGetBool after the first time). The options could even be moved to > MatSetFromOptions, but that doesn't get called nearly as much as we would > probably like. > > There is also the somewhat deeper problem of multiple objects with the same > prefix (often no prefix). This is most visible for matrices inside of > multigrid and/or fieldsplit. It is easy to have more than 20 matrices with no > prefix so even if the multiple-output problem above was solved, it would > still be fairly overwhelming. I think this is somewhat harder to fix because > it would imply a per-prefix log of whether the option has been printed. I > think that the one special case of no-prefix Mat would already be a > significant usability improvement. >
