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

Re: ufuncs, iterators
by Barry Smith 18 Aug '05

18 Aug '05

Simon, There is not because what does MatSet() mean for a sparse matrix? Make it dense, just set all the current nonzeros, error? You tell us, I could live with either of the later two but don't really like the first. Barry BTW: possibly related note, are you using dense matrices sometimes to represent "just" 2-arrays; that is, not as representations of linear operators. If so, I do not think this is the correct approach! Conceptually PETSc Mat's are linear operators I think it would be a big mistake to overload them as 2-arrays also. The "correct" approach is to use the DACreate2d() construct for handling 2-d arrays; With the DA the values are stored into Vecs but there is additional information about the two array structure; it can be decomposed nicely in parallel and one can set/access values with the usual two i,j indices. Of course if they are being used as operators ignore this. In Matlab matrix == 2-d array == matrix (in my opinion a terrible design decision) in PETSc matrix (dense) != 2-d array , the are completely different beasts mathematically On Fri, 19 Aug 2005, Simon Burton wrote: > > Is there a way to simulate a MatSet (like VecSet) ? > > Simon. > >

1 0

Re: ufuncs, iterators
by Simon Burton 18 Aug '05

18 Aug '05

Is there a way to simulate a MatSet (like VecSet) ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

1 0

Re: ufuncs, iterators
by Simon Burton 18 Aug '05

18 Aug '05

On Thu, 18 Aug 2005 19:57:02 -0500 Matthew Knepley <knepley(a)mcs.anl.gov> wrote: > > > (d) m=exp(m) (pointwise exp) > > We could add pointwise operations just like the VecPointwise*(). > > Matt Yes, we need MatPointwiseMult aswell. Should I make a start on this ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

1 0

Re: ufuncs, iterators
by Matthew Knepley 18 Aug '05

18 Aug '05

Simon Burton <simon(a)arrowtheory.com> writes: > Hi, > > Along the lines of python's numarray [1], we need some way of > operating pointwise (and inner/outer operations) on Mat/Vec objects. > > In particular, we need things like the following: > (a) v=add.reduce(m) (sum along rows/cols of a Mat to produce a Vec) This seems to be handled. > (b) m=add.outer(v1,v2) (sum of all elements of two Vecs to produce a Mat) This should be in MatDense() interface specifically since it produces a dense matrix. In fact, I thought it was always preferrable not to form the matrix explicitly. I would have to see how it is used. > (c) m=add(m1,m2) (pointwise sum) We have MatAXPY() > (d) m=exp(m) (pointwise exp) We could add pointwise operations just like the VecPointwise*(). Matt > Right now we can do (a) and (b) using dgemm and single column/row matrices with just 1s, > and we can do (c) using SetValues. But for (d): it looks like we will be writing a c-loop ? > > And I don't think the PETSc interface to dgemm (MatMatMult*) is general enough to do (b) > (we need one of the products to be added to the other product, so beta=1). > > It would be easy enough to use numarray to "shadow" the PETSc arrays (using *GetArray) > and then make numarray do the work, but this seems doomed to failure because > numarray is inherently dense. > > Simon. > > > [1]: http://stsdas.stsci.edu/numarray/numarray-1.3.html/node35.html > > -- > Simon Burton, B.Sc. > Licensed PO Box 8066 > ANU Canberra 2601 > Australia > Ph. 61 02 6249 6940 > http://arrowtheory.com > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

ufuncs, iterators
by Simon Burton 18 Aug '05

18 Aug '05

Hi, Along the lines of python's numarray [1], we need some way of operating pointwise (and inner/outer operations) on Mat/Vec objects. In particular, we need things like the following: (a) v=add.reduce(m) (sum along rows/cols of a Mat to produce a Vec) (b) m=add.outer(v1,v2) (sum of all elements of two Vecs to produce a Mat) (c) m=add(m1,m2) (pointwise sum) (d) m=exp(m) (pointwise exp) Right now we can do (a) and (b) using dgemm and single column/row matrices with just 1s, and we can do (c) using SetValues. But for (d): it looks like we will be writing a c-loop ? And I don't think the PETSc interface to dgemm (MatMatMult*) is general enough to do (b) (we need one of the products to be added to the other product, so beta=1). It would be easy enough to use numarray to "shadow" the PETSc arrays (using *GetArray) and then make numarray do the work, but this seems doomed to failure because numarray is inherently dense. Simon. [1]: http://stsdas.stsci.edu/numarray/numarray-1.3.html/node35.html -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

1 0

