September 2017 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Getting credit for Contributors graph on github?
by Satish Balay 28 Sep '17

28 Sep '17

On Thu, 28 Sep 2017, Satish Balay wrote: > So perhaps the following change. > > diff --git a/.mailmap b/.mailmap > index aa4cc0b5da..53fa78858d 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -39,7 +39,8 @@ Peter Brune <brune(a)uchicago.edu> <brune(a)cs.uchicago.edu> > Peter Brune <brune(a)uchicago.edu> <emppter@pbrune> > Peter Brune <brune(a)mcs.anl.gov> <brune@localhost> > Peter Brune <brune(a)mcs.anl.gov> <prbrune@localhost> > -Richard Tran Mills <rtm(a)eecs.utk.edu> > +Richard Tran Mills <rmills(a)rmills.org> <rmills(a)ornl.gov> > +Richard Tran Mills <rmills(a)rmills.org> <rtm(a)eecs.utk.edu> > Semih Özmen <semihozmen(a)gmail.com> > Shri Abhyankar <abhyshr(a)mcs.anl.gov> > Stefano Zampini <stefano.zampini(a)gmail.com> pushed this change Satish

1 0

Re: [petsc-dev] Getting credit for Contributors graph on github?
by Satish Balay 28 Sep '17

28 Sep '17

>From petsc/.mailmap # See 'git help shortlog' for details $ git log |grep ^Author |grep -i mills |sort | uniq Author: Richard Mills <rtm(a)eecs.utk.edu> Author: Richard Tran Mills <rmills(a)ornl.gov> Author: Richard Tran Mills <rmills(a)rmills.org> So perhaps the following change. diff --git a/.mailmap b/.mailmap index aa4cc0b5da..53fa78858d 100644 --- a/.mailmap +++ b/.mailmap @@ -39,7 +39,8 @@ Peter Brune <brune(a)uchicago.edu> <brune(a)cs.uchicago.edu> Peter Brune <brune(a)uchicago.edu> <emppter@pbrune> Peter Brune <brune(a)mcs.anl.gov> <brune@localhost> Peter Brune <brune(a)mcs.anl.gov> <prbrune@localhost> -Richard Tran Mills <rtm(a)eecs.utk.edu> +Richard Tran Mills <rmills(a)rmills.org> <rmills(a)ornl.gov> +Richard Tran Mills <rmills(a)rmills.org> <rtm(a)eecs.utk.edu> Semih Özmen <semihozmen(a)gmail.com> Shri Abhyankar <abhyshr(a)mcs.anl.gov> Stefano Zampini <stefano.zampini(a)gmail.com> Satish On Thu, 28 Sep 2017, Richard Tran Mills wrote: > In my case, the easiest thing for me to do would be to add all of my > addresses to my GitHub account, but I can't validate all of those, as I > have commits associated with email addresses (e.g., rmills(a)ornl.gov) that > haven't existed for years. > > I'm not familiar with the .mailmap file format. I want to make my > "canonical" email address "rmills(a)rmills.org", and map all of my old email > addresses to be associated with that. Can someone please tell me what I > need to enter in the .mailmap file to do this? > > (Followup question: Once I've done this, since GitHub knows that " > rmills(a)rmills.org" is associated with my account, will it count my commits > made under my old email addresses in the "contributors" graph?) > > Thanks, > Richard > > On Wed, Sep 27, 2017 at 4:20 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > > > Just a reminder for developers who want to get credit for their PETSc > > commits. > > > > > > Begin forwarded message: > > > > *From: *Jed Brown <jed(a)jedbrown.org> > > *Subject: **Re: [petsc-maint] Contributors graph on github?* > > *Date: *September 27, 2017 at 11:01:48 AM CDT > > *To: *Richard Tran Mills <rtmills(a)anl.gov>, PETSc-maint < > > petsc-maint(a)mcs.anl.gov> > > > > Add the addresses to your account or add yourself to .mailmap. > > > > Richard Tran Mills <rtmills(a)anl.gov> writes: > > > > I hadn't seen this "contributors" graph before and found it interesting: > > > > https://github.com/petsc/petsc/graphs/contributors > > > > What would I need to do to get the various commits I've made over there > > years to be associated with my 'rtmills' github account? > > > > --Richard > > > > > > >

