December 2014 - petsc-dev - mailman3.cels.anl.gov

RegisterAllCalled visibility
by Tobin Isaac 12 Dec '14

12 Dec '14

Hi all, I'm trying to learn about PETSc's dynamic library framework. I've noticed that XXXInitializePackage() routines are idempotent, but XXXRegisterAll() routines are not, and usually have a visible XXXRegisterAllCalled boolean to guard against multiple calls (but not always). Then there are comments that say "In general, if there is more than one DLL then XXXRegisterAll() may be called several times." I don't understand the different handling between initialization and registration, especially because the initialization routines generally call the registration routines. Any help? Thanks, Toby

1 0

Zero sized VecSetValues
by Pierre Jolivet 12 Dec '14

12 Dec '14

Hello, Taking http://www.mcs.anl.gov/petsc/petsc-current/src/vec/vec/examples/tutorials/e… and changing its 56th line from VecSetValues(x,1,&i,&one,ADD_VALUES); to VecSetValues(x,0,NULL,NULL,ADD_VALUES); yield the following error (at least --with-debug=1): [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: Invalid pointer [0]PETSC ERROR: Null Pointer: Parameter # 3 What is the rationale behind first checking the pointers, then doing the work or lack thereof, instead of, first checking if there is some work to do, and only then check the pointers (à la MPI) ? Thank you for your help, Pierre

1 0

More Fortran Interfaces
by John O'Sullivan 08 Dec '14

08 Dec '14

Hi, I'm working with Adrian on our PetSc project at the University of Auckland. I think I've found a couple more fortran interfaces that are missing: DMPlexGetFaceFields DMPlexGefFaceGeometry I get the error: Undefined symbols for architecture x86_64: "_dmplexgetfacefields_", referenced from: _rhs_darcy_local.2542 in darcy.o "_dmplexgetfacegeometry_", referenced from: _rhs_darcy_local.2542 in darcy.o I haven't got to the restore stage yet but I think probably these ones are missing too: DMPlexRestoreFaceFields DMPlexRestoreFaceGeometry Also I'm having trouble declaring a pointer to a PetscFVFaceGeom type to use with the DMPlexGetFaceGeometry. Is there a trick to this or maybe its definition in fortran is missing too? Thanks very much! Cheers John -- Dr John O'Sullivan Lecturer Department of Engineering Science University of Auckland, New Zealand email: jp.osullivan at auckland.ac.nz<https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev> tel: +64 (0)9 923 85353

1 0

Re: [petsc-dev] question about linear solver examples in petsc
by Matthew Knepley 05 Dec '14

05 Dec '14

On Thu, Dec 4, 2014 at 1:00 PM, Raphaël Couturier < raphael.couturier(a)univ-fcomte.fr> wrote: > Hello Matt, > > Thank you for all your work on PETSc. > I would like to know if you or your colleagues have some examples of code > with linear systems in PETSc that are difficult to solve with more of less > all preconditioners and GMRES? > I am Cc'ing petsc-dev since better feedback might come from there. ex15 is the p-Laplacian, ex16 is large deformation elasticity (ex54 is infinitesimal). These are somewhat difficult, but most of the difficulty is getting MG to work right. These are likely candidates to be solved with FMG, neglecting Krylov. In the past, hard things to solve have generally been very non-normal matrices. We do not maintain a catalogue since we (I at least) have almost given up on black box solvers in favor of focusing on preconditioners for certain problem types. However, other people on here might have specific problems that they need solved. Thanks, Matt > In fact, I am working on a new method which solves, for example ex15 or > ex54 of ksp/ksp/examples/tutorials with large instances (for example > 200,000,000 components or more) with the mg preconditioner and for example > 8192 cores, faster than GMRES. > So I would like to know if it is possible to test other difficult examples? > > I have submitted my work to a conference, and as soon as this work is > accepted, I will be able to give more details on the method. > > Best wishes, > > Raphaël Couturier > http://members.femto-st.fr/raphael-couturier/ > > > > -- 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] bitbucket giving wrong information
by Barry Smith 04 Dec '14

04 Dec '14

> On Dec 4, 2014, at 9:25 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> It seems to me the simplest way is simply to include the PR number >> into the new local branch name that person made. I don't see why >> we need any of the complicated goobly guck below if we just follow >> my proposal above. Nor do I see any harm in my proposal. If you >> want to provide also a description of the pull request >> functionality we could have >> >> myuserid/pullrequest-number-mychosendescription > > Fine, do you have a preference between these? > > pr123/username/description > username/pr123-description Don't care. Didn't realize branches could have two slashes > > Spelling out "pullrequest" uses a lot of line space > >> "Annotating the PR # into the merge commit" as an additional convention is fine with me also but is orthogonal to the finding above." > > Sure, but valuable because the reference shows up as a PR comment so > it's easier to tell when a given PR is in 'next'.

1 0

Re: [petsc-dev] bitbucket giving wrong information
by Jed Brown 04 Dec '14

