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

Re: PETSc team switching from BitKeeper
by Satish Balay 02 Jun '06

02 Jun '06

We have converted the repositories over to mercurial. Currently they are available as readonly with: hg clone old-http://www-unix.mcs.anl.gov/~petsc/petsc-dev hg clone old-http://www-unix.mcs.anl.gov/~petsc/BuildSystem This is a temporary thing - until we can move to a better location. Satish On Thu, 25 May 2006, Satish Balay wrote: > I'll start the conversion of petsc-dev & BuildSystem from bk to hg on > Friday (May 26) 10:00 PM [CST]. The public repositories will be > offline once I start the conversion. > > So, if you have some changes in to push - please schedule to do them > before that time [or wait until the conversion is done to hg - and > send in hg changes]. > > I expect this conversion process to take 2 days or so [hence > attempting to do this over the weekend]. > > I'll also be converting the ther repos [that don't get changed > frequently] - but they would get converted anytime [starting now] > > Thanks, > Satish > > On Tue, 23 May 2006, Barry Smith wrote: > > > In the next couple of weeks we will be switching all the > > PETSc repositories from bk (BitKeeper) to hg (Mercurial) > >

1 0

Re: PETSc team switching from BitKeeper
by Satish Balay 25 May '06

25 May '06

Folks, I'll start the conversion of petsc-dev & BuildSystem from bk to hg on Friday (May 26) 10:00 PM [CST]. The public repositories will be offline once I start the conversion. So, if you have some changes in to push - please schedule to do them before that time [or wait until the conversion is done to hg - and send in hg changes]. I expect this conversion process to take 2 days or so [hence attempting to do this over the weekend]. I'll also be converting the ther repos [that don't get changed frequently] - but they would get converted anytime [starting now] Thanks, Satish On Tue, 23 May 2006, Barry Smith wrote: > In the next couple of weeks we will be switching all the > PETSc repositories from bk (BitKeeper) to hg (Mercurial)

1 0

PETSc team switching from BitKeeper
by Barry Smith 23 May '06

23 May '06

PETSc users and friends, In the next couple of weeks we will be switching all the PETSc repositories from bk (BitKeeper) to hg (Mercurial) http://www.selenic.com/mercurial/wiki/index.cgi/Mercurial hg commands are "similar" to bk, here is a rough mapping bk clone hg clone bk citool hg commit (or bk ci; bk commit) bk pull hg pull hg update hg commit bk push hg push We are all learning hg now so expect our recommended way to use hg to change as we understand it better. Once a repository has been moved from bk to hg, it will no longer be avaible via bk. So if you are making changes to any repository PUSH often. We will attempt to provide - an http url to pull the PETSc repositories and - an ssh url to push repositories (for those with push permission). We'll provide more information as we proceed with this process. For now just install Mercurial (http://www.selenic.com/mercurial/wiki/index.cgi/Mercurial) Those inside MCS can start with hg clone ssh://[email protected]//home/petsc/hg-repo/petsc-private Please let us know if you have any questions or problems. Barry

1 0

Re: Complex numbers and C compiler
by Barry Smith 18 May '06

18 May '06

Mathieu, You can use (in the main directory) first make ACTION=testexamples_C tree then make ACTION=testexamples_Complex tree it should run a vast amount of the test problems. Barry On Thu, 18 May 2006, Mathieu Taillefumier wrote: > Dear All, > > I modify the library in order to be able to compile the complex version of the library using a C compiler. Most of the modifications are in the header files, but I needed to modify the name of some variables in some of the source code. The first run I made using one of my program gives the same results than the one with c++ version of the library. But before sending the part I modified, I would like to know if you have a very heavy test suite for the library. > > The second point is that you need to have c99 compliant compiler, which means on intel processors that you need to use icc or gcc 4.1 (gcc 4.0 most work also, but I didn't try). The other thing is that I have only access to computer based on intel or amd processors, which means that I cannot test the code on all possibles architectures in particular CRAY and s.o. > > Regards > > Mathieu >

1 0

Complex numbers and C compiler
by Mathieu Taillefumier 18 May '06

18 May '06

Dear All, I modify the library in order to be able to compile the complex version of the library using a C compiler. Most of the modifications are in the header files, but I needed to modify the name of some variables in some of the source code. The first run I made using one of my program gives the same results than the one with c++ version of the library. But before sending the part I modified, I would like to know if you have a very heavy test suite for the library. The second point is that you need to have c99 compliant compiler, which means on intel processors that you need to use icc or gcc 4.1 (gcc 4.0 most work also, but I didn't try). The other thing is that I have only access to computer based on intel or amd processors, which means that I cannot test the code on all possibles architectures in particular CRAY and s.o. Regards Mathieu -- -- Dr Mathieu Taillefumier Max Planck Institute for Microstructure physics Weinberg 2, D-06120 Halle (Saale) Germany

1 0

None
by Barry Smith 09 Apr '06

09 Apr '06

Yes, and eventually we'll want those variants generated automatically; actually not that difficult. The difficulty is mostly in designing a generator flexible enough but not so flexible it doesn't do anything :-) Barry From: William Gropp <gropp(a)mcs.anl.gov> > At 01:10 PM 4/8/2006, Barry Smith wrote: > > The biggest reason we haven't added "multi-vectors" is more design >decisions that have to be made then actual code implementation. There are >two important design decisions: Thanks, Barry. I agree with both of your suggestions. For the second case (storage ordering), in the long term, I might want to allow several forms of interlacing and padding, depending on what testing shows provides a significant performance boost. Bill >I) Introduce a new class or overload Vec? > > 1) Introduce a Vecs class, essentially copying the interface from > Vec and implement the methods. A Vecs is essentially a collection > of Vec. > Then provide methods such as > MatMults(), MatSolves(), PCApplys(), PCSetUps(), KSPSolves() etc > > 2) Overload the current Vec class so that a Vec is either a "regular" > Vec or a collection of vectors. Modify the Vec interface and methods > as needed, then modify the MatMult() etc as needed > > 3) Do 1) and have it all working well and then use this to quickly > do 2) and throw away the seperate concept of Vecs (without losing > the fastest possible performance for a "new" Vec that has a single > vector). > > The advantage of 1) is we never break the current interface. 2) has the > advantage of not introducing a new class; and since software > comprehension difficulty grows exponentially with the number of classes > this is a good thing. The advantage of 3) is we get an incremental > approach > to 2) (incremental is often good). Disadvantage of 3) is that users have > to live with first the Vecs interface (but on the other hand most people > won't use Vecs anyways) and then go back to Vec. > > I think 3) is the correct approach. > >II) Default storage of "multivectors"? (note: the interfaces for Vecs will, of > course, be data storage format neutral, but the code we actually write > cannot be) > > 1) Have the Vecs be essentially an array of Vec. > > 2) Have a Vecs essentially be a double array where the "values" of the > "vectors" are interlaced. > > The advantage of 1) is that it is easier to implement and doing things > like deflation (removing one of the vectors in a Vec) doesn't require > any copies of the vector data. The advantage of 2) is better performance, > and since we are using block for better performance we should take > advantage > of the best possible performance. > > I think implementing both 1) and 2) is appropriate, starting with 1) since > getting it completed would be faster. > > Barry > >Note: the Vecs currently in petscvec.h is just a toy and can be ignored. > >On Fri, 7 Apr 2006, Victor Eijkhout wrote: > >>The question has come up before. If all goes according to plan, then Bill >>Gropp will hire a student for the summer to implement it. On a project >>that I lead, and that has use for multivectors for a different purpose, >>there is actually budget. Feel free to recommend someone to Bill if you >>know of a good candidate. Does your former advisor have students who are >>familiar with the matter? >> >>Victor. >> >>On Apr 7, 2006, at 1:05 PM, Richard Tran Mills wrote: >> >>>Hi Guys, >>>My former Ph.D. advisor, Andreas Stathopoulos (andreas(a)cs.wm.edu) has >>>released an eigensolver package, PRIMME, that he is interested in >>>interfacing as an external package with PETSc. I told him a bit about >>>how he could do this, but what I couldn't really answer was his >>>questions about "multivector" support in PETSc. PRIMME implements block >>>Davidson/Jacobi-Davidson type methods, and thus needs to do a lot of >>>operations like sparse matrix-multivector multiplies. I haven't seen >>>anything like this in PETSc (and since PETSc doesn't have block Krylov >>>solvers, I suppose there is currently no need). Has anyone done any >>>work on stuff like this, or does anyone have any plans to? Any thoughts >>>on this? >>>Cheers, >>>Richard >> William Gropp http://www.mcs.anl.gov/~gropp

