April 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Fwd: [petsc-users] PCView only for one block ?
by Jed Brown 16 Apr '13

16 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Someone has been mucking with PCView_BJacobi? Under normal > circumstances where the same PC type is used on each block it only > prints a single block. Not sure why it suddenly prints something > for each block? Mikolaj, can you show the code that you use for setting up this bjacobi? > if (jac->same_local_solves) { > ierr = PetscViewerASCIIPrintf(viewer," Local solve is same for all blocks, in the following KSP and PC objects:\n");CHKERRQ(ierr); > if (jac->ksp && !jac->psubcomm) { > ierr = PetscViewerGetSingleton(viewer,&sviewer);CHKERRQ(ierr); > if (!rank) { > ierr = PetscViewerASCIIPushTab(viewer);CHKERRQ(ierr); > ierr = KSPView(jac->ksp[0],sviewer);CHKERRQ(ierr); > ierr = PetscViewerASCIIPopTab(viewer);CHKERRQ(ierr); > } > ierr = PetscViewerRestoreSingleton(viewer,&sviewer);CHKERRQ(ierr); > } else if (jac->psubcomm && !jac->psubcomm->color) { > ierr = PetscViewerASCIIGetStdout(mpjac->psubcomm->comm,&sviewer);CHKERRQ(ierr); > ierr = PetscViewerASCIIPushTab(viewer);CHKERRQ(ierr); > ierr = KSPView(*(jac->ksp),sviewer);CHKERRQ(ierr); > ierr = PetscViewerASCIIPopTab(viewer);CHKERRQ(ierr); FWIW, src/snes/examples/tutorials/ex7.c also produces verbose output. I understand the desire to show details when someone configures each subdomain differently, but I'd still rather have scalable output by default.

1 0

Re: [petsc-dev] SNESGetSNESLineSearch and TSGetTSAdapt
by Jed Brown 16 Apr '13

16 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > You gave me a list. I need a rule! Is the rule for setting and > getting a ABasenameXXXX from a BBasename object > BBasenameGet/SetXXX() rather than BBasenameGet/SetABasenameXXX()? > Where ABasename sometimes is the same as BBasename but need not be. Sounds good to me. > This is a reasonable rule to propose, appears to be mostly what we > have done, it needs to be documented in the developers manual and > any fixes made to the code. I am fine with it. > > Barry > > Note: There is a bit of difference between, for example, > MatGetNullSpace() where the alternative is MatGetMatNullSpace() and > MatGetLocalToGlobalMapping() versuse MatGetISLocalToGlobalMapping() > since the in first case ABasename == BBasename while in the second it > does not. We repeated the IS part in some related API at one point, but it spills over 31 characters and I don't think it communicates useful information. > A part of me wants to keep the A/BBasename but in the usual case it is > redundant and wordy and we haven't kept it anyways in the past. Note: > if we had a really really good pretty printer I could have it always > presented in my Emacs buffers with the wordiness :-) I believe this will do that: $ cat >> .git/info/attributes <<EOF *.c filter=barry *.h filter=barry EOF $ git config filter.barry.clean '!sed s/MatGetMatNullSpace/MatGetNullSpace/g' $ git config filter.barry.smudge '!sed s/MatGetNullSpace/MatGetMatNullSpace/g' I do not recommend doing this.

1 0

Re: [petsc-dev] SNESGetSNESLineSearch and TSGetTSAdapt
by Barry Smith 16 Apr '13

16 Apr '13

On Apr 16, 2013, at 2:02 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> Jed, >> >> Please state what the "more established convention" is for these names? You gave me a list. I need a rule! Is the rule for setting and getting a ABasenameXXXX from a BBasename object BBasenameGet/SetXXX() rather than BBasenameGet/SetABasenameXXX()? Where ABasename sometimes is the same as BBasename but need not be. This is a reasonable rule to propose, appears to be mostly what we have done, it needs to be documented in the developers manual and any fixes made to the code. I am fine with it. Barry Note: There is a bit of difference between, for example, MatGetNullSpace() where the alternative is MatGetMatNullSpace() and MatGetLocalToGlobalMapping() versuse MatGetISLocalToGlobalMapping() since the in first case ABasename == BBasename while in the second it does not. A part of me wants to keep the A/BBasename but in the usual case it is redundant and wordy and we haven't kept it anyways in the past. Note: if we had a really really good pretty printer I could have it always presented in my Emacs buffers with the wordiness :-) > > MatGetNullSpace returns the null space of a matrix inside a namespaced object MatNullSpace. > > MatGetColoring returns a coloring for a matrix inside a namespaced object MatColoring. > > MatGetInfo returns info about a matrix inside a namespaced object MatInfo. > > MatGetLocalToGlobalMapping returns a local-to-global mapping inside a namespaced object ISLocalToGlobalMapping. > > SNESGetConvergedReason gets the reason SNES converged/diverged inside a namespaced object SNESConvergedReason. > > TSGetAdapt returns an adaptive controller for TS inside a namespaced object TSAdapt. > > SNESGetLineSearch returns a line-search method for SNES inside a namespaced object SNESLineSearch. > > > Is this really inconsistent? Surely saying SNESGetSNESLineSearch is > inconsistent with the others, so if we choose that name, we're obliged > to write MatGetMatNullSpace, MatGetMatColoring, MatGetMatInfo, ... > > I don't think repeating the namespace like that offers any value, and > doing it only for TSGetTSAdapt and SNESGetSNESLineSearch is anomalous.

1 0

Re: [petsc-dev] SNESGetSNESLineSearch and TSGetTSAdapt
by Jed Brown 16 Apr '13

16 Apr '13

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Jed, > > Please state what the "more established convention" is for these names? MatGetNullSpace returns the null space of a matrix inside a namespaced object MatNullSpace. MatGetColoring returns a coloring for a matrix inside a namespaced object MatColoring. MatGetInfo returns info about a matrix inside a namespaced object MatInfo. MatGetLocalToGlobalMapping returns a local-to-global mapping inside a namespaced object ISLocalToGlobalMapping. SNESGetConvergedReason gets the reason SNES converged/diverged inside a namespaced object SNESConvergedReason. TSGetAdapt returns an adaptive controller for TS inside a namespaced object TSAdapt. SNESGetLineSearch returns a line-search method for SNES inside a namespaced object SNESLineSearch. Is this really inconsistent? Surely saying SNESGetSNESLineSearch is inconsistent with the others, so if we choose that name, we're obliged to write MatGetMatNullSpace, MatGetMatColoring, MatGetMatInfo, ... I don't think repeating the namespace like that offers any value, and doing it only for TSGetTSAdapt and SNESGetSNESLineSearch is anomalous.

1 0

Re: [petsc-dev] fortran examples and tutorials testing
by Matthew Knepley 16 Apr '13

16 Apr '13

On Tue, Apr 16, 2013 at 12:23 PM, Travis Austin <austin(a)txcorp.com> wrote: > > Thanks for the quick response. A related question is are examples in the > tutorials tested before the release or > only the examples in tests? > Everything is tested (I gather not everything got fixed). Matt > Travis > > =============================== > Travis Austin, Ph.D > VP, Computational Mathematics > Tech-X Corporation > 5621 Arapahoe Ave > Boulder, CO 80303 > austin(a)txcorp.com > =============================== > > > > On Apr 16, 2013, at 11:17 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Tue, Apr 16, 2013 at 12:12 PM, Travis Austin <austin(a)txcorp.com> wrote: > >> Hi, >> >> I have been digging into the tutorials directories in PETSc and wanting >> to understand how the makefile breaks up fortran >> examples into TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90. (This is follow >> on work from the Tech-X Phase >> I related to PETSc.) >> >> There appear to be some F90 examples that are mixed in >> TESTEXAMPLES_FORTRAN. For example, in the snes >> tutorials, I see this: >> >> snes/examples/tutorials/makefile:TESTEXAMPLES_FORTRAN = ex1f.PETSc >> runex1f ex1f.rm ex40f90.PETSc runex40f90 ex40f90.rm >> > > Its a mistake. > > >> In other places, anything with an f90 in the name is under >> TESTEXAMPLES_F90. >> >> Is there any particular strategy for how files are placed >> under TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90? >> >> Another related question is that some of the F90 examples have a .F >> suffix and others have a .F90 suffix which is of course >> related to formatting but my guess is the committer of these files just >> following their own preferences. >> (See snes/examples/tutorials/ex39f90.F and ex40f90.F90.) >> > > F90 is wrong, another mistake. > > Matt > > >> Does anyone know if there was a reason that ex39f90 was made *.F and >> ex40f90 was make *.F90? I'm trying to parse some >> of these examples based on suffixes and different suffixes makes is a bit >> more cumbersome. >> >> Thanks for any help, >> Travis >> >> =============================== >> Travis Austin, Ph.D >> VP, Computational Mathematics >> Tech-X Corporation >> 5621 Arapahoe Ave >> Boulder, CO 80303 >> austin(a)txcorp.com >> =============================== >> >> >> >> > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] fortran examples and tutorials testing
by Travis Austin 16 Apr '13

16 Apr '13

Thanks for the quick response. A related question is are examples in the tutorials tested before the release or only the examples in tests? Travis =============================== Travis Austin, Ph.D VP, Computational Mathematics Tech-X Corporation 5621 Arapahoe Ave Boulder, CO 80303 austin(a)txcorp.com =============================== On Apr 16, 2013, at 11:17 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Apr 16, 2013 at 12:12 PM, Travis Austin <austin(a)txcorp.com> wrote: > Hi, > > I have been digging into the tutorials directories in PETSc and wanting to understand how the makefile breaks up fortran > examples into TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90. (This is follow on work from the Tech-X Phase > I related to PETSc.) > > There appear to be some F90 examples that are mixed in TESTEXAMPLES_FORTRAN. For example, in the snes > tutorials, I see this: > > snes/examples/tutorials/makefile:TESTEXAMPLES_FORTRAN = ex1f.PETSc runex1f ex1f.rm ex40f90.PETSc runex40f90 ex40f90.rm > > Its a mistake. > > In other places, anything with an f90 in the name is under TESTEXAMPLES_F90. > > Is there any particular strategy for how files are placed under TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90? > > Another related question is that some of the F90 examples have a .F suffix and others have a .F90 suffix which is of course > related to formatting but my guess is the committer of these files just following their own preferences. > (See snes/examples/tutorials/ex39f90.F and ex40f90.F90.) > > F90 is wrong, another mistake. > > Matt > > Does anyone know if there was a reason that ex39f90 was made *.F and ex40f90 was make *.F90? I'm trying to parse some > of these examples based on suffixes and different suffixes makes is a bit more cumbersome. > > Thanks for any help, > Travis > > =============================== > Travis Austin, Ph.D > VP, Computational Mathematics > Tech-X Corporation > 5621 Arapahoe Ave > Boulder, CO 80303 > austin(a)txcorp.com > =============================== > > > > > > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener

1 0

Re: [petsc-dev] fortran examples and tutorials testing
by Matthew Knepley 16 Apr '13

16 Apr '13

On Tue, Apr 16, 2013 at 12:12 PM, Travis Austin <austin(a)txcorp.com> wrote: > Hi, > > I have been digging into the tutorials directories in PETSc and wanting to > understand how the makefile breaks up fortran > examples into TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90. (This is follow > on work from the Tech-X Phase > I related to PETSc.) > > There appear to be some F90 examples that are mixed in > TESTEXAMPLES_FORTRAN. For example, in the snes > tutorials, I see this: > > snes/examples/tutorials/makefile:TESTEXAMPLES_FORTRAN = ex1f.PETSc runex1f > ex1f.rm ex40f90.PETSc runex40f90 ex40f90.rm > Its a mistake. > In other places, anything with an f90 in the name is under > TESTEXAMPLES_F90. > > Is there any particular strategy for how files are placed > under TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90? > > Another related question is that some of the F90 examples have a .F suffix > and others have a .F90 suffix which is of course > related to formatting but my guess is the committer of these files just > following their own preferences. > (See snes/examples/tutorials/ex39f90.F and ex40f90.F90.) > F90 is wrong, another mistake. Matt > Does anyone know if there was a reason that ex39f90 was made *.F and > ex40f90 was make *.F90? I'm trying to parse some > of these examples based on suffixes and different suffixes makes is a bit > more cumbersome. > > Thanks for any help, > Travis > > =============================== > Travis Austin, Ph.D > VP, Computational Mathematics > Tech-X Corporation > 5621 Arapahoe Ave > Boulder, CO 80303 > austin(a)txcorp.com > =============================== > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] SNESGetSNESLineSearch and TSGetTSAdapt
by Barry Smith 16 Apr '13

16 Apr '13

Jed, Please state what the "more established convention" is for these names? Thanks Barry On Apr 16, 2013, at 8:20 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > >> Okay, that makes sense. I agree. > > TSGetAdapt is in 'next'. SNESGetSNESLineSearch is in > 'jed/snesgetlinesearch' which is not yet merged. I'll wait for comment > from Peter or Barry before merging.

1 0

fortran examples and tutorials testing
by Travis Austin 16 Apr '13

16 Apr '13

Hi, I have been digging into the tutorials directories in PETSc and wanting to understand how the makefile breaks up fortran examples into TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90. (This is follow on work from the Tech-X Phase I related to PETSc.) There appear to be some F90 examples that are mixed in TESTEXAMPLES_FORTRAN. For example, in the snes tutorials, I see this: snes/examples/tutorials/makefile:TESTEXAMPLES_FORTRAN = ex1f.PETSc runex1f ex1f.rm ex40f90.PETSc runex40f90 ex40f90.rm In other places, anything with an f90 in the name is under TESTEXAMPLES_F90. Is there any particular strategy for how files are placed under TESTEXAMPLES_FORTRAN and TESTEXAMPLES_F90? Another related question is that some of the F90 examples have a .F suffix and others have a .F90 suffix which is of course related to formatting but my guess is the committer of these files just following their own preferences. (See snes/examples/tutorials/ex39f90.F and ex40f90.F90.) Does anyone know if there was a reason that ex39f90 was made *.F and ex40f90 was make *.F90? I'm trying to parse some of these examples based on suffixes and different suffixes makes is a bit more cumbersome. Thanks for any help, Travis =============================== Travis Austin, Ph.D VP, Computational Mathematics Tech-X Corporation 5621 Arapahoe Ave Boulder, CO 80303 austin(a)txcorp.com ===============================

1 0

Fwd: [petsc-users] PCView only for one block ?
by Barry Smith 16 Apr '13

16 Apr '13

Someone has been mucking with PCView_BJacobi? Under normal circumstances where the same PC type is used on each block it only prints a single block. Not sure why it suddenly prints something for each block? if (jac->same_local_solves) { ierr = PetscViewerASCIIPrintf(viewer," Local solve is same for all blocks, in the following KSP and PC objects:\n");CHKERRQ(ierr); if (jac->ksp && !jac->psubcomm) { ierr = PetscViewerGetSingleton(viewer,&sviewer);CHKERRQ(ierr); if (!rank) { ierr = PetscViewerASCIIPushTab(viewer);CHKERRQ(ierr); ierr = KSPView(jac->ksp[0],sviewer);CHKERRQ(ierr); ierr = PetscViewerASCIIPopTab(viewer);CHKERRQ(ierr); } ierr = PetscViewerRestoreSingleton(viewer,&sviewer);CHKERRQ(ierr); } else if (jac->psubcomm && !jac->psubcomm->color) { ierr = PetscViewerASCIIGetStdout(mpjac->psubcomm->comm,&sviewer);CHKERRQ(ierr); ierr = PetscViewerASCIIPushTab(viewer);CHKERRQ(ierr); ierr = KSPView(*(jac->ksp),sviewer);CHKERRQ(ierr); ierr = PetscViewerASCIIPopTab(viewer);CHKERRQ(ierr); } } else { Begin forwarded message: > From: Jed Brown <jedbrown(a)mcs.anl.gov> > Subject: Re: [petsc-users] PCView only for one block ? > Date: April 16, 2013 9:36:53 AM CDT > To: Matthew Knepley <knepley(a)gmail.com>, PETSc users list <petsc-users(a)mcs.anl.gov> > Reply-To: PETSc users list <petsc-users(a)mcs.anl.gov> > > Matthew Knepley <knepley(a)gmail.com> writes: > >> Pull out the subpc you want and call PCView. There is nothing from the >> command line. > > I would be in favor of changing the default command line behavior. The > current behavior makes -ksp_view output hopeless for large runs. I > think -<solver>_view should always produce scalable output by default.

1 0