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

Re: [petsc-dev] [petsc-maint #80119] Re: make install broken on unix?
by Barry Smith 21 Jul '11

21 Jul '11

Brad. As a tmp fix I have changed the directory name to pythonscripts so your nightly tests should work again. Thanks for letting use know about the problem. Barry Barry- Your debugging info helped. The problem is that PETSc now wants to install PetscBinaryRead.py in $prefix/bin/python, but the python interpreter is also installed to $prefix/bin (we install everything we need for PyLith to $prefix) so $prefix/bin/python is the Python interpreter not a directory. Installing PetscBinaryRead.py to a directory called $prefix/bin/python seems like a bad idea to me. Brad On Jul 21, 2011, at 4:39 PM, Jed Brown wrote: > On Thu, Jul 21, 2011 at 14:37, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Maybe pythonscripts? > > Seems to me it should be installed like a proper python package, using a suitable setup.py. This usually puts it in $prefix/lib/python2.x/site-packages/.

1 0

Re: [petsc-dev] broken DMGetInterpolation_DA !!!!
by Barry Smith 21 Jul '11

21 Jul '11

On Jul 21, 2011, at 5:00 PM, Jed Brown wrote: > On Thu, Jul 21, 2011 at 14:48, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > Whoever wrote the DMGetInterpolation_DA_Q1() for when coordinates are provided in DA > > 1) it is completely broken for the periodic case! > > There is a serious semantic problem with periodic non-regular coordinates: we don't know how big the wrap element is. There is no way to determine this automatically, and there is no way to store it. So maybe generate an error message??? Producing the incorrect answer is not a good approach. > > > 2) it doesn't actually use the coordinates provided by the user in the DA ; it uses uniform coordinates it cooks up on the fly > > /* compute local coordinate arrays */ > nxi = ratioi + 1; > neta = ratioj + 1; > ierr = PetscMalloc(sizeof(PetscScalar)*nxi,&xi);CHKERRQ(ierr); > ierr = PetscMalloc(sizeof(PetscScalar)*neta,&eta);CHKERRQ(ierr); > for (li=0; li<nxi; li++) { > xi[li] = -1.0 + (PetscScalar)li*(2.0/(PetscScalar)(nxi-1)); > } > for (lj=0; lj<neta; lj++) { > eta[lj] = -1.0 + (PetscScalar)lj*(2.0/(PetscScalar)(neta-1)); > } > > These are reference coordinates. They get mapped using a Q1 local coordinate mapping. Dave wrote this code, but it was tested to give second order accuracy for non-uniform mapped grids. I completely do not understand the situation. In the code if (vcoors) { ierr = DMDAGetGhostedCoordinates(dac,&cvcoors);CHKERRQ(ierr); ierr = DMDAVecGetArray(ddf->da_coordinates,vcoors,&coors);CHKERRQ(ierr); ierr = DMDAVecGetArray(ddc->da_coordinates,cvcoors,&ccoors);CHKERRQ(ierr); } but the variable coors and ccoors are NEVER used in the routine! How can this routine supposedly support non-uniform mapped grids when the coordinates are never even taken into account? And why is ierr = DMDAVecGetArray(ddf->da_coordinates,vcoors,&coors);CHKERRQ(ierr); ierr = DMDAVecGetArray(ddc->da_coordinates,cvcoors,&ccoors);CHKERRQ(ierr); even called if the result is not used? What am I missing? > > Are you using non-uniform periodic grids? No, they are uniform. But I want to store the coordinates explicitly. > If you have regular periodic grids, but you still want to store coordinates explicitly, then we could write some special case to detect that you set coordinates that happened to be uniform, therefore we can guess that the wrap cell should also be uniform, and the code for no provided coordinates would be correct. What do you want to do?

1 0

Re: [petsc-dev] broken DMGetInterpolation_DA !!!!
by Jed Brown 21 Jul '11

21 Jul '11