1 0

Re: [petsc-dev] Getting credit for Contributors graph on github?
by Richard Tran Mills 28 Sep '17

28 Sep '17

In my case, the easiest thing for me to do would be to add all of my addresses to my GitHub account, but I can't validate all of those, as I have commits associated with email addresses (e.g., rmills(a)ornl.gov) that haven't existed for years. I'm not familiar with the .mailmap file format. I want to make my "canonical" email address "rmills(a)rmills.org", and map all of my old email addresses to be associated with that. Can someone please tell me what I need to enter in the .mailmap file to do this? (Followup question: Once I've done this, since GitHub knows that " rmills(a)rmills.org" is associated with my account, will it count my commits made under my old email addresses in the "contributors" graph?) Thanks, Richard On Wed, Sep 27, 2017 at 4:20 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > Just a reminder for developers who want to get credit for their PETSc > commits. > > > Begin forwarded message: > > *From: *Jed Brown <jed(a)jedbrown.org> > *Subject: **Re: [petsc-maint] Contributors graph on github?* > *Date: *September 27, 2017 at 11:01:48 AM CDT > *To: *Richard Tran Mills <rtmills(a)anl.gov>, PETSc-maint < > petsc-maint(a)mcs.anl.gov> > > Add the addresses to your account or add yourself to .mailmap. > > Richard Tran Mills <rtmills(a)anl.gov> writes: > > I hadn't seen this "contributors" graph before and found it interesting: > > https://github.com/petsc/petsc/graphs/contributors > > What would I need to do to get the various commits I've made over there > years to be associated with my 'rtmills' github account? > > --Richard > > >

1 0

Re: [petsc-dev] PetscSF in Fortran
by Adrian Croucher 27 Sep '17

27 Sep '17

hi On 28/09/17 15:34, Adrian Croucher wrote: > > So I think I will need to use PetscSFSetGraph() after all, so I can > increase the number of roots, update the leaf point indices, and also > update the remote root index for each leaf (presumably I can use the > original SF and PetscSFBcastBegin/ PetscSFBcastEnd to do that). > > If you agree, then I will need working Fortran interfaces to the > PetscSFGetGraph/ PetscSFSetGraph functions, which are missing at > present. Are you able to add those easily? It looks like the Fortran interfaces for PetscSFBcastBegin/ PetscSFBcastEnd are missing as well. I would need those to make this work. - Adrian -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.croucher(a)auckland.ac.nz tel: +64 (0)9 923 4611

1 0

Re: [petsc-dev] PetscSF in Fortran
by Adrian Croucher 27 Sep '17

27 Sep '17

hi On 28/09/17 04:18, Matthew Knepley wrote: > > Okay, I think this should be easy to solve. > > First a little bit about SF. There are two parts to the specification. > You have the communication part, which maps > a certain location p on this process to another location q on another > process. This might not change for you. The > second part just tells it how big the data array is (numRoots), which > is the thing that the locations in the communication > part index into. > > So my question is, where did you put the numbers for the points you > added? Are they after all points, or only after the old cells? > I think you can easily create the new SF using the info from SFGetGraph(). I've had a closer look at how the SF stuff works (partly by viewing the point SF from the original DM) and I think I understand it now. There were two things I hadn't realised: 1) It looks like all DM points are always considered potential roots for leaves on another process, which is why it complained with an error message when the number of roots was less than pEnd . I don't think this really makes so much sense in the dual-porosity mesh case I'm working on, because the new points I'm adding are all 'inside' the original cells and have no possible connection with any other points. So they can't be roots for any off-process leaf points. But I guess it won't hurt to tell it that they can (by increasing the number of roots passed to PetscSFSetGraph so it's equal to the new pEnd). 2) Because I'm doing finite volume I had only thought about ghost cells, but the SF needs to include leaf points in other height strata as well (vertices, edges and faces). My new points in each stratum have been added after the partition ghost points, so the leaf cells won't have changed their point indices. However the leaf points in other strata will have been shifted (because of points added into preceding strata). So I think I will need to use PetscSFSetGraph() after all, so I can increase the number of roots, update the leaf point indices, and also update the remote root index for each leaf (presumably I can use the original SF and PetscSFBcastBegin/ PetscSFBcastEnd to do that). If you agree, then I will need working Fortran interfaces to the PetscSFGetGraph/ PetscSFSetGraph functions, which are missing at present. Are you able to add those easily? Thanks, Adrian -- Dr Adrian Croucher Senior Research Fellow Department of Engineering Science University of Auckland, New Zealand email: a.croucher(a)auckland.ac.nz tel: +64 (0)9 923 4611

