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

Re: [petsc-dev] getting rid of the sys/shell directory?
by Dmitry Karpeev 14 Feb '13

14 Feb '13

Done: https://bitbucket.org/petsc/petsc-dev/commits/aee59bf3b744565306435f5b76084… Dmitry. On Tue, Feb 12, 2013 at 10:06 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov>wrote: > I'll remove it. > Dmitry > On Feb 12, 2013 9:50 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > >> >> How hard will it be to get rid of the sys/shell directory? All that >> code that needs to be constantly updated with Jed's crazy schemes is >> driving me nuts. >> >> Barry >> >> -- Dmitry Karpeev, Ph.D. Assistant Computational Mathematician Mathematics and Computer Science Argonne National Laboratory Argonne, Illinois, USA and Fellow Computation Institute University of Chicago 5735 S. Ellis Avenue Chicago, IL 60637 ----------------------- Phone: 630-252-1229 Fax: 630-252-5986

1 0

Re: [petsc-dev] watching petsc-dev in gource
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 12:13 AM, Sean Farley <sean(a)mcs.anl.gov> wrote: > It'd be a good chance to get rid of some of the larger binary files and > use better formatting on the bk-changeset-* log messages! > And switch to Git! ;-) You know I _had_ to say it.

1 0

Re: [petsc-dev] watching petsc-dev in gource
by Sean Farley 14 Feb '13

14 Feb '13

Jed Brown writes: > On Wed, Feb 13, 2013 at 8:57 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> How come we can't? Didn't the RCS files get input into BK or did we >> start all over again with BK? Anyway to add the RCS info back in? > > > If you have it archived somewhere, we can import it, but it will change the > SHA1s of everything afterward so everyone would need to reclone. It'd be a good chance to get rid of some of the larger binary files and use better formatting on the bk-changeset-* log messages!

1 0

Re: [petsc-dev] questions on new include organization
by Barry Smith 13 Feb '13

13 Feb '13

On Feb 13, 2013, at 10:39 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Feb 13, 2013 at 10:35 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > After trying to put it into petscpc.h I remembered why it was separate. It uses the KSP object. So either we put part of the interface in petscksp.h or typedef KSP in petscpc.h so I'll leave it as is for now. > > Ah, that's why PCFieldSplitGetSubKSP() is in petscksp.h, along with MatSchurComplement stuff. Yuck. So using two different bad ways of resolving the same problem! Not good. I'm inclined to get rid of petscpcmg.h anyways (and its 3 Fortran versions). Then we are at least solving the same problem with only one bad way. Barry

1 0

Re: [petsc-dev] questions on new include organization
by Jed Brown 13 Feb '13

13 Feb '13

On Wed, Feb 13, 2013 at 10:35 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > After trying to put it into petscpc.h I remembered why it was separate. > It uses the KSP object. So either we put part of the interface in > petscksp.h or typedef KSP in petscpc.h so I'll leave it as is for now. Ah, that's why PCFieldSplitGetSubKSP() is in petscksp.h, along with MatSchurComplement stuff.

1 0

Re: [petsc-dev] questions on new include organization
by Barry Smith 13 Feb '13

13 Feb '13

On Feb 13, 2013, at 10:11 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Feb 13, 2013 at 10:02 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Should we, should we not do the same thing for the other PCs? What about KSPs? Definitely no for KSPs. > > PCFieldSplit would be the most likely candidate, but its interface is not that broad and it's not currently high-risk for growing dependencies, so I don't think there would be much return. I'm not the one that separated out petscpcmg.h and I'm not sure it's providing much value being separate. (It used to be called petscmg.h, I just renamed it to petscpcmg.h.) After trying to put it into petscpc.h I remembered why it was separate. It uses the KSP object. So either we put part of the interface in petscksp.h or typedef KSP in petscpc.h so I'll leave it as is for now. Barry > > > > > > > ** Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right. > > > > I see the appeal of hierarchies, but I find them rigid and inconvenient. I definitely prefer object models (interface and implementation, but no implementation inheritance). The only reason for implementation inheritance is code sharing, but I think that's frequently a false economy and comes back to bite us in brittleness. > > The KSP -> gmres -> l or F; I am talking about is from the user perspective (I agree that any implementation inheritance is secondary and certainly not important to the users). The question is do we give the user a list of 20 KSP or do we give them sets of related ones. I am arguing that presenting them as sets of related ones is better. > > Arguably, GCR is more like FGMRES than FGMRES is like GMRES. LSQR is more like MINRES than MINRES is like GMRES, IDR is more like BCGSL than BCGSL is like BCGS, etc. I think this hierarchical classification does not work. Yahoo tried to do this with the internet and had their lunch eaten by Google. > > We need searching, tagging, and perhaps semantic knowledge of properties, but I prefer a flat namespace to encoding the hierarchy induced by one choice of classification metric.

1 0

Re: [petsc-dev] questions on new include organization
by Jed Brown 13 Feb '13

13 Feb '13

