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

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Barry Smith 30 Mar '12

30 Mar '12

On Mar 30, 2012, at 11:07 AM, Lisandro Dalcin wrote: > On 30 March 2012 19:00, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >> On 30 March 2012 18:20, Blaise Bourdin <bourdin(a)lsu.edu> wrote: >>> >>> On Mar 30, 2012, at 10:13 AM, Jed Brown wrote: >>> >>> The PetscLayout is shared. It should probably not be allowed to change block >>> size after duplicating. >>> > > Actually, reading my previous reply, I did not expressed it well. I DO > AGREE with you that blocksizes should not be allowed to change once > set for first time. However, I think PETSc do have some code around > (in PC?) relying on this and unashamedly changing the bs of an INPUT > vector! If that was fixed, then we can disable changing bs for Vec. > But as long as we need to support this misfeature, at least let's try > to do better around the lines of my patch (BTW, I'm not sure how to > handle the blocked local to global mapping.... perhaps we can > reconstruct another one?) Let's locate all the code that changes the block size (after it is set) and eradicate it, then we won't need this bad patch. I think this can be done by having VecSetBlockSize() simple error out it if the map->bs != -1 and new block size not equals current block size. Barry > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] broken
by Peter Brune 30 Mar '12

30 Mar '12

Will push immediately. Note to self: test in something that isn't C++. - Peter On Fri, Mar 30, 2012 at 10:57 AM, Mark F. Adams <mark.adams(a)columbia.edu>wrote: > It looks like petsc-dev is broken: > > /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c: In function > 'SNESFASCycle_Additive': > /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c:573:5: error: > incompatible type for argument 2 of 'VecNorm' > /Users/markadams/Codes/petsc-dev/include/petscvec.h:221:24: note: expected > 'NormType' but argument is of type 'PetscReal *' > /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c:573:5: error: > too few arguments to function 'VecNorm' > /Users/markadams/Codes/petsc-dev/include/petscvec.h:221:24: note: declared > here > make[4]: *** [CMakeFiles/petsc.dir/src/snes/impls/fas/fas.c.o] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[3]: *** [CMakeFiles/petsc.dir/all] Error 2 > >

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Lisandro Dalcin 30 Mar '12

30 Mar '12

On 30 March 2012 19:00, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 30 March 2012 18:20, Blaise Bourdin <bourdin(a)lsu.edu> wrote: >> >> On Mar 30, 2012, at 10:13 AM, Jed Brown wrote: >> >> The PetscLayout is shared. It should probably not be allowed to change block >> size after duplicating. >> Actually, reading my previous reply, I did not expressed it well. I DO AGREE with you that blocksizes should not be allowed to change once set for first time. However, I think PETSc do have some code around (in PC?) relying on this and unashamedly changing the bs of an INPUT vector! If that was fixed, then we can disable changing bs for Vec. But as long as we need to support this misfeature, at least let's try to do better around the lines of my patch (BTW, I'm not sure how to handle the blocked local to global mapping.... perhaps we can reconstruct another one?) -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Lisandro Dalcin 30 Mar '12

30 Mar '12

On 30 March 2012 18:20, Blaise Bourdin <bourdin(a)lsu.edu> wrote: > > On Mar 30, 2012, at 10:13 AM, Jed Brown wrote: > > The PetscLayout is shared. It should probably not be allowed to change block > size after duplicating. > > I see... I had always been under the impression that VecDuplicate was just a > convenient shortcut. The documentation for VecDuplicate does not mention > that the Vecs share anything. Perhaps it should. > I do not agree with Jed. I think we have to apply the attached patch. The layout should be shared if it is possible, if it is not, create a new one. BTW, my patch includes a fix for PetscLayoutCopy not INCREFing the local to global mappings. PS: This patch is against petsc-3.2, if possible, please apply any bit of it to branch release-3.2 and merge in dev. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Mark F. Adams 30 Mar '12

30 Mar '12

Well, technically yes, but I'm guessing the there is a switch that detected happy breakdown or something ... don't know. On Mar 30, 2012, at 11:31 AM, Jed Brown wrote: > Min should also be 1, no? > > On Mar 30, 2012 9:26 AM, "Mark F. Adams" <mark.adams(a)columbia.edu> wrote: > I've had problems with GMRES and eigen estimates in the past but I now have a smoking gun. It seems that if you give GMRES an operator preconditioned with LU (ie, the preconditioned operator is the identity) GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a prefect max=1.0, min=0.0. > > Any thoughts? > > Mark