1 0

Getting credit for Contributors graph on github?
by Barry Smith 27 Sep '17

27 Sep '17

Just a reminder for developers who want to get credit for their PETSc commits. > Begin forwarded message: > > From: Jed Brown <jed(a)jedbrown.org> > Subject: Re: [petsc-maint] Contributors graph on github? > Date: September 27, 2017 at 11:01:48 AM CDT > To: Richard Tran Mills <rtmills(a)anl.gov>, PETSc-maint <petsc-maint(a)mcs.anl.gov> > > Add the addresses to your account or add yourself to .mailmap. > > Richard Tran Mills <rtmills(a)anl.gov> writes: > >> I hadn't seen this "contributors" graph before and found it interesting: >> >> https://github.com/petsc/petsc/graphs/contributors >> >> What would I need to do to get the various commits I've made over there >> years to be associated with my 'rtmills' github account? >> >> --Richard

1 0

Re: [petsc-dev] *unwind* next branch
by Balay, Satish 27 Sep '17

27 Sep '17

Next is recreated (again) so these branches are no longer there. Satish On Wed, 2017-09-27 at 16:17 +0300, Lisandro Dalcin wrote: > Also revert the merge of dalcinl/fix-dmplex-draw, I have to decline > the PR and make a new one targeting maint. > > On 27 September 2017 at 16:16, Lisandro Dalcin <dalcinl(a)gmail.com> > wrote: > > Satish, please revert the merge to next of my branch > > dalcinl/add-tsrestart. This branch has fixes that should go to new > > maint, but now I need to rework the commits, as they introduce new > > APIs. > >

1 0

Re: [petsc-dev] *unwind* next branch
by Balay, Satish 27 Sep '17

27 Sep '17

All (next users), We had to unwind next again - so you would also have to do the delete and recreate next again! Sorry about that. If you try to merge across the old and new next versions - you should get a merge conflict on include/petscversion.h. [i.e this merge conflict indicates you have to recreate next - and *not* resolve/push] $ git fetch $ git merge origin/next Auto-merging include/petscversion.h CONFLICT (content): Merge conflict in include/petscversion.h Automatic merge failed; fix conflicts and then commit the result. Satish On Wed, 2017-09-27 at 02:01 +0000, Balay, Satish wrote: > So *all git repo users* (if you have/use 'next' branch in your clone) > - please do the following (in all your git clones): > > git checkout master > git fetch > git branch -D next > git checkout next >

1 0

Re: [petsc-dev] MatAssembly removes all preallocation info
by Kong, Fande 27 Sep '17

27 Sep '17