Re: [DOLFIN-dev] [[email protected]: Re: [PETSC #13286] Make pcimpl.h a public API]
by Anders Logg 05 Jul '05

05 Jul '05

On Tue, Jul 05, 2005 at 01:20:34PM -0400, Faheem Mitha wrote: > On Tue, 5 Jul 2005, Johan Jansson wrote: > > >Hi, > > > >Below is some discussion about PETSc standard installation and > >packages. It seems that a petsc-dev package should include the PETSc > >source, and thus that DOLFIN can assume the PETSc source is available > >when building. This would solve both the pcimpl.h issue as well as the > >issue of extracting PETSc compiler flags. > > Hi, > > I mean no disrespect, but I think that assuming that the source is > available would make life much more difficult for packagers, is very > non-standard, and generally undesirable. If you don't believe me, ask > people on an appropriate technical mailing list. > debian-devel(a)lists.debian.org comes to mind. > > In general a *-dev should contain headers files and that is all. I could > probably find some technical standards material to quote you on this if > you wanted. Yes, I'm familiar with this standard as a long-time Debian user. Of course we should try to follow the standard whenever possible. > If I understand correctly, you want to access some internals of PETSc, so > having the 'public' headers available is not sufficient since you want to > compile against a header that defines a 'private' implementation, is that > correct? Yes. > I don't know what the best way of resolving this is, but I do think that > compiling DOLFIN should work 'out-of-the-box' on a 'make install' of > PETSc. I agree. The problem as I see it is that PETSc does not follow the standard. Even if you do a 'make install' in PETSc, you still need to define a PETSC_DIR, right? And then there's the problem of getting the compiler flags and libs. A petsc-config script installed by PETSc 'make install' in $prefix/bin/ would be useful. As I've said, I'd be happy to update DOLFIN to work with an installed version of PETSc. I don't know the details so I can't do it right now, but I can figure it out and do it later or someone can send me a patch. In particular, the next stable release of DOLFIN (will be out today) will require a user to download PETSc 2.3.0 and do export PETSC_DIR=`pwd` ./config/configure.py --with-clanguage=cxx make all > I can see three possibilities. > > a) The PETSc 'make install' adds these internal details as necessary > to a make install. This would be a reasonable solution. One could > argue that if someone needs to access these private details, then > perhaps they should be regarded as public. I think this is the best alternative. It might also be the case that we should really not access pcimpl.h and there are ways around this. I have not looked at this in detail so I don't know. > b) The packager adds these files to the PETSc package to make the > compilation of DOLFIN work. I'm certainly willing to do that if you > told me what and where to put the extra files. > > However, this means DOLFIN would not compile with the result of a > PETSc 'make install'. Also, this solution does not scale well, since > some other package may want to access some other internal > stuff. However, this would still be better than expecting the full > source to be present. > > c) DOLFIN includes those files itself. This is another possibility > which is not ideal, since DOLFIN should not really be shipping bits of > another package. This is the second best alternative. > However, still preferable to assuming the source is available. > > Please bear in mind that the current size of PETSc, as I have packaged > it, is around 130 Mb. This is already on the large size for a library > package, and having to make the source available would make this even > larger. I'd like to figure out ways to make this smaller. That seems unreasonably large. The Debian package is 1.4MB (4.2MB installed). Maybe you can talk to Adam Powell? (I see that you have submitted a request to package 2.3.0 already.) > Please, I beg both the DOLFIN and PETSc development teams to reconsider. > Again, I mean no disrespect. I appreciate all your hard work and > expertise, and just want what is technically best. So do I, thanks for your comments! /Anders

1 0

Re: [DOLFIN-dev] [[email protected]: Re: [PETSC #13286] Make pcimpl.h a public API]
by Faheem Mitha 05 Jul '05

05 Jul '05

On Tue, 5 Jul 2005, Johan Jansson wrote: > Hi, > > Below is some discussion about PETSc standard installation and > packages. It seems that a petsc-dev package should include the PETSc > source, and thus that DOLFIN can assume the PETSc source is available > when building. This would solve both the pcimpl.h issue as well as the > issue of extracting PETSc compiler flags. Hi, I mean no disrespect, but I think that assuming that the source is available would make life much more difficult for packagers, is very non-standard, and generally undesirable. If you don't believe me, ask people on an appropriate technical mailing list. debian-devel(a)lists.debian.org comes to mind. In general a *-dev should contain headers files and that is all. I could probably find some technical standards material to quote you on this if you wanted. If I understand correctly, you want to access some internals of PETSc, so having the 'public' headers available is not sufficient since you want to compile against a header that defines a 'private' implementation, is that correct? I don't know what the best way of resolving this is, but I do think that compiling DOLFIN should work 'out-of-the-box' on a 'make install' of PETSc. I can see three possibilities. a) The PETSc 'make install' adds these internal details as necessary to a make install. This would be a reasonable solution. One could argue that if someone needs to access these private details, then perhaps they should be regarded as public. b) The packager adds these files to the PETSc package to make the compilation of DOLFIN work. I'm certainly willing to do that if you told me what and where to put the extra files. However, this means DOLFIN would not compile with the result of a PETSc 'make install'. Also, this solution does not scale well, since some other package may want to access some other internal stuff. However, this would still be better than expecting the full source to be present. c) DOLFIN includes those files itself. This is another possibility which is not ideal, since DOLFIN should not really be shipping bits of another package. However, still preferable to assuming the source is available. Please bear in mind that the current size of PETSc, as I have packaged it, is around 130 Mb. This is already on the large size for a library package, and having to make the source available would make this even larger. I'd like to figure out ways to make this smaller. Please, I beg both the DOLFIN and PETSc development teams to reconsider. Again, I mean no disrespect. I appreciate all your hard work and expertise, and just want what is technically best. Thank you for your attention. Faheem.

1 0

Re: fortran interface/dir-reorg push
by Satish Balay 02 Jun '05

02 Jun '05

On Thu, 2 Jun 2005, Satish Balay wrote: > > With this push - you'll need updated 'bfort' for the fortran interface > to work. Forgot to mention - the updated bfort is at ftp://ftp.mcs.anl.gov/pub/petsc/tmp/sowing.tar.gz [--download-sowing gets the correct version] Satish

1 0

fortran interface/dir-reorg push
by Satish Balay 02 Jun '05

02 Jun '05

I'll push my changes to fortran interface & some code reorg. This is not completely done yet - but I'd like to push - to minimize potential merge conflicts.. With this push - you'll need updated 'bfort' for the fortran interface to work. Satish

1 0

no longer a seperate libpetscfortran library
by Barry Smith 24 May '05

24 May '05

petsc-dev users, Satish recently reorganized the generation of the PETSc fortran stubs; there is no longer a seperate libpetscfortran library; the stubs are now in the other libraries. Sorry for not leting everyone know sooner, Barry

1 0