1 0

Re: [PETSC #14656] "multivector" support in PETSc?
by William Gropp 09 Apr '06

09 Apr '06

At 01:10 PM 4/8/2006, Barry Smith wrote: > The biggest reason we haven't added "multi-vectors" is more design >decisions that have to be made then actual code implementation. There are >two important design decisions: Thanks, Barry. I agree with both of your suggestions. For the second case (storage ordering), in the long term, I might want to allow several forms of interlacing and padding, depending on what testing shows provides a significant performance boost. Bill >I) Introduce a new class or overload Vec? > > 1) Introduce a Vecs class, essentially copying the interface from > Vec and implement the methods. A Vecs is essentially a collection > of Vec. > Then provide methods such as > MatMults(), MatSolves(), PCApplys(), PCSetUps(), KSPSolves() etc > > 2) Overload the current Vec class so that a Vec is either a "regular" > Vec or a collection of vectors. Modify the Vec interface and methods > as needed, then modify the MatMult() etc as needed > > 3) Do 1) and have it all working well and then use this to quickly > do 2) and throw away the seperate concept of Vecs (without losing > the fastest possible performance for a "new" Vec that has a single > vector). > > The advantage of 1) is we never break the current interface. 2) has the > advantage of not introducing a new class; and since software > comprehension difficulty grows exponentially with the number of classes > this is a good thing. The advantage of 3) is we get an incremental > approach > to 2) (incremental is often good). Disadvantage of 3) is that users have > to live with first the Vecs interface (but on the other hand most people > won't use Vecs anyways) and then go back to Vec. > > I think 3) is the correct approach. > >II) Default storage of "multivectors"? (note: the interfaces for Vecs will, of > course, be data storage format neutral, but the code we actually write > cannot be) > > 1) Have the Vecs be essentially an array of Vec. > > 2) Have a Vecs essentially be a double array where the "values" of the > "vectors" are interlaced. > > The advantage of 1) is that it is easier to implement and doing things > like deflation (removing one of the vectors in a Vec) doesn't require > any copies of the vector data. The advantage of 2) is better performance, > and since we are using block for better performance we should take > advantage > of the best possible performance. > > I think implementing both 1) and 2) is appropriate, starting with 1) since > getting it completed would be faster. > > Barry > >Note: the Vecs currently in petscvec.h is just a toy and can be ignored. > >On Fri, 7 Apr 2006, Victor Eijkhout wrote: > >>The question has come up before. If all goes according to plan, then Bill >>Gropp will hire a student for the summer to implement it. On a project >>that I lead, and that has use for multivectors for a different purpose, >>there is actually budget. Feel free to recommend someone to Bill if you >>know of a good candidate. Does your former advisor have students who are >>familiar with the matter? >> >>Victor. >> >>On Apr 7, 2006, at 1:05 PM, Richard Tran Mills wrote: >> >>>Hi Guys, >>>My former Ph.D. advisor, Andreas Stathopoulos (andreas(a)cs.wm.edu) has >>>released an eigensolver package, PRIMME, that he is interested in >>>interfacing as an external package with PETSc. I told him a bit about >>>how he could do this, but what I couldn't really answer was his >>>questions about "multivector" support in PETSc. PRIMME implements block >>>Davidson/Jacobi-Davidson type methods, and thus needs to do a lot of >>>operations like sparse matrix-multivector multiplies. I haven't seen >>>anything like this in PETSc (and since PETSc doesn't have block Krylov >>>solvers, I suppose there is currently no need). Has anyone done any >>>work on stuff like this, or does anyone have any plans to? Any thoughts >>>on this? >>>Cheers, >>>Richard >> William Gropp http://www.mcs.anl.gov/~gropp