04 Dec '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > It seems to me the simplest way is simply to include the PR number > into the new local branch name that person made. I don't see why > we need any of the complicated goobly guck below if we just follow > my proposal above. Nor do I see any harm in my proposal. If you > want to provide also a description of the pull request > functionality we could have > > myuserid/pullrequest-number-mychosendescription Fine, do you have a preference between these? pr123/username/description username/pr123-description Spelling out "pullrequest" uses a lot of line space > "Annotating the PR # into the merge commit" as an additional convention is fine with me also but is orthogonal to the finding above." Sure, but valuable because the reference shows up as a PR comment so it's easier to tell when a given PR is in 'next'.

1 0

Re: [petsc-dev] bitbucket giving wrong information
by Barry Smith 04 Dec '14

04 Dec '14

> On Dec 4, 2014, at 6:00 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> It cannot be a choose, because I have to be able to find it without asking that person what they chose. That is it has to come automatically from the pull request. I suggest then simply >> >> pullrequest-number (where number is the number of the pull request). >> >> Or possibly >> >> myuserid/pullrequest-number (so everyone knows I am the one who made the local branch for the pull request) >> >> Comments, improvements? > > You want to get from PR to branch name or from branch name to PR? Given a PR I want to find the (new) local branch that someone made in response to it. Note that this new local branch may not yet have been merged into next etc or may have been. It seems to me the simplest way is simply to include the PR number into the new local branch name that person made. I don't see why we need any of the complicated goobly guck below if we just follow my proposal above. Nor do I see any harm in my proposal. If you want to provide also a description of the pull request functionality we could have myuserid/pullrequest-number-mychosendescription I see absolutely no reason not to include both the string pullrequest (so we know it is a special kind of branch) and the PR number (so we trivially know what pull request it is associated with). Comments? Barry "Annotating the PR # into the merge commit" as an additional convention is fine with me also but is orthogonal to the finding above." > > PR to branch name: > > git branch -r --contains $last_commit_in_PR > > or click on the commit and see the branch name on the right > > or (if the branch has been merged to 'next' and a convention of > annotating the PR # into the merge commit has been followed), > > git log --grep 'PR #123' next > > > Branch name to PR is not automatic even for in-repo branches, but if the > branch has been merged to 'next' with recommended annotation, this works > > git log --grep the-branch-name next

1 0

Re: [petsc-dev] bitbucket giving wrong information
by Jed Brown 04 Dec '14

04 Dec '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > It cannot be a choose, because I have to be able to find it without asking that person what they chose. That is it has to come automatically from the pull request. I suggest then simply > > pullrequest-number (where number is the number of the pull request). > > Or possibly > > myuserid/pullrequest-number (so everyone knows I am the one who made the local branch for the pull request) > > Comments, improvements? You want to get from PR to branch name or from branch name to PR? PR to branch name: git branch -r --contains $last_commit_in_PR or click on the commit and see the branch name on the right or (if the branch has been merged to 'next' and a convention of annotating the PR # into the merge commit has been followed), git log --grep 'PR #123' next Branch name to PR is not automatic even for in-repo branches, but if the branch has been merged to 'next' with recommended annotation, this works git log --grep the-branch-name next

1 0

Re: [petsc-dev] bitbucket giving wrong information
by Barry Smith 04 Dec '14

04 Dec '14

> On Dec 4, 2014, at 5:25 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> If we are doing this to generate a local branch that people can work with then we need to be more systemic with no my-branch-name stuff. If follow Dominics approach we should do >> >>> git fetch bitbucket:username/petsc their-branch-name:username/pullrequest-their-branch-name >>> git push -u origin username/pullrequest-their-branch-name > > Sometimes people don't choose meaningful branch names. I.e., sometimes > they commit on their master, other times they use different naming > conventions Do_Stuff. Yup, you are right, they could have any crazy name. > I don't see a problem with the integraor choosing > a better name. It cannot be a choose, because I have to be able to find it without asking that person what they chose. That is it has to come automatically from the pull request. I suggest then simply pullrequest-number (where number is the number of the pull request). Or possibly myuserid/pullrequest-number (so everyone knows I am the one who made the local branch for the pull request) Comments, improvements? > It's useful to annotate the merge (to 'next' and > 'master') with "PR #123" so that it gets linked from the PR page.

1 0

Re: [petsc-dev] bitbucket giving wrong information
by Jed Brown 04 Dec '14

04 Dec '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > If we are doing this to generate a local branch that people can work with then we need to be more systemic with no my-branch-name stuff. If follow Dominics approach we should do > >> git fetch bitbucket:username/petsc their-branch-name:username/pullrequest-their-branch-name >> git push -u origin username/pullrequest-their-branch-name Sometimes people don't choose meaningful branch names. I.e., sometimes they commit on their master, other times they use different naming conventions Do_Stuff. I don't see a problem with the integraor choosing a better name. It's useful to annotate the merge (to 'next' and 'master') with "PR #123" so that it gets linked from the PR page.

1 0