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

PetscViewerASCIISynchronizedAllow
by Jed Brown 21 Apr '11

21 Apr '11

Currently this needs to be called, but is not available from Fortran and is marked as developer level. Is there a plan to make it somehow automatic (I thought the function was introduced because it was expensive to do it automatically), or did someone forget to make Fortran bindings and set the Level?

1 0

pushing MASSIVE change to PETSc-dev
by Barry Smith 21 Apr '11

21 Apr '11

I have just pushed a massive change to petsc-dev. All destructor functions of the form XXXDestroy(XXX) are now XXXDestroy(XXX*), so for example KSPDestroy(ksp) should be replaced with KSPDestroy(&ksp). This has no effect on Fortran codes that remain the same. I have tested with C and C++ but likely missed a few instances. To avoid dealing with this change immediately you can do hg pull hg update d3e10315d68b to work with the last version before this change, then when you are ready to update do another hg pull hg update If you are actually changing PETSc code then you cannot delay doing the full update. Please report all problems to petsc-dev(a)mcs.anl.gov or petsc-maint(a)mcs.anl.gov Barry To update your code quickly in emacs you can make a tags file for your source by, for example, etags *.c then in emacs do meta visit-tags-table CR CR which loads the tags file and then meta tags-query CR Destroy(\([a-zA-Z]\) CR Destroy(&\1 where CR means hit carriage return

1 0

Re: [petsc-dev] [petsc-users] How to create and assemble matrices for DA vectors??
by Barry Smith 21 Apr '11

21 Apr '11

On Apr 21, 2011, at 6:07 AM, Jed Brown wrote: > 2011/4/21 Алексей Рязанов <ram(a)ibrae.ac.ru> > I think I understand this now. But it seems strange that the DAGetMatrix procedure creates the matrix and I need call the MatDestroy after the "get" proceure to properly free the memory. > > Indeed, it should be named DACreateMatrix(). Actually, eventually DAGetMatrix() will take a matrix as input so would be called something like DMMatFill() so please don't change any names yet. I want to get away from having objects create other objects, instead they would take the object already created and modify it. This gives the user finer control over the state of the object created, it's subclass etc. For example, we don't want to have to hardwire inside of DMGetMatrix() lists of every matrix class that will ever be added to PETSc. > > @petsc-dev > This comes up way too often and we've all agreed that it should change. Let's do it before 3.2 is released. In what other cases does the following model not hold? > > 1. XCreateY(X,...,&Y); user has ownership to the new Y and should destroy with YDestroy(Y) > > 2. XGetY(X,...,&Y); user has a "cheap" reference to an object owned by X, reference count is not incremented, no need to do anything when the user is done with Y > > 3. XGetY(X,...,&Y); the new Y may require setup or other resources, user calls XRestoreY(X,...,&Y) when they are finished with Y This mode is fine. Barry > > > I wish there was a nice naming convention to distinguish 2 from 3, but I think we should shoot for no exceptions to following 1 versus (2,3). > > What about MatGetSubMatrix()? For internal use, e.g. in PCFieldSplit, I think that model 3 would be better because it exposes more optimizations when assembly is lagged.

1 0

Re: [petsc-dev] [petsc-users] How to create and assemble matrices for DA vectors??
by Jed Brown 21 Apr '11

21 Apr '11

2011/4/21 Алексей Рязанов <ram(a)ibrae.ac.ru> > I think I understand this now. But it seems strange that the DA*Get*Matrix > procedure *creates* the matrix and I need call the MatDestroy after the > "get" proceure to properly free the memory. > Indeed, it should be named DACreateMatrix(). @petsc-dev This comes up way too often and we've all agreed that it should change. Let's do it before 3.2 is released. In what other cases does the following model not hold? 1. XCreateY(X,...,&Y); user has ownership to the new Y and should destroy with YDestroy(Y) 2. XGetY(X,...,&Y); user has a "cheap" reference to an object owned by X, reference count is not incremented, no need to do anything when the user is done with Y 3. XGetY(X,...,&Y); the new Y may require setup or other resources, user calls XRestoreY(X,...,&Y) when they are finished with Y I wish there was a nice naming convention to distinguish 2 from 3, but I think we should shoot for no exceptions to following 1 versus (2,3). What about MatGetSubMatrix()? For internal use, e.g. in PCFieldSplit, I think that model 3 would be better because it exposes more optimizations when assembly is lagged.

1 0

petsc-dev repo
by Satish Balay 21 Apr '11

21 Apr '11

If you've pulled petsc-dev in the past couple of hours - you might have some hg errors like: >>>>>> not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge) <<<<<< If so - suggest doing: hg rollback [or alternatively] mv petsc-dev petsc-dev.old hg clone petsc-dev.old petsc-dev -r d3e10315d68b cp petsc-dev.old/.hg/hgrc petsc-dev/.hg/hgrc I've manually removed this bad state from petsc.cs.iit.edu/petsc/petsc-dev - so if you pull now - its ok [i.e you won't see the 2 heads with 'hg heads'] Satish

1 0

Re: [petsc-dev] BuildSystem help
by Barry Smith 20 Apr '11

20 Apr '11

On Apr 20, 2011, at 1:43 PM, Matthew Knepley wrote: > On Wed, Apr 20, 2011 at 1:24 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > I wanted to add to valgrind.py a test that made sure valgrind.h was compilable. So I added a simple test > > self.checkCompile('#include <valgrind/valgrind.h>','RUNNING_ON_VALGRIND;\n') > > the problem is I do not know where you stash the directory where the include file is put therefor the test fails because it does not know where to look for valgrind/valgrind.h > > > Please pull and fix this now, since configure in petsc-dev is currently broken. > > Pushed. Is this what you want? Yes, I think it worked correctly. Note this would prevent the bad problem reported by a previous petsc-maint today about valgrind. BTW: When a test fails BuildSystem prints the test but when it succeeds it doesn't print the test it did. How about having self.checkCompile('#include <valgrind/valgrind.h>','RUNNING_ON_VALGRIND;\n') for example print the code it is testing when it succeeds also. Makes understanding what configure does easier Barry > > Matt > > Thanks > > Barry > > > > > -- > 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] BuildSystem help
by Matthew Knepley 20 Apr '11

20 Apr '11

On Wed, Apr 20, 2011 at 1:24 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > I wanted to add to valgrind.py a test that made sure valgrind.h was > compilable. So I added a simple test > > self.checkCompile('#include > <valgrind/valgrind.h>','RUNNING_ON_VALGRIND;\n') > > the problem is I do not know where you stash the directory where the > include file is put therefor the test fails because it does not know where > to look for valgrind/valgrind.h > > > Please pull and fix this now, since configure in petsc-dev is currently > broken. > Pushed. Is this what you want? Matt > Thanks > > Barry > > -- 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

BuildSystem help
by Barry Smith 20 Apr '11

20 Apr '11

Matt, I wanted to add to valgrind.py a test that made sure valgrind.h was compilable. So I added a simple test self.checkCompile('#include <valgrind/valgrind.h>','RUNNING_ON_VALGRIND;\n') the problem is I do not know where you stash the directory where the include file is put therefor the test fails because it does not know where to look for valgrind/valgrind.h Please pull and fix this now, since configure in petsc-dev is currently broken. Thanks Barry

1 0

Re: [petsc-dev] [petsc-maint #70913] petsc-dev compilation error
by Barry Smith 20 Apr '11

20 Apr '11

Great, thanks. On Apr 20, 2011, at 10:27 AM, Satish Balay wrote: > On Wed, 20 Apr 2011, Matthew Knepley wrote: > >> On Wed, Apr 20, 2011 at 10:21 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >>> >>> On Apr 20, 2011, at 10:18 AM, Matthew Knepley wrote: >>> >>>> On Wed, Apr 20, 2011 at 10:12 AM, Barry Smith <bsmith(a)mcs.anl.gov> >>> wrote: >>>> >>>> I think Jed pointed out a problem with the current approach. We don't >>> really want to have MANSECs for each DMXXXX but we do want different include >>> files. I forgot what Jed and I concluded but it could be that some makefiles >>> need SUBMANSEC that appends onto the MANSEC. By the way it is DMDA not dadm, >>> the base class always comes first. >>>> >>>> Already pushed a bunch of MANSEC changes. >>> >>> You may need to unpush them. >>> >> >> I am not doing anything until this crap is explained. I would not have had >> to push erroneous stuff if >> the process and inputs were clear. MANSEC directly mapped to sections of manual pages (for generating docs) and also to include files (for generating Fortran stuff) . So it served two slightly different purposes. Jed decided that things like da should have their own include file (not just be in petscdm.h just like petscpcmg.h. This broke the direct mapping for man page sections and include files. By introducing SUBMANSEC we can map to the include files again. Barry > > > I've added in SUBMANSEC propcessing in generatefortranstubs.py - and > will change Matt's MANSEC changes to SUBMANSEC [in makefiles] > > Satish

1 0

Re: [petsc-dev] [petsc-maint #70913] petsc-dev compilation error
by Barry Smith 20 Apr '11

20 Apr '11

On Apr 20, 2011, at 10:18 AM, Matthew Knepley wrote: > On Wed, Apr 20, 2011 at 10:12 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I think Jed pointed out a problem with the current approach. We don't really want to have MANSECs for each DMXXXX but we do want different include files. I forgot what Jed and I concluded but it could be that some makefiles need SUBMANSEC that appends onto the MANSEC. By the way it is DMDA not dadm, the base class always comes first. > > Already pushed a bunch of MANSEC changes. You may need to unpush them. Barry > > Matt > > Barry > > > On Apr 20, 2011, at 9:39 AM, Matthew Knepley wrote: > > > On Wed, Apr 20, 2011 at 9:10 AM, Satish Balay <petsc-maint(a)mcs.anl.gov>wrote: > > > >> On Wed, 20 Apr 2011, Matthew Knepley wrote: > >> > >>> On Wed, Apr 20, 2011 at 8:16 AM, Satish Balay <petsc-maint(a)mcs.anl.gov > >>> wrote: > >>> > >>>> On Wed, 20 Apr 2011, Matthew Knepley wrote: > >>>> > >>>>> On Wed, Apr 20, 2011 at 5:05 AM, Sylvain Barbot < > >>>> sylbar.vainbot(a)gmail.com>wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I run into errors trying to compile petsc-dev. > >>>>>> Should i download another version of it, or i'm doing something > >> wrong > >>>>>> in the config? > >>>>>> > >>>>> > >>>>> Satish, this is a --with-fortran-interfaces problem. What needs to be > >>>>> included in the new DM > >>>>> headers in order to generate these? > >>>> > >>>> The sources should have a makefile with the correct 'MANSEC' value. > >>>> > >>> > >>> 1) What generates the interfaces? > >> > >> bfort via bin/maint/generatefortranstubs.py > >>> > >>> 2) I do not know what correct might be > >>> > >> > >> If some of the sources should be tagged as 'DADM' instedad of 'DM' - > >> then MANSEC=DADM should be listed in the corresponding makefiles for > >> the sources. > >> > >> Or else we'll have to remove all dadm.h related includes [and merge > >> with dm.h] > >> > > > > Okay, I will try to fix it. Can you check the docs to make sure my fixes > > do the right thing for documentation, etc? > > > > Matt > > > > > >> Satish > >> > >>> Matt > >>> > >>> > >>>> Satish > >>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Matt > >>>>> > >>>>> > >>>>>> Thanks for your help, > >>>>>> Sylvain Barbot > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > -- > > 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 > > > > On Wed, Apr 20, 2011 at 9:10 AM, Satish Balay <petsc-maint(a)mcs.anl.gov> wrote: > > On Wed, 20 Apr 2011, Matthew Knepley wrote: > > > > > On Wed, Apr 20, 2011 at 8:16 AM, Satish Balay <petsc-maint(a)mcs.anl.gov>wrote: > > > > > > > On Wed, 20 Apr 2011, Matthew Knepley wrote: > > > > > > > > > On Wed, Apr 20, 2011 at 5:05 AM, Sylvain Barbot < > > > > sylbar.vainbot(a)gmail.com>wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I run into errors trying to compile petsc-dev. > > > > > > Should i download another version of it, or i'm doing something wrong > > > > > > in the config? > > > > > > > > > > > > > > > > Satish, this is a --with-fortran-interfaces problem. What needs to be > > > > > included in the new DM > > > > > headers in order to generate these? > > > > > > > > The sources should have a makefile with the correct 'MANSEC' value. > > > > > > > > > > 1) What generates the interfaces? > > > > bfort via bin/maint/generatefortranstubs.py > > > > > > 2) I do not know what correct might be > > > > > > > If some of the sources should be tagged as 'DADM' instedad of 'DM' - > > then MANSEC=DADM should be listed in the corresponding makefiles for > > the sources. > > > > Or else we'll have to remove all dadm.h related includes [and merge > > with dm.h] > > > > Okay, I will try to fix it. Can you check the docs to make sure my fixes > > do the right thing for documentation, etc? > > > > Matt > > > > Satish > > > > > Matt > > > > > > > > > > Satish > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Matt > > > > > > > > > > > > > > > > Thanks for your help, > > > > > > Sylvain Barbot > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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