1 0

Re: [PETSC #14656] "multivector" support in PETSc?
by Barry Smith 08 Apr '06

08 Apr '06

The biggest reason we haven't added "multi-vectors" is more design decisions that have to be made then actual code implementation. There are two important design decisions: I) Introduce a new class or overload Vec? 1) Introduce a Vecs class, essentially copying the interface from Vec and implement the methods. A Vecs is essentially a collection of Vec. Then provide methods such as MatMults(), MatSolves(), PCApplys(), PCSetUps(), KSPSolves() etc 2) Overload the current Vec class so that a Vec is either a "regular" Vec or a collection of vectors. Modify the Vec interface and methods as needed, then modify the MatMult() etc as needed 3) Do 1) and have it all working well and then use this to quickly do 2) and throw away the seperate concept of Vecs (without losing the fastest possible performance for a "new" Vec that has a single vector). The advantage of 1) is we never break the current interface. 2) has the advantage of not introducing a new class; and since software comprehension difficulty grows exponentially with the number of classes this is a good thing. The advantage of 3) is we get an incremental approach to 2) (incremental is often good). Disadvantage of 3) is that users have to live with first the Vecs interface (but on the other hand most people won't use Vecs anyways) and then go back to Vec. I think 3) is the correct approach. II) Default storage of "multivectors"? (note: the interfaces for Vecs will, of course, be data storage format neutral, but the code we actually write cannot be) 1) Have the Vecs be essentially an array of Vec. 2) Have a Vecs essentially be a double array where the "values" of the "vectors" are interlaced. The advantage of 1) is that it is easier to implement and doing things like deflation (removing one of the vectors in a Vec) doesn't require any copies of the vector data. The advantage of 2) is better performance, and since we are using block for better performance we should take advantage of the best possible performance. I think implementing both 1) and 2) is appropriate, starting with 1) since getting it completed would be faster. Barry Note: the Vecs currently in petscvec.h is just a toy and can be ignored. On Fri, 7 Apr 2006, Victor Eijkhout wrote: > >The question has come up before. If all goes according to plan, then Bill >Gropp will hire a student for the summer to implement it. On a project that >I lead, and that has use for multivectors for a different purpose, there is >actually budget. Feel free to recommend someone to Bill if you know of a >good candidate. Does your former advisor have students who are familiar >with the matter? > >Victor. > >On Apr 7, 2006, at 1:05 PM, Richard Tran Mills wrote: > >>Hi Guys, >> >>My former Ph.D. advisor, Andreas Stathopoulos (andreas(a)cs.wm.edu) has >>released an eigensolver package, PRIMME, that he is interested in >>interfacing as an external package with PETSc. I told him a bit about how >>he could do this, but what I couldn't really answer was his questions >>about "multivector" support in PETSc. PRIMME implements block >>Davidson/Jacobi-Davidson type methods, and thus needs to do a lot of >>operations like sparse matrix-multivector multiplies. I haven't seen >>anything like this in PETSc (and since PETSc doesn't have block Krylov >>solvers, I suppose there is currently no need). Has anyone done any work >>on stuff like this, or does anyone have any plans to? Any thoughts on >>this? >> >>Cheers, >>Richard >> > > >