1 0

broken
by Mark F. Adams 30 Mar '12

30 Mar '12

It looks like petsc-dev is broken: /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c: In function 'SNESFASCycle_Additive': /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c:573:5: error: incompatible type for argument 2 of 'VecNorm' /Users/markadams/Codes/petsc-dev/include/petscvec.h:221:24: note: expected 'NormType' but argument is of type 'PetscReal *' /Users/markadams/Codes/petsc-dev/src/snes/impls/fas/fas.c:573:5: error: too few arguments to function 'VecNorm' /Users/markadams/Codes/petsc-dev/include/petscvec.h:221:24: note: declared here make[4]: *** [CMakeFiles/petsc.dir/src/snes/impls/fas/fas.c.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [CMakeFiles/petsc.dir/all] Error 2

1 0

Re: [petsc-dev] GMRES and eigen estimates
by Jed Brown 30 Mar '12

30 Mar '12

Min should also be 1, no? On Mar 30, 2012 9:26 AM, "Mark F. Adams" <mark.adams(a)columbia.edu> wrote: > I've had problems with GMRES and eigen estimates in the past but I now > have a smoking gun. It seems that if you give GMRES an operator > preconditioned with LU (ie, the preconditioned operator is the identity) > GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a > prefect max=1.0, min=0.0. > > Any thoughts? > > Mark

1 0

GMRES and eigen estimates
by Mark F. Adams 30 Mar '12

30 Mar '12

I've had problems with GMRES and eigen estimates in the past but I now have a smoking gun. It seems that if you give GMRES an operator preconditioned with LU (ie, the preconditioned operator is the identity) GMRES gives me a highest eigen estimate of ~10 (way off). With CG I get a prefect max=1.0, min=0.0. Any thoughts? Mark

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Blaise Bourdin 30 Mar '12

30 Mar '12

On Mar 30, 2012, at 10:13 AM, Jed Brown wrote: > The PetscLayout is shared. It should probably not be allowed to change block size after duplicating. > I see... I had always been under the impression that VecDuplicate was just a convenient shortcut. The documentation for VecDuplicate does not mention that the Vecs share anything. Perhaps it should. On a different topic, is there a way to generate the xdmf description with the hdf5 viewer? Blaise > On Mar 30, 2012 9:02 AM, "Blaise Bourdin" <bourdin(a)lsu.edu> wrote: > Hi, > > I am trying to make use of the more advanced features of the hdf5 viewer. > > I get the following error when running src/vec/vec/examples/tutorials/ex19.c: > [0]PETSC ERROR: VecLoad_HDF5() line 251 in /opt/HPC/petsc-dev/src/vec/vec/utils/vecio.c Block size 1 specified for vector does not match blocksize in file 2 > > Upon further investigating, I noticed that if Vec x2 is obtained by duplicating x1, then setting the block size for x2 also sets it for x1. Is this really the desired behavior? > > I am attaching an trivial example. > > Blaise > > > > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin > > > > > > > > -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Re: [petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize
by Jed Brown 30 Mar '12

30 Mar '12

The PetscLayout is shared. It should probably not be allowed to change block size after duplicating. On Mar 30, 2012 9:02 AM, "Blaise Bourdin" <bourdin(a)lsu.edu> wrote: > Hi, > > I am trying to make use of the more advanced features of the hdf5 viewer. > > I get the following error when running > src/vec/vec/examples/tutorials/ex19.c: > [0]PETSC ERROR: VecLoad_HDF5() line 251 in > /opt/HPC/petsc-dev/src/vec/vec/utils/vecio.c Block size 1 specified for > vector does not match blocksize in file 2 > > Upon further investigating, I noticed that if Vec x2 is obtained by > duplicating x1, then setting the block size for x2 also sets it for x1. Is > this really the desired behavior? > > I am attaching an trivial example. > > Blaise > > > > > -- > Department of Mathematics and Center for Computation & Technology > Louisiana State University, Baton Rouge, LA 70803, USA > Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 > http://www.math.lsu.edu/~bourdin > > > > > > > > >

1 0