March 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Satish Balay 19 Mar '12

19 Mar '12

On Mon, 19 Mar 2012, Matthew Knepley wrote: > On Mon, Mar 19, 2012 at 10:03 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > 2012/3/19 Satish Balay <balay(a)mcs.anl.gov> > > > >> The other issue here is: multiple library conflict. If there is a user > >> using tetgen directly [and has a separate install of it] - and also > >> uses petsc from the same code , then there could be duplicate symbol > >> issue. [Now the solution is - don't link with a separate tegen - just > >> link with petsc - but thats generally not good.] > >> > > > > Matt has significantly modified tetgen (removing its superfluous use of > > C++) so all these symbols are different. > > > > AND you could have tested your assumption of a problem by trying it with > --download-tetgen, which >From the emails it wasn't obvious that you are planning on a new name 'ctetgen' - all references were to tetgen. > works because this is how I tested it. The --download-ctetgen option will > work shortly. > > What is this with criticizing what I do before even finding out what I > actually did? sorry - I misunderstood the situation based on this email thread.. The reason I resopinded to the license issue is - we do get emails from folks who are concerend and want clarificaton regarind petsc usage and license. satish

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Matthew Knepley 19 Mar '12

19 Mar '12

On Mon, Mar 19, 2012 at 10:03 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > 2012/3/19 Satish Balay <balay(a)mcs.anl.gov> > >> The other issue here is: multiple library conflict. If there is a user >> using tetgen directly [and has a separate install of it] - and also >> uses petsc from the same code , then there could be duplicate symbol >> issue. [Now the solution is - don't link with a separate tegen - just >> link with petsc - but thats generally not good.] >> > > Matt has significantly modified tetgen (removing its superfluous use of > C++) so all these symbols are different. > AND you could have tested your assumption of a problem by trying it with --download-tetgen, which works because this is how I tested it. The --download-ctetgen option will work shortly. What is this with criticizing what I do before even finding out what I actually did? Matt -- 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] Reminder: *every* symbol with extern linkage *must* be namespaced
by Jed Brown 19 Mar '12

19 Mar '12

2012/3/19 Satish Balay <balay(a)mcs.anl.gov> > The other issue here is: multiple library conflict. If there is a user > using tetgen directly [and has a separate install of it] - and also > uses petsc from the same code , then there could be duplicate symbol > issue. [Now the solution is - don't link with a separate tegen - just > link with petsc - but thats generally not good.] > Matt has significantly modified tetgen (removing its superfluous use of C++) so all these symbols are different.

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Satish Balay 19 Mar '12

19 Mar '12

On Mon, 19 Mar 2012, Satish Balay wrote: > On Sat, 17 Mar 2012, Matthew Knepley wrote: > > > On Sat, Mar 17, 2012 at 4:08 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > > On Sat, Mar 17, 2012 at 16:04, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > > >> On Sat, Mar 17, 2012 at 3:49 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > >> > > >>> > > >>> It should be done as a --download-tetgen > > >>> > > >>> I don't want that --with-gnu-copyright approach reintroduced. > > >> > > >> > > >> 1) I already fixed these symbols hours ago. Pull your fucking repository. > > >> > > >> 2) Turn it on with a download option. I don't give a shit. > > >> > > > > > > This has nothing to do with namespaces, it has to do with software > > > licenses. You just included a bunch of source that has a license which is > > > far more restrictive than the PETSc license. You can't do that (while > > > keeping the PETSc license) without making its use optional. Barry wants > > > that done via an external package instead of an option within the PETSc > > > source tree. > > > > > > > It does not fucking matter whether its there to begin with or you download > > it into the tree with HTTP, and since I > > am maintaining it, I want it there to begin with. > > I think it matters. When the user uses --download-package - he is > explicitly requesting the package - and can aussme the licence is > different. > > On the other hand - if you've are in a position to change its license > [to the part thats in petsc] to be same as petsc license - then its > fine. The other issue here is: multiple library conflict. If there is a user using tetgen directly [and has a separate install of it] - and also uses petsc from the same code , then there could be duplicate symbol issue. [Now the solution is - don't link with a separate tegen - just link with petsc - but thats generally not good.] sAtish > > BTW: > libfast in: /home/balay/spetsc/src/dm/impls/complex > complex.c: In function οΏ½DMComplexGenerate_CTetgenοΏ½: > complex.c:4128:65: warning: variable οΏ½faceοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: In function οΏ½TetGenMeshBTreeSortοΏ½: > ctetgen.c:10050:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > ctetgen.c:10070:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > ctetgen.c: In function οΏ½TetGenMeshFindDirection2οΏ½: > ctetgen.c:13153:49: warning: variable οΏ½copοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: In function οΏ½TetGenMeshConstrainedFacetsοΏ½: > ctetgen.c:15042:22: warning: variable οΏ½delaunayflagοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: In function οΏ½TetGenMeshConstrainedFacets2οΏ½: > ctetgen.c:15340:22: warning: variable οΏ½delaunayflagοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: In function οΏ½TetGenMeshRepairEncSubsοΏ½: > ctetgen.c:18617:8: warning: variable οΏ½oldptnumοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: In function οΏ½TetGenMeshOptimizeοΏ½: > ctetgen.c:19734:18: warning: variable οΏ½maxdihedοΏ½ set but not used [-Wunused-but-set-variable] > ctetgen.c: At top level: > ctetgen.c:2026:23: warning: οΏ½ListHasItemοΏ½ defined but not used [-Wunused-function] > libfast in: /home/balay/spetsc/src/dm/impls/complex/ftn-auto > libfast in: /home/balay/spetsc/src/dm/impls/shell > > > Satish

1 0

Re: [petsc-dev] Reminder: *every* symbol with extern linkage *must* be namespaced
by Matthew Knepley 19 Mar '12

19 Mar '12

On Mon, Mar 19, 2012 at 9:56 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Sat, 17 Mar 2012, Matthew Knepley wrote: > > > On Sat, Mar 17, 2012 at 4:08 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > > > On Sat, Mar 17, 2012 at 16:04, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > > > >> On Sat, Mar 17, 2012 at 3:49 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > >> > > >>> > > >>> It should be done as a --download-tetgen > > >>> > > >>> I don't want that --with-gnu-copyright approach reintroduced. > > >> > > >> > > >> 1) I already fixed these symbols hours ago. Pull your fucking > repository. > > >> > > >> 2) Turn it on with a download option. I don't give a shit. > > >> > > > > > > This has nothing to do with namespaces, it has to do with software > > > licenses. You just included a bunch of source that has a license which > is > > > far more restrictive than the PETSc license. You can't do that (while > > > keeping the PETSc license) without making its use optional. Barry wants > > > that done via an external package instead of an option within the PETSc > > > source tree. > > > > > > > It does not fucking matter whether its there to begin with or you > download > > it into the tree with HTTP, and since I > > am maintaining it, I want it there to begin with. > > I think it matters. When the user uses --download-package - he is > explicitly requesting the package - and can aussme the licence is > different. > I will only turn it on if they give the download argument. > On the other hand - if you've are in a position to change its license > [to the part thats in petsc] to be same as petsc license - then its > fine. > > BTW: > libfast in: /home/balay/spetsc/src/dm/impls/complex > complex.c: In function ‘DMComplexGenerate_CTetgen’: > complex.c:4128:65: warning: variable ‘face’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: In function ‘TetGenMeshBTreeSort’: > ctetgen.c:10050:20: warning: cast to pointer from integer of different > size [-Wint-to-pointer-cast] > ctetgen.c:10070:21: warning: cast to pointer from integer of different > size [-Wint-to-pointer-cast] > I can't change this, since this is what the package does. I guess they get away with it now. Matt ctetgen.c: In function ‘TetGenMeshFindDirection2’: > ctetgen.c:13153:49: warning: variable ‘cop’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: In function ‘TetGenMeshConstrainedFacets’: > ctetgen.c:15042:22: warning: variable ‘delaunayflag’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: In function ‘TetGenMeshConstrainedFacets2’: > ctetgen.c:15340:22: warning: variable ‘delaunayflag’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: In function ‘TetGenMeshRepairEncSubs’: > ctetgen.c:18617:8: warning: variable ‘oldptnum’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: In function ‘TetGenMeshOptimize’: > ctetgen.c:19734:18: warning: variable ‘maxdihed’ set but not used > [-Wunused-but-set-variable] > ctetgen.c: At top level: > ctetgen.c:2026:23: warning: ‘ListHasItem’ defined but not used > [-Wunused-function] libfast in: /home/balay/spetsc/src/dm/impls/complex/ftn-auto > libfast in: /home/balay/spetsc/src/dm/impls/shell > > > Satish -- 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] Reminder: *every* symbol with extern linkage *must* be namespaced
by Satish Balay 19 Mar '12

19 Mar '12

On Sat, 17 Mar 2012, Matthew Knepley wrote: > On Sat, Mar 17, 2012 at 4:08 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Sat, Mar 17, 2012 at 16:04, Matthew Knepley <knepley(a)gmail.com> wrote: > > > >> On Sat, Mar 17, 2012 at 3:49 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> > >>> > >>> It should be done as a --download-tetgen > >>> > >>> I don't want that --with-gnu-copyright approach reintroduced. > >> > >> > >> 1) I already fixed these symbols hours ago. Pull your fucking repository. > >> > >> 2) Turn it on with a download option. I don't give a shit. > >> > > > > This has nothing to do with namespaces, it has to do with software > > licenses. You just included a bunch of source that has a license which is > > far more restrictive than the PETSc license. You can't do that (while > > keeping the PETSc license) without making its use optional. Barry wants > > that done via an external package instead of an option within the PETSc > > source tree. > > > > It does not fucking matter whether its there to begin with or you download > it into the tree with HTTP, and since I > am maintaining it, I want it there to begin with. I think it matters. When the user uses --download-package - he is explicitly requesting the package - and can aussme the licence is different. On the other hand - if you've are in a position to change its license [to the part thats in petsc] to be same as petsc license - then its fine. BTW: libfast in: /home/balay/spetsc/src/dm/impls/complex complex.c: In function οΏ½DMComplexGenerate_CTetgenοΏ½: complex.c:4128:65: warning: variable οΏ½faceοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: In function οΏ½TetGenMeshBTreeSortοΏ½: ctetgen.c:10050:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ctetgen.c:10070:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ctetgen.c: In function οΏ½TetGenMeshFindDirection2οΏ½: ctetgen.c:13153:49: warning: variable οΏ½copοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: In function οΏ½TetGenMeshConstrainedFacetsοΏ½: ctetgen.c:15042:22: warning: variable οΏ½delaunayflagοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: In function οΏ½TetGenMeshConstrainedFacets2οΏ½: ctetgen.c:15340:22: warning: variable οΏ½delaunayflagοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: In function οΏ½TetGenMeshRepairEncSubsοΏ½: ctetgen.c:18617:8: warning: variable οΏ½oldptnumοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: In function οΏ½TetGenMeshOptimizeοΏ½: ctetgen.c:19734:18: warning: variable οΏ½maxdihedοΏ½ set but not used [-Wunused-but-set-variable] ctetgen.c: At top level: ctetgen.c:2026:23: warning: οΏ½ListHasItemοΏ½ defined but not used [-Wunused-function] libfast in: /home/balay/spetsc/src/dm/impls/complex/ftn-auto libfast in: /home/balay/spetsc/src/dm/impls/shell Satish

1 0

Re: [petsc-dev] I do not think this is the right solution
by Matthew Knepley 18 Mar '12

18 Mar '12

On Sun, Mar 18, 2012 at 8:57 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Sun, Mar 18, 2012 at 20:50, Matthew Knepley <knepley(a)gmail.com> wrote: > >> Oh, vastly complicate my code, so that I can do something equivalent to >> what I get in a few lines. Please >> reconsider further coding suggestions. >> > > I gave this suggestion before looking at how you were using it, either of > my other suggestions would trivial within your current code. > > Note that your current solution relies on the user (or another program > running a diff) to compare for a specific instance where as this allows the > running code to check in a self-contained way. I'm not saying one is better > than the other here, just that there are merits to both. > If we were not relying on diffs, we could do just what you said with MatRedundant and matrix norms. I think that is eventually where we want to go, but it requires more test infrastructure. I would advocate moving to Python for that. Matt -- 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] I do not think this is the right solution
by Jed Brown 18 Mar '12

18 Mar '12

On Sun, Mar 18, 2012 at 20:50, Matthew Knepley <knepley(a)gmail.com> wrote: > Oh, vastly complicate my code, so that I can do something equivalent to > what I get in a few lines. Please > reconsider further coding suggestions. > I gave this suggestion before looking at how you were using it, either of my other suggestions would trivial within your current code. Note that your current solution relies on the user (or another program running a diff) to compare for a specific instance where as this allows the running code to check in a self-contained way. I'm not saying one is better than the other here, just that there are merits to both.

1 0

Re: [petsc-dev] I do not think this is the right solution
by Matthew Knepley 18 Mar '12

18 Mar '12

On Sun, Mar 18, 2012 at 7:05 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Sun, Mar 18, 2012 at 18:54, Matthew Knepley <knepley(a)gmail.com> wrote: > >> That has nothing to do with anything we are talking about. >> > > Bull, run your code in parallel, but have it create the matrix in two > ways, one on COMM_SELF and one running on COMM_WORLD. Take the COMM_WORLD > one and MatGetRedundantMatrix(Aworld,...,&Ared) to get the redundant > matrix, then compute the norm of Ared - Aself. > Oh, vastly complicate my code, so that I can do something equivalent to what I get in a few lines. Please reconsider further coding suggestions. Matt > From looking at your code, this is more intrusive than below. > > >> >> >>> And if you really want to stay parallel and print all the non-small >>> values, MatDuplicate and fill up the new matrix with the thresholded values. >>> >> >> Neither does this. >> > > Imagine a world in which > > ierr = MatChop(JacP, 1.0e-10);CHKERRQ(ierr); > ierr = MatView(JacP, PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); > > was instead written > > Mat Chopped; > ierr = MatChop(JacP, 1.0e-10, &Chopped);CHKERRQ(ierr); > ierr = MatView(Chopped, PETSC_VIEWER_STDOUT_WORLD);CHKERRQ(ierr); > ierr = MatDestroy(&Chopped);CHKERRQ(ierr); > > You could MatHeaderReplace(JacP,Chopped); if you were feeling ornery > (considering that the local callback you are using didn't pass a Mat* or > forward the SNES down that far (i.e. an API bug because we assert that you > can change the matrix in a Jacobian evaluation routine)). > > >> >> >>> Note, there was a request a while back to be able to make an ASCII >>> viewer use a user-defined floating-point format string. >>> >> >> That would not help. For a small number, you do not want ANY significant >> digits. >> > > %f > -- 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] I do not think this is the right solution
by Jed Brown 18 Mar '12

18 Mar '12

On Sun, Mar 18, 2012 at 18:55, Matthew Knepley <knepley(a)gmail.com> wrote: > No off-diagonal. So I think the MatGetArray() should be MatDenseGetArray() because it's not directly useful otherwise. For in-place modification (if that is actually useful), I'd do it with a callback. Note that for your specific purpose, you can do in-place modification with MatMPIAIJGetAIJ() and MatGetArray() on each off-diagonal block.

1 0