On Thu, Jul 21, 2011 at 14:48, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > Whoever wrote the DMGetInterpolation_DA_Q1() for when coordinates are > provided in DA > > 1) it is completely broken for the periodic case! > There is a serious semantic problem with periodic non-regular coordinates: we don't know how big the wrap element is. There is no way to determine this automatically, and there is no way to store it. > > 2) it doesn't actually use the coordinates provided by the user in the DA > ; it uses uniform coordinates it cooks up on the fly > > /* compute local coordinate arrays */ > nxi = ratioi + 1; > neta = ratioj + 1; > ierr = PetscMalloc(sizeof(PetscScalar)*nxi,&xi);CHKERRQ(ierr); > ierr = PetscMalloc(sizeof(PetscScalar)*neta,&eta);CHKERRQ(ierr); > for (li=0; li<nxi; li++) { > xi[li] = -1.0 + (PetscScalar)li*(2.0/(PetscScalar)(nxi-1)); > } > for (lj=0; lj<neta; lj++) { > eta[lj] = -1.0 + (PetscScalar)lj*(2.0/(PetscScalar)(neta-1)); > } > These are reference coordinates. They get mapped using a Q1 local coordinate mapping. Dave wrote this code, but it was tested to give second order accuracy for non-uniform mapped grids. Are you using non-uniform periodic grids? If you have regular periodic grids, but you still want to store coordinates explicitly, then we could write some special case to detect that you set coordinates that happened to be uniform, therefore we can guess that the wrap cell should also be uniform, and the code for no provided coordinates would be correct. What do you want to do?

1 0

broken DMGetInterpolation_DA !!!!
by Barry Smith 21 Jul '11

21 Jul '11

Whoever wrote the DMGetInterpolation_DA_Q1() for when coordinates are provided in DA 1) it is completely broken for the periodic case! 2) it doesn't actually use the coordinates provided by the user in the DA ; it uses uniform coordinates it cooks up on the fly /* compute local coordinate arrays */ nxi = ratioi + 1; neta = ratioj + 1; ierr = PetscMalloc(sizeof(PetscScalar)*nxi,&xi);CHKERRQ(ierr); ierr = PetscMalloc(sizeof(PetscScalar)*neta,&eta);CHKERRQ(ierr); for (li=0; li<nxi; li++) { xi[li] = -1.0 + (PetscScalar)li*(2.0/(PetscScalar)(nxi-1)); } for (lj=0; lj<neta; lj++) { eta[lj] = -1.0 + (PetscScalar)lj*(2.0/(PetscScalar)(neta-1)); } so why does it even exist? Needless to say we are using the periodic boundary conditions and frustrated by the fact that it gives the wrong matrices. Tempted to rip out all the coordinate version of the interpolation cause I don't see it what it provides that the non-coordinate (the if (!vcoors) { branch of the code) provides and at least the non-coordinate version works for periodic boundary conditions. I know someone worked for a long time on the coordinate version but I don't know why. Is anyone willing to look at this? Barry

1 0

Re: [petsc-dev] Guidlines for migrating to dev version
by Sean Farley 20 Jul '11

20 Jul '11

> > Is there a written guideline somewhere for migrating from release version > to dev version? http://www.mcs.anl.gov/petsc/petsc-as/documentation/changes/dev.html Sean

1 0

Guidlines for migrating to dev version
by Ataollah Mesgarnejad 20 Jul '11

20 Jul '11

Dear all, Is there a written guideline somewhere for migrating from release version to dev version? Best, Ata

1 0

Re: [petsc-dev] [Fwd: Re: [petsc-users] PETSc recommended visualization packages]
by Satish Balay 19 Jul '11

19 Jul '11

pushed the patch to petsc-dev satish On Tue, 19 Jul 2011, Ethan Coon wrote: > Taking this to dev. > > Attached is a patch for PetscBinaryRead, which now has been tested on > Mat, IS, and Vec. Supports returning dense numpy.matrix, sparse CSR, > and scipy.sparse matrices (all have been tested). > > Also cc'ed Ata directly since I'm not sure he's on dev. Ata -- could > you please test the attached PetscBinaryRead.py for me on your system to > make sure I've correctly handled your version of numpy? Note that the > return format has changed from what you have now. Thanks. > > PetscBinaryWrite.py when I get to it... > > Thanks, > > Ethan > > -------- Forwarded Message -------- > From: Lisandro Dalcin <dalcinl(a)gmail.com> > Reply-to: PETSc users list <petsc-users(a)mcs.anl.gov> > To: PETSc users list <petsc-users(a)mcs.anl.gov> > Subject: Re: [petsc-users] PETSc recommended visualization packages > Date: Thu, 14 Jul 2011 19:34:42 -0300 > > On 14 July 2011 18:33, Ethan Coon <ecoon(a)lanl.gov> wrote: > > On Thu, 2011-07-14 at 17:47 -0300, Lisandro Dalcin wrote: > > > >> > >> 1) readMatDense() is wrong. The I,J,V arrays are the CSR structure, > >> not the COO (coordinate) format, Then you cannot simply: > >> > > > > Ok, thanks, I wasn't sure of which format you were using, > > Well, PETSc's AIJ matrices are CSR in memory (but not in disk, binary > files store row counts instead of row pointers) > > >> > >> 2) It would be nice to provie a 'scipy' Mat format returning a > >> 'scipy.sparse.csr_matrix' instance. A possible implementation would > >> be: > >> > > > > Agreed, I considered doing that as the default for sparse, but wasn't > > sure what others would want. Providing both makes sense. > > > > Note however that this would require a SciPy installation. > > PS: Sorry for not being more helpful and contributing actual code, but > I'm really busy. > > > >