1 0

Re: [PETSC #14656] "multivector" support in PETSc?
by Barry Smith 08 Apr '06

08 Apr '06

The biggest reason we haven't added "multi-vectors" is more design decisions that have to be made then actual code implementation. There are two important design decisions: I) Introduce a new class or overload Vec? 1) Introduce a Vecs class, essentially copying the interface from Vec and implement the methods. A Vecs is essentially a collection of Vec. Then provide methods such as MatMults(), MatSolves(), PCApplys(), PCSetUps(), KSPSolves() etc 2) Overload the current Vec class so that a Vec is either a "regular" Vec or a collection of vectors. Modify the Vec interface and methods as needed, then modify the MatMult() etc as needed 3) Do 1) and have it all working well and then use this to quickly do 2) and throw away the seperate concept of Vecs (without losing the fastest possible performance for a "new" Vec that has a single vector). The advantage of 1) is we never break the current interface. 2) has the advantage of not introducing a new class; and since software comprehension difficulty grows exponentially with the number of classes this is a good thing. The advantage of 3) is we get an incremental approach to 2) (incremental is often good). Disadvantage of 3) is that users have to live with first the Vecs interface (but on the other hand most people won't use Vecs anyways) and then go back to Vec. I think 3) is the correct approach. II) Default storage of "multivectors"? (note: the interfaces for Vecs will, of course, be data storage format neutral, but the code we actually write cannot be) 1) Have the Vecs be essentially an array of Vec. 2) Have a Vecs essentially be a double array where the "values" of the "vectors" are interlaced. The advantage of 1) is that it is easier to implement and doing things like deflation (removing one of the vectors in a Vec) doesn't require any copies of the vector data. The advantage of 2) is better performance, and since we are using block for better performance we should take advantage of the best possible performance. I think implementing both 1) and 2) is appropriate, starting with 1) since getting it completed would be faster. Barry Note: the Vecs currently in petscvec.h is just a toy and can be ignored. On Fri, 7 Apr 2006, Victor Eijkhout wrote: > The question has come up before. If all goes according to plan, then Bill > Gropp will hire a student for the summer to implement it. On a project that I > lead, and that has use for multivectors for a different purpose, there is > actually budget. Feel free to recommend someone to Bill if you know of a good > candidate. Does your former advisor have students who are familiar with the > matter? > > Victor. > > On Apr 7, 2006, at 1:05 PM, Richard Tran Mills wrote: > >> Hi Guys, >> >> My former Ph.D. advisor, Andreas Stathopoulos (andreas(a)cs.wm.edu) has >> released an eigensolver package, PRIMME, that he is interested in >> interfacing as an external package with PETSc. I told him a bit about how >> he could do this, but what I couldn't really answer was his questions about >> "multivector" support in PETSc. PRIMME implements block >> Davidson/Jacobi-Davidson type methods, and thus needs to do a lot of >> operations like sparse matrix-multivector multiplies. I haven't seen >> anything like this in PETSc (and since PETSc doesn't have block Krylov >> solvers, I suppose there is currently no need). Has anyone done any work >> on stuff like this, or does anyone have any plans to? Any thoughts on >> this? >> >> Cheers, >> Richard >> > >

1 0

Re: PETSc/ridgeSim 3D scaling on BG/L
by Matthew Knepley 02 Apr '06

02 Apr '06

Thats awesome. 80% true efficiency for 1K nodes on under 1 million unknowns. Thats only 1,000 unknowns per proc. If we were cranking the problems size, I am sure you'd be up in the 90s. Hopefully this summer we can deliver you much improved serial performance as well. BTW, I want to talk sometime about the subduction benchmark. Van Keken talked about it at Purdue, so I got a diametrically opposed viewpoint from a sympathetic person. It was eye opening. Matt On 4/2/06, Richard Katz <katz(a)ldeo.columbia.edu> wrote: > > Hi All, > > Thought you might be interested to see this. > > The simulation is finite-volume, steady-state, non-Newtonian CFD in 3D. > And, of course, it is done using PETSc (version 2.3.1). > > How does this compare to other PETSc-based simulations? > > Cheers > Rich > > Barry -- I had a problem with the the jobs that we discussed but I'm > hoping to run them properly tonight. > > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0