Hi Barry, Just added a PR for this. https://bitbucket.org/petsc/petsc/pull-requests/760/matresetpreallocation/d… Fande, On Mon, Sep 25, 2017 at 12:35 PM, Kong, Fande <fande.kong(a)inl.gov> wrote: > > > On Mon, Sep 25, 2017 at 12:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> > On Sep 25, 2017, at 1:17 PM, Kong, Fande <fande.kong(a)inl.gov> wrote: >> > >> > >> > >> > On Mon, Sep 25, 2017 at 11:41 AM, Barry Smith <bsmith(a)mcs.anl.gov> >> wrote: >> > >> > > On Sep 25, 2017, at 11:22 AM, Kong, Fande <fande.kong(a)inl.gov> wrote: >> > > >> > > >> > > >> > > On Mon, Sep 25, 2017 at 10:05 AM, Stefano Zampini < >> stefano.zampini(a)gmail.com> wrote: >> > > If you know the union of the different sparsity patterns, after you >> preallocate you can set all zeros to use all the entries. This way PETSc >> will not complain about new nonzeros in successive assemblies. >> > > >> > > >> > > Thanks, Stefano, >> > > >> > > Yes, we are actually using this way right now. We are explicitly >> setting zeros to the matrix to stop petsc shrinking the memory. >> > >> > This >> > > But we want to know why we free the extra memory? Yes, we shrink >> the memory by moving all data together to have an efficiency computation. >> But it is still possible to not throw away our preallocated memory space >> if we want to use latter. >> >> We don't actually "throw out" the extra memory we just don't use it >> and it becomes unaccessible. >> >> Yes, one could actually keep the preallocation information. This would >> essentially require >> >> 1) an additional array of length number of rows that is allocated and >> filled with the user provide nonzero counts when the user sets the >> preallocation (currently this information is lost when the matrix is >> "shrunk") and >> >> 2) A API say MatResetPreallocation() that used this saved information to >> fill in the ilen and other integer arrays in the matrix as if the user had >> called MatPreallocateXXX() again. >> >> Actually now that I say this I realize it is pretty easy. You could >> make a pull request and introduce this functionality. >> > > Yes, this is what I want. I will be working on this and making a PR. > > Fande, > > >> >> Barry >> >> >> > >> > contradicts this. >> > >> > If at the beginning you put in all the zeros you will ever need then >> PETSc will not "throw away" preallocated space. Most likely you are not >> actually setting the initial nonzero structure using the union of all >> future nonzero structures. >> > >> > We are explicitly setting zeros, and the code is working. But setting >> zeros is not a free function. In this email, I am trying to understand why >> we have to do in this way. If we could not throw away the extra memory >> when we do not explicitly set zeros, it would be nice. >> > >> > >> > If the nonzero structure changes dramatically over time, for >> instance if the mesh is moving around removing lots of old connections and >> introducing lots of new ones then you do not want to just preallocate. >> Instead you need to preallocate for each totally new nonzero structure. >> > >> > There is no way to "preserve" the initial preallocation information >> through later time except by explicitly putting zero entries into the >> matrix. >> > >> > OK. Got it. >> > >> > Thanks, >> > >> > Fande, >> > >> > >> > Barry >> > >> > > >> > > >> > > Fande, >> > > >> > > >> > > Il 25 Set 2017 7:01 PM, "Kong, Fande" <fande.kong(a)inl.gov> ha >> scritto: >> > > Hi Matt, >> > > >> > > Thanks for your reply. >> > > >> > > The sparsity pattern is slightly different from one Newton iteration >> to another. We preallocate enough memory at the beginning, and want to use >> that memory for the following iterations. >> > > >> > > Does PETSc accutally free the preallocated (extra) memory? I so >> cannot use it during the second iteration. >> > > >> > > >> > > >> > > Fande, >> > > >> > > On Mon, Sep 25, 2017 at 9:43 AM, Matthew Knepley <knepley(a)gmail.com> >> wrote: >> > > On Mon, Sep 25, 2017 at 11:39 AM, Kong, Fande <fande.kong(a)inl.gov> >> wrote: >> > > Hi All, >> > > >> > > A matrix is created with the right preallocation, and then >> MatAssembly is called. The preallocation info will be removed. We insert >> any values then, and will encounter an malloc error. >> > > >> > > My question is that we was intending to design like this way? >> Attached simple example demonstrates what I am talking about. >> > > >> > > Yes, this is the intent. Why are you assembling? Could you use >> MAT_ASSEMBLY_FLUSH? >> > > >> > > Matt >> > > >> > > >> > > Fande, >> > > >> > > >> > > >> > > -- >> > > 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 >> > > >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cse >> .buffalo.edu_-7Eknepley_&d=DwIFAg&c=54IZrppPQZKX9mLzcGdPfFD1 >> hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4t >> s7XKfj2opmiCY&m=U9L00IdHyC-4OTIJws8B4BeQTX1DBhNdzqB-NGUI3Es& >> s=ZakQrYVOAFg6ShY9i0MSYHkgGWvqwRfACulWOiIX07o&e= >> > > >> > > >> >> >