On Wed, Feb 13, 2013 at 10:02 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Should we, should we not do the same thing for the other PCs? What about > KSPs? Definitely no for KSPs. > PCFieldSplit would be the most likely candidate, but its interface is not that broad and it's not currently high-risk for growing dependencies, so I don't think there would be much return. I'm not the one that separated out petscpcmg.h and I'm not sure it's providing much value being separate. (It used to be called petscmg.h, I just renamed it to petscpcmg.h.) > > > > > > ** Note we don't do this for sub sub classes, KSPLGMRES should be > KSPGMRESL etc. pity we should have done it right. > > > > I see the appeal of hierarchies, but I find them rigid and inconvenient. > I definitely prefer object models (interface and implementation, but no > implementation inheritance). The only reason for implementation inheritance > is code sharing, but I think that's frequently a false economy and comes > back to bite us in brittleness. > > The KSP -> gmres -> l or F; I am talking about is from the user > perspective (I agree that any implementation inheritance is secondary and > certainly not important to the users). The question is do we give the user > a list of 20 KSP or do we give them sets of related ones. I am arguing that > presenting them as sets of related ones is better. > Arguably, GCR is more like FGMRES than FGMRES is like GMRES. LSQR is more like MINRES than MINRES is like GMRES, IDR is more like BCGSL than BCGSL is like BCGS, etc. I think this hierarchical classification does not work. Yahoo tried to do this with the internet and had their lunch eaten by Google. We need searching, tagging, and perhaps semantic knowledge of properties, but I prefer a flat namespace to encoding the hierarchy induced by one choice of classification metric.

1 0

Re: [petsc-dev] questions on new include organization
by Barry Smith 13 Feb '13

13 Feb '13

On Feb 13, 2013, at 9:22 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > My justification for splitting out the DM implementation headers was that KSP/SNES/TS depend on the DM interface, but should not (there may be a couple places that cheat) depend on the DMDA/DMPlex/etc interfaces. I would say that any include of petscdmxxx.h outside of dmxxxsnes.c is a bad dependency. The user, on the other hand, always depends on the implementation, so they should include petscdmxxx.h. > > This is also the result of DM doing too many jobs. Not at all. It has two jobs: talking to the mesh data and talking to the solver objects. What makes it seem to have many jobs is that each type of mesh object has its own language. > > > ** Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right. > > I see the appeal of hierarchies, but I find them rigid and inconvenient. I definitely prefer object models (interface and implementation, but no implementation inheritance). The only reason for implementation inheritance is code sharing, but I think that's frequently a false economy and comes back to bite us in brittleness. If we had a lightweight way to selectively forward methods, we could break out the sharable part into an internal object with well-defined methods and avoid the piggy-back overriding of methods (implementation inheritance). > > I agree with this. I have never seen inheritance buy anything in the real world. > > 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] questions on new include organization
by Barry Smith 13 Feb '13

13 Feb '13

On Feb 13, 2013, at 9:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Feb 13, 2013 at 2:14 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > * There are other petscxxx.h include files, but generally the user need only include petscPACKAGENAME.h though Jed seems to have broken this model with some subclasses like petscdmda.h petscpcmg.h etc not being included by petscdm.h and petscpc.h (hmm this is both good and bad) not including a bunch of stuff the user doesn't need or specifically request is good but on the other hand the user has to specifically include it (increased learning curve). So to use PCMG functionality directly one must include petscpcmg.h directly but to use field split they don't need petscpcfieldsplit.h this can lead to user exasperation (and mine)! > > My justification for splitting out the DM implementation headers was that KSP/SNES/TS depend on the DM interface, but should not (there may be a couple places that cheat) depend on the DMDA/DMPlex/etc interfaces. I would say that any include of petscdmxxx.h outside of dmxxxsnes.c is a bad dependency. The user, on the other hand, always depends on the implementation, so they should include petscdmxxx.h. Understood and not completely unreasonable. Should we, should we not do the same thing for the other PCs? What about KSPs? Definitely no for KSPs. > > > ** Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right. > > I see the appeal of hierarchies, but I find them rigid and inconvenient. I definitely prefer object models (interface and implementation, but no implementation inheritance). The only reason for implementation inheritance is code sharing, but I think that's frequently a false economy and comes back to bite us in brittleness. The KSP -> gmres -> l or F; I am talking about is from the user perspective (I agree that any implementation inheritance is secondary and certainly not important to the users). The question is do we give the user a list of 20 KSP or do we give them sets of related ones. I am arguing that presenting them as sets of related ones is better. > If we had a lightweight way to selectively forward methods, we could break out the sharable part into an internal object with well-defined methods and avoid the piggy-back overriding of methods (implementation inheritance).

1 0

Re: [petsc-dev] questions on new include organization
by Matthew Knepley 13 Feb '13

13 Feb '13

On Wed, Feb 13, 2013 at 10:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Feb 13, 2013 at 2:14 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> * There are other petscxxx.h include files, but generally the user need >> only include petscPACKAGENAME.h though Jed seems to have broken this model >> with some subclasses like petscdmda.h petscpcmg.h etc not being included by >> petscdm.h and petscpc.h (hmm this is both good and bad) not including a >> bunch of stuff the user doesn't need or specifically request is good but on >> the other hand the user has to specifically include it (increased learning >> curve). So to use PCMG functionality directly one must include petscpcmg.h >> directly but to use field split they don't need petscpcfieldsplit.h this >> can lead to user exasperation (and mine)! >> > > My justification for splitting out the DM implementation headers was that > KSP/SNES/TS depend on the DM interface, but should not (there may be a > couple places that cheat) depend on the DMDA/DMPlex/etc interfaces. I would > say that any include of petscdmxxx.h outside of dmxxxsnes.c is a bad > dependency. The user, on the other hand, always depends on the > implementation, so they should include petscdmxxx.h. > This is also the result of DM doing too many jobs. > >> ** Note we don't do this for sub sub classes, KSPLGMRES should be >> KSPGMRESL etc. pity we should have done it right. >> > > I see the appeal of hierarchies, but I find them rigid and inconvenient. I > definitely prefer object models (interface and implementation, but no > implementation inheritance). The only reason for implementation inheritance > is code sharing, but I think that's frequently a false economy and comes > back to bite us in brittleness. If we had a lightweight way to selectively > forward methods, we could break out the sharable part into an internal > object with well-defined methods and avoid the piggy-back overriding of > methods (implementation inheritance). > I agree with this. I have never seen inheritance buy anything in the real world. 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