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

watching petsc-dev in gource
by Barry Smith 13 Feb '13

13 Feb '13

You should watch petsc-dev in gource. (Oh there's the esi directory, December 2001 :-). You have to watch a long time before Jed appears :-) Barry

1 0

petsccusp.h is a weird file
by Barry Smith 13 Feb '13

13 Feb '13

It is in include/petsccusp.h but has includes from the PETSc source code tree (which won't even work for --prefix installs). Likely this need to be refactored or discarded or something #if !defined(__PETSCCUSP_H) #define __PETSCCUSP_H /* This should only be included in user code that uses CUSP directly and hence the file name ends with .cu */ #include <../src/vec/vec/impls/dvecimpl.h> #include <../src/vec/vec/impls/seq/seqcusp/cuspvecimpl.h> #endif

1 0

PetscViewerBinaryMatlabOpen() being removed
by Barry Smith 13 Feb '13

13 Feb '13

Ethan and Richard, Well over a decade late I have refactored your PetscViewerBinaryMatlabOpen() code to embed it in the standard PETSc binary viewer so it doesn't introduce nonstandard paradigms into PETSc. Could you please test it out in petsc-dev to find all the bugs I have introduced? To get the effect you just call PetscViewerBinaryOpen() followed by PetscViewerSetFormat(viewer,PETSC_FORMAT_BINARY_MATLAB); the names of the variables are obtained by the names of the PETSc objects which may be set with PetscObjectSetName(). Thanks Barry

1 0

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

13 Feb '13

Currently PETSc has the following "organization" There are eight "packages" (each which can be in its own static/dynamic library (libpetscPACKAGENAME.something) and has its own include file petscPACKAGENAME.h*) sys vec mat dm characteristic ksp snes ts Each of these packages (except sys) has a "main" class with the same name as the package (KSP in ksp, TS in ts example). Each package also contains a bunch of "related" classes (for example the ksp package has the PC class, the ts package has the TSAdapt class etc etc). Each class (except a couple) is implemented as an abstract base class with several implementations (Mat -> Mat_SeqAIJ etc) Occasionally there are "almost" subclasses of subclasses (KSPGMRES -> KSPLGMRES, KSPFGMRES stored in subdirectory of gmres) The naming of subclasses for names and methods is suppose to be readable from left to right (for example KSPGMRES, KSPGMRESSetRestart())** We don't always/usually directly incorporate the names of packages in the names of the various classes in that package (for example we have PC, we don't call PC KSPPC, we have PetscViewer we don't have SysViewer) but sometimes we seem to (TSAdapt is a class in the ts package, or is it a subclass of TS?). We also have strange names like ISLocalToGlobalMapping which is not a subclass of IS, nor is it in the is package (there is no is package). We sometimes namespace with Petsc but usually don't. Much of the specific naming is historical and happenstance. I believe that the more we can systematize the naming conventions and hierarchy the easier we make PETSc to use and maintain/write. At the same time we have to be somewhat sensitive to what people are used to and probably shouldn't change 80% of the names every six months. If I were to start PETSc today I would give packages different names from classes and always name space everything with Petsc_Packagename_Classname[_Subclassname[_Subsubclass]] (without the _ of course). For example, PetscLinearKrylov[GMRES[L]], PetscLinearPreconditionerFieldsplit. Don't worry this is not going to happen. I guess this is one of the reasons I pick on PetscSection so much; I don't know where it belongs, it begins with Petsc which (informally) is mostly sys stuff but it is not like sys stuff, it is implemented in the Vec class part of the vec package but it is definitely not a Vec. Note there are no action items in this email, just me thinking out loud. Barry * 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)! ** Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right. On Feb 13, 2013, at 7:50 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Feb 13, 2013 at 7:40 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Regardless of exactly how this shakes out I think you both have to agree that PetscSection is a bit of an oddball and it should be more "integrated" with the "IS stuff" in that we have a single source code location (directory) and set of concepts related to indexing things. And don't have some in the Vec directory. > So, for now, I won't change names or functionality but would like permission to move source around. Who knows, maybe in the end the is directory will get a more suitable name. > > That's fine with me, but note that vsection.c depends on Vec, but IS does not depend on Vec. vsection.c depends on Vec so it can't simply be moved to src/vec/is. > > > Barry > > As you know I really really like having names that convey connections left to right, KSPGMRES, PC_ILU etc. I think this helps make the learning and understanding curve lower. Now people see IS and PetscSection and they are two completely unrelated things to their eyes but in fact they are not unrelated and I would like to convey that somehow in the future. > > BTW: I consider it a terrible tragedy that in (for example C++ and Java) one can define a subclass of a class and just use a completely arbitrary ASCII name for the subclass completely unrelated to the class it is derived from, talk about losing information. > > Just be glad not too many projects chose the German way, using a three-term recurrence to compute the designation order, and always withholding the verb until the end. ;-)

1 0

Re: [petsc-dev] A closer look at the Xeon Phi
by Tim Tautges 13 Feb '13

13 Feb '13

On 02/12/2013 06:40 PM, Jed Brown wrote: > On Tue, Feb 12, 2013 at 6:06 PM, Tim Tautges <tautges(a)mcs.anl.gov <mailto:[email protected]>> wrote: > > I'm kind of surprised at the > 10k element crossover myself. For the strong scaling cases, at high core counts, > that's not terribly far from the number of DOFS per processor, is it? I guess CPUs will be slower than the Xeon in > most cases (BGx), or fewer (Titan), but still. > > > Which crossover are you referring to? The CPU versus GTX285 at about 20k dofs, but with only very small gains for > another order of magnitude? > Yeah, that's what I meant. There seems to be little benefit to both Phis and true GPUs until you get well above 20k DOFs per core, but for strong scaling studies, I wonder how many applications are really that large. Maybe they are on Titan-class machines (fewer CPU cores, more memory/core), but maybe those cores are faster than the Xeon 55xx (not sure about that assertion), but then the crossover would be at even larger DOF counts. If you take into account the added complexity of building those codes and running those machines, I still don't see the payoff to those machines. Anybody know whether that effect showed up in the INCITE proposals? Since users get charged for the GPUs whether they use them or not, I'd expect to see requests skewed toward Mira. - tim > For 2D Laplace, we expect to see strong scaling peter out around a couple thousand dofs per core. It can go a little > further on Blue Gene because the network is much faster and the cores are a bit slower. > > Titan has a lot of (premium price) GPUs that you have to use to utilize the machine well, but it's unclear whether the > architecture is delivering a science/dollars advantage, even if you ignore development costs to port and re-tune codes > and the environment costs (it's more complicated to build and run, so it takes people longer to get running). I think > the main justification is speculation about what future hardware will look like, not cost-effectiveness today. -- ================================================================ "You will keep in perfect peace him whose mind is steadfast, because he trusts in you." Isaiah 26:3 Tim Tautges Adjunct Professor, Engr. Physics (tautges(a)engr.wisc.edu) University of Wisconsin-Madison gphone: (608) 354-1459 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706

1 0

Re: [petsc-dev] removing PETSC_NULL from petsc-dev
by Jed Brown 13 Feb '13

13 Feb '13

On Wed, Feb 13, 2013 at 7:29 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I have removed the use of PETSC_NULL from all PETSc C code. Please > remember to just use NULL in PETSc source code in the future (or Karl's > script will find you). > > > > I see you changed to > > > > #define PETSC_IGNORE NULL > > > > but kept > > > > #define PETSC_NULL 0 > > > > Should the second be updated to > > > > #define PETSC_NULL NULL > > > > because it is stricter about passing PETSC_NULL for an integer argument? > > Yes, I was hesitant to change too much at once. It is fine to change and > fine to add the damn deprecated message. Sadly, this hack does not work because according to C++, the comma-sequence '(x,0)' yields a different type from '0'. In particular, the latter can be implicitly converted to a pointer type, but the former cannot. AFAIK, the only way to do this is to use 'nullptr'. Consequently, we can update to '#define PETSC_NULL NULL', but cannot include a deprecated message. I also think I was perhaps a little overzealous about deprecation. It doesn't cause any hardship for it to exist as long as we don't refer to it any where, thus there may be no reason to break user code by removing PETSC_NULL. Since people are inherently a bit lazy, I think its use will quietly go away. https://bitbucket.org/petsc/petsc-dev/commits/77e0b4525183a96d1d7836ee30256… This will cause warnings at those places where PETSC_NULL was used in place of an int, but people should update those anyway because it's confusing. Note that we still cannot _depend_ on NULL having "pointer" type, for example, when passed to a variadic function. (We had a thread about that a while back.) It's perfectly valid for stddef.h to '#define NULL 0'.

1 0

Re: [petsc-dev] I hate this one
by Karl Rupp 13 Feb '13

13 Feb '13

>> the checks are in src/contrib/style/checks/. You can run them from PETSC_DIR, but they currently check the full source tree only. > > Karl will be modifying them to be able to run directly on single source files and subdirectories. And on modified files obtained from `hg status`... Same should work for uncrustify. Best regards, Karli

1 0

Re: [petsc-dev] I hate this one
by Barry Smith 13 Feb '13

13 Feb '13

On Feb 13, 2013, at 10:45 AM, Milad Fatenejad <milad(a)uchicago.edu> wrote: > Thanks Karl! > > On Wed, Feb 13, 2013 at 10:38 AM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hi Milad, > > the checks are in src/contrib/style/checks/. You can run them from PETSC_DIR, but they currently check the full source tree only. Karl will be modifying them to be able to run directly on single source files and subdirectories. Barry > Compare with > http://krupp.iue.tuwien.ac.at/petsc-style/ > to see whether you've introduced additional 'violations'. You can also generate the full HTML output by running src/contrib/style/runhtml.sh from PETSC_DIR and view/compare the output in src/contrib/style/html/index.html > > Best regards, > Karli > > > > On 02/13/2013 10:32 AM, Milad Fatenejad wrote: > Hello: > > I am working on modifying PETSc to interoperate with the MOAB mesh > library. I'd love to get some of Karl's scripts to ensure that my code > is compliant with the style guide. Are they available somewhere? > > Thank You > Milad > > On Mon, Jan 21, 2013 at 10:19 AM, Sean Farley <sean(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <rupp(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > Hi Matt, > > > > > >> Again, there are limits to everything, and this surpasses > the useful > >> > >> limit to this kind of specification. This is not personal > >> expression, this > >> is ease of reading. > >> > >> > >> Also, judging by the ENORMOUS number of source code changes, > "everyone" > >> was not following the informal guidelines. > > > > > > Yes, the changes are 'enormous' if you count the absolute number > of lines. > > However, my overall impression while refactoring was that I > touched ~1% of > > the total code base only. It's the huge size of the code base > that makes the > > number of changes appear to be high. > > > > Also, an estimated 50% of the violations stem from a copy&paste > of older > > code or previous examples rather than intentionally ignoring the > style > > guidelines. Thus, by bringing everything to a consistent state, a > (large) > > number of such copy&paste-induced violations are no longer going > to happen > > at all. > > > > The PETSc coding style guide needs to define exactly one style. > Your style > > preference obviously differs. My personal preference differs > slightly, too. > > Maybe Jed and/or others would prefer another slight variation. > Nevertheless, > > allowing a bit more flexibility in one's own personal coding style by > > following one common coding style is to the benefit of the whole > project. > > Visual consistency is an obvious one, but most importantly it aids in > > setting up other scripts for increased uniformity among the > different PETSc > > modules. > > > > You may argue that it does not matter whether we have 'for(...)' > or 'for > > (...)'. While this is certainly right for a compiler, I would > like to give > > you one example where it *does* make a difference: > > src/mat/interface/matrix.c: > > PetscErrorCode MatSetValuesAdifor(Mat mat,PetscInt nl,void *v) > > So, keeping consistency with the style guide, we would write > > for (...) {...} > > MatSetValuesAdifor(...) {...} > > and there is the additional blank contributing to the difference > between the > > function call and the for-loop. If, however, we have > > for(...) {...} > > MatSetValuesAdifor(...) {...} > > any scripts additionally need to check for characters in front of > 'for'. > > Fortunately, it is *currently* sufficient to just consider all > characters > > other than a blank in front of 'for' to be a function call. > However, one day > > we might find code such as > > do_something(...);for(...) {...}; > > or even > > cilk_for(...) > > and all of a sudden we are unable to use any simple checker > scripts any > > more. With a common PETSc style, the additional blank would still > allow for > > far simpler checks and refactoring if required. > > > > Just my 2 cents… > > Thanks, Karl. I appreciate your effort on this front. > >

1 0

Re: [petsc-dev] I hate this one
by Milad Fatenejad 13 Feb '13

13 Feb '13

Thanks Karl! On Wed, Feb 13, 2013 at 10:38 AM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hi Milad, > > the checks are in src/contrib/style/checks/. You can run them from > PETSC_DIR, but they currently check the full source tree only. Compare with > http://krupp.iue.tuwien.ac.at/**petsc-style/<http://krupp.iue.tuwien.ac.at/petsc-style/> > to see whether you've introduced additional 'violations'. You can also > generate the full HTML output by running src/contrib/style/runhtml.sh from > PETSC_DIR and view/compare the output in src/contrib/style/html/index.** > html > > Best regards, > Karli > > > > On 02/13/2013 10:32 AM, Milad Fatenejad wrote: > >> Hello: >> >> I am working on modifying PETSc to interoperate with the MOAB mesh >> library. I'd love to get some of Karl's scripts to ensure that my code >> is compliant with the style guide. Are they available somewhere? >> >> Thank You >> Milad >> >> On Mon, Jan 21, 2013 at 10:19 AM, Sean Farley <sean(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <rupp(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> > Hi Matt, >> > >> > >> >> Again, there are limits to everything, and this surpasses >> the useful >> >> >> >> limit to this kind of specification. This is not personal >> >> expression, this >> >> is ease of reading. >> >> >> >> >> >> Also, judging by the ENORMOUS number of source code changes, >> "everyone" >> >> was not following the informal guidelines. >> > >> > >> > Yes, the changes are 'enormous' if you count the absolute number >> of lines. >> > However, my overall impression while refactoring was that I >> touched ~1% of >> > the total code base only. It's the huge size of the code base >> that makes the >> > number of changes appear to be high. >> > >> > Also, an estimated 50% of the violations stem from a copy&paste >> of older >> > code or previous examples rather than intentionally ignoring the >> style >> > guidelines. Thus, by bringing everything to a consistent state, a >> (large) >> > number of such copy&paste-induced violations are no longer going >> to happen >> > at all. >> > >> > The PETSc coding style guide needs to define exactly one style. >> Your style >> > preference obviously differs. My personal preference differs >> slightly, too. >> > Maybe Jed and/or others would prefer another slight variation. >> Nevertheless, >> > allowing a bit more flexibility in one's own personal coding style >> by >> > following one common coding style is to the benefit of the whole >> project. >> > Visual consistency is an obvious one, but most importantly it aids >> in >> > setting up other scripts for increased uniformity among the >> different PETSc >> > modules. >> > >> > You may argue that it does not matter whether we have 'for(...)' >> or 'for >> > (...)'. While this is certainly right for a compiler, I would >> like to give >> > you one example where it *does* make a difference: >> > src/mat/interface/matrix.c: >> > PetscErrorCode MatSetValuesAdifor(Mat mat,PetscInt nl,void *v) >> > So, keeping consistency with the style guide, we would write >> > for (...) {...} >> > MatSetValuesAdifor(...) {...} >> > and there is the additional blank contributing to the difference >> between the >> > function call and the for-loop. If, however, we have >> > for(...) {...} >> > MatSetValuesAdifor(...) {...} >> > any scripts additionally need to check for characters in front of >> 'for'. >> > Fortunately, it is *currently* sufficient to just consider all >> characters >> > other than a blank in front of 'for' to be a function call. >> However, one day >> > we might find code such as >> > do_something(...);for(...) {...}; >> > or even >> > cilk_for(...) >> > and all of a sudden we are unable to use any simple checker >> scripts any >> > more. With a common PETSc style, the additional blank would still >> allow for >> > far simpler checks and refactoring if required. >> > >> > Just my 2 cents… >> >> Thanks, Karl. I appreciate your effort on this front. >> >> >>

1 0

Re: [petsc-dev] I hate this one
by Karl Rupp 13 Feb '13

13 Feb '13

Hi Milad, the checks are in src/contrib/style/checks/. You can run them from PETSC_DIR, but they currently check the full source tree only. Compare with http://krupp.iue.tuwien.ac.at/petsc-style/ to see whether you've introduced additional 'violations'. You can also generate the full HTML output by running src/contrib/style/runhtml.sh from PETSC_DIR and view/compare the output in src/contrib/style/html/index.html Best regards, Karli On 02/13/2013 10:32 AM, Milad Fatenejad wrote: > Hello: > > I am working on modifying PETSc to interoperate with the MOAB mesh > library. I'd love to get some of Karl's scripts to ensure that my code > is compliant with the style guide. Are they available somewhere? > > Thank You > Milad > > On Mon, Jan 21, 2013 at 10:19 AM, Sean Farley <sean(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp <rupp(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > Hi Matt, > > > > > >> Again, there are limits to everything, and this surpasses > the useful > >> > >> limit to this kind of specification. This is not personal > >> expression, this > >> is ease of reading. > >> > >> > >> Also, judging by the ENORMOUS number of source code changes, > "everyone" > >> was not following the informal guidelines. > > > > > > Yes, the changes are 'enormous' if you count the absolute number > of lines. > > However, my overall impression while refactoring was that I > touched ~1% of > > the total code base only. It's the huge size of the code base > that makes the > > number of changes appear to be high. > > > > Also, an estimated 50% of the violations stem from a copy&paste > of older > > code or previous examples rather than intentionally ignoring the > style > > guidelines. Thus, by bringing everything to a consistent state, a > (large) > > number of such copy&paste-induced violations are no longer going > to happen > > at all. > > > > The PETSc coding style guide needs to define exactly one style. > Your style > > preference obviously differs. My personal preference differs > slightly, too. > > Maybe Jed and/or others would prefer another slight variation. > Nevertheless, > > allowing a bit more flexibility in one's own personal coding style by > > following one common coding style is to the benefit of the whole > project. > > Visual consistency is an obvious one, but most importantly it aids in > > setting up other scripts for increased uniformity among the > different PETSc > > modules. > > > > You may argue that it does not matter whether we have 'for(...)' > or 'for > > (...)'. While this is certainly right for a compiler, I would > like to give > > you one example where it *does* make a difference: > > src/mat/interface/matrix.c: > > PetscErrorCode MatSetValuesAdifor(Mat mat,PetscInt nl,void *v) > > So, keeping consistency with the style guide, we would write > > for (...) {...} > > MatSetValuesAdifor(...) {...} > > and there is the additional blank contributing to the difference > between the > > function call and the for-loop. If, however, we have > > for(...) {...} > > MatSetValuesAdifor(...) {...} > > any scripts additionally need to check for characters in front of > 'for'. > > Fortunately, it is *currently* sufficient to just consider all > characters > > other than a blank in front of 'for' to be a function call. > However, one day > > we might find code such as > > do_something(...);for(...) {...}; > > or even > > cilk_for(...) > > and all of a sudden we are unable to use any simple checker > scripts any > > more. With a common PETSc style, the additional blank would still > allow for > > far simpler checks and refactoring if required. > > > > Just my 2 centsï¿½ > > Thanks, Karl. I appreciate your effort on this front. > > >

1 0