1 0

Re: [petsc-dev] PetscSF in Fortran
by Matthew Knepley 27 Sep '17

27 Sep '17

On Tue, Sep 26, 2017 at 11:49 PM, Adrian Croucher <a.croucher(a)auckland.ac.nz > wrote: > hi Matt, > > On 25/09/17 23:12, Matthew Knepley wrote: > > > If you truly need the exact same SF for your grid, you should be able to > use DMGet/SetPointSF() since it will just reference count it for you. Then > the default SF is created automatically from the point SF. Does this work? > > > It doesn't seem to work, unfortunately. If I run in parallel I get an > error on each processor like this: > > [0]PETSC ERROR: Nonconforming object sizes > [0]PETSC ERROR: SF roots 447 < pEnd 543 > [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html > for trouble shooting. > [0]PETSC ERROR: Petsc Development GIT revision: v3.7.6-5886-gc423942 GIT > Date: 2017-06-28 18:43:52 -0500 > [0]PETSC ERROR: test_all on a linux-gnu-c-opt named en-354401 by acro018 > Wed Sep 27 16:31:28 2017 > [0]PETSC ERROR: Configure options --with-x --download-hdf5 > --download-netcdf --download-exodusii --downloa > d-triangle --download-ptscotch --download-chaco > --download-hypre > [0]PETSC ERROR: #1 PetscSectionCreateGlobalSection() line 929 in > /home/acro018/software/PETSc/code/src/vec > /is/utils/vsectionis.c > > [0]PETSC ERROR: #2 DMGetDefaultGlobalSection() line 3458 in > /home/acro018/software/PETSc/code/src/dm/inter > face/dm.c > > [0]PETSC ERROR: #3 User provided function() line 0 in User file > > The reason I thought just copying the SF across might work is that the > partition ghost cells in my modified DMPlex should be in the same locations > (DMPlex points) as they were in the original DMPlex. My understanding was > that the SF just stores the root corresponding to a leaf (ghost point?) on > the current processor, so those ought to be unchanged. But maybe there are > subtleties about the SF stuff that I don't yet understand. > > What I am doing is adding new points for the dual-porosity mesh into my > modified DMPlex. I have added the new cells after the partition ghost > cells, and before the boundary ghost cells (and similarly for other depth > strata). So I have shifted the locations of the boundary ghost cells, but > not the partition ghost cells. I give the new points the appropriate depth > label values so that the depth stratum bounds are updated correctly. I also > shift the end_interior value for each depth stratum, so that code relying > on DMPlexGetHybridBounds() should still work. > > Would you expect copying the SF to work in this case? > Okay, I think this should be easy to solve. First a little bit about SF. There are two parts to the specification. You have the communication part, which maps a certain location p on this process to another location q on another process. This might not change for you. The second part just tells it how big the data array is (numRoots), which is the thing that the locations in the communication part index into. So my question is, where did you put the numbers for the points you added? Are they after all points, or only after the old cells? I think you can easily create the new SF using the info from SFGetGraph(). Matt > > - Adrian > > -- > Dr Adrian Croucher > Senior Research Fellow > Department of Engineering Science > University of Auckland, New Zealand > email: a.croucher(a)auckland.ac.nz > tel: +64 (0)9 923 4611 <+64%209-923%204611> > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0