1 0

[Fwd: Re: [petsc-users] PETSc recommended visualization packages]
by Ethan Coon 19 Jul '11

19 Jul '11

Taking this to dev. Attached is a patch for PetscBinaryRead, which now has been tested on Mat, IS, and Vec. Supports returning dense numpy.matrix, sparse CSR, and scipy.sparse matrices (all have been tested). Also cc'ed Ata directly since I'm not sure he's on dev. Ata -- could you please test the attached PetscBinaryRead.py for me on your system to make sure I've correctly handled your version of numpy? Note that the return format has changed from what you have now. Thanks. PetscBinaryWrite.py when I get to it... Thanks, Ethan -------- Forwarded Message -------- From: Lisandro Dalcin <dalcinl(a)gmail.com> Reply-to: PETSc users list <petsc-users(a)mcs.anl.gov> To: PETSc users list <petsc-users(a)mcs.anl.gov> Subject: Re: [petsc-users] PETSc recommended visualization packages Date: Thu, 14 Jul 2011 19:34:42 -0300 On 14 July 2011 18:33, Ethan Coon <ecoon(a)lanl.gov> wrote: > On Thu, 2011-07-14 at 17:47 -0300, Lisandro Dalcin wrote: > >> >> 1) readMatDense() is wrong. The I,J,V arrays are the CSR structure, >> not the COO (coordinate) format, Then you cannot simply: >> > > Ok, thanks, I wasn't sure of which format you were using, Well, PETSc's AIJ matrices are CSR in memory (but not in disk, binary files store row counts instead of row pointers) >> >> 2) It would be nice to provie a 'scipy' Mat format returning a >> 'scipy.sparse.csr_matrix' instance. A possible implementation would >> be: >> > > Agreed, I considered doing that as the default for sparse, but wasn't > sure what others would want. Providing both makes sense. > Note however that this would require a SciPy installation. PS: Sorry for not being more helpful and contributing actual code, but I'm really busy. -- ------------------------------------ Ethan Coon Post-Doctoral Researcher Applied Mathematics - T-5 Los Alamos National Laboratory 505-665-8289 http://www.ldeo.columbia.edu/~ecoon/ ------------------------------------

1 0

Re: [petsc-dev] This looks EXTREMELY nonportable to me
by Matthew Knepley 18 Jul '11

18 Jul '11

Okay, I see the PETSC_USE_PTHREAD_CLASSES guard. Large merge changesets are unhelpful for those trying to follow development. Matt On Tue, Jul 19, 2011 at 12:01 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > Who ever did this, please fix it: > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2ae64ecc368c > > 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 > -- 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

This looks EXTREMELY nonportable to me
by Matthew Knepley 18 Jul '11

18 Jul '11

Who ever did this, please fix it: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2ae64ecc368c 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