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

MUMPS and 64 bit indices
by Garth N. Wells 15 Dec '14

15 Dec '14

It's possible to configure PETSc with the options --with-64-bit-indices --download-mumps and compile and run, but it doesn't look like the MUMPS interface supports 64 bit indices. Should the above combination throw an error at configure time? (On a side note, SuperLU_dist and Umfpack are flaky with 64 bit indices, which seems largely related to calling ParMETIS/METIS). Garth

1 0

Re: [petsc-dev] More Fortran Interfaces
by Matthew Knepley 13 Dec '14

13 Dec '14

On Mon, Dec 8, 2014 at 4:00 AM, John O'Sullivan <jp.osullivan(a)auckland.ac.nz > wrote: > > Hi, > > I'm working with Adrian on our PetSc project at the University of > Auckland. I think I've found a couple more fortran interfaces that are > missing: > > DMPlexGetFaceFields > DMPlexGefFaceGeometry > > I get the error: > > Undefined symbols for architecture x86_64: > "_dmplexgetfacefields_", referenced from: > _rhs_darcy_local.2542 in darcy.o > "_dmplexgetfacegeometry_", referenced from: > _rhs_darcy_local.2542 in darcy.o > > I haven't got to the restore stage yet but I think probably these ones are > missing too: > > DMPlexRestoreFaceFields > DMPlexRestoreFaceGeometry > > Also I'm having trouble declaring a pointer to a PetscFVFaceGeom type to > use with the DMPlexGetFaceGeometry. Is there a trick to this or maybe its > definition in fortran is missing too? > Sorry, this is a really bad time of year for me with family and work travel. I can put in the Fortran bindings this week I think. I do not know how to handle structs in Fortran (will ask Fortran gurus). Right now, I am just going to make a PetscScalar array with one more dimension since the struct is a bunch of Scalars, and you will have to index into it treating the struct as another dim. Thanks, Matt > Thanks very much! > > Cheers > John > > *-- > **Dr John O'Sullivan > Lecturer > **Department of Engineering Science > **University of Auckland, New Zealand > **email: jp.osullivan at auckland.ac.nz <https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev> > **tel: +64 (0)9 923 85353* > > > -- 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

Re: [petsc-dev] More Fortran Interfaces
by John O'Sullivan 13 Dec '14

13 Dec '14

Hi guys, Just wondering if there's any news on the missing fortran interfaces? Thanks very much! John -- Dr John O'Sullivan Lecturer Department of Engineering Science University of Auckland, New Zealand email: jp.osullivan at auckland.ac.nz tel: +64 (0)9 923 85353 ________________________________________ From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of John O'Sullivan [jp.osullivan(a)auckland.ac.nz] Sent: Monday, 8 December 2014 11:00 p.m. To: petsc-dev(a)mcs.anl.gov Subject: [petsc-dev] More Fortran Interfaces Hi, I'm working with Adrian on our PetSc project at the University of Auckland. I think I've found a couple more fortran interfaces that are missing: DMPlexGetFaceFields DMPlexGefFaceGeometry I get the error: Undefined symbols for architecture x86_64: "_dmplexgetfacefields_", referenced from: _rhs_darcy_local.2542 in darcy.o "_dmplexgetfacegeometry_", referenced from: _rhs_darcy_local.2542 in darcy.o I haven't got to the restore stage yet but I think probably these ones are missing too: DMPlexRestoreFaceFields DMPlexRestoreFaceGeometry Also I'm having trouble declaring a pointer to a PetscFVFaceGeom type to use with the DMPlexGetFaceGeometry. Is there a trick to this or maybe its definition in fortran is missing too? Thanks very much! Cheers John -- Dr John O'Sullivan Lecturer Department of Engineering Science University of Auckland, New Zealand email: jp.osullivan at auckland.ac.nz<https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev> tel: +64 (0)9 923 85353

1 0

Re: [petsc-dev] Zero sized VecSetValues
by Barry Smith 13 Dec '14

13 Dec '14

Fixed > On Dec 13, 2014, at 12:35 PM, Pierre Jolivet <jolivet(a)ann.jussieu.fr> wrote: > > Hello Barry, > Thank you for the quick fix. > > On a completely unrelated note, in commit bbe210f1929f67cd37937d8e6757679d89b1c592 that you pushed to master recently, you introduced an unused variable Vec xx. > Now if I do a make check, I end up with the somehow misleading message > > *******************Error detected during compile or link!******************* > See http://www.mcs.anl.gov/petsc/documentation/faq.html > /mnt/space/SVN/petsc/src/snes/examples/tutorials ex19 > ********************************************************************************* > > because of -Wunused-variable. > > Could you please fix that ? > > Thank you in advance, > Pierre > > On 2014-12-13 05:50, Barry Smith wrote: >> Pierre, >> Please find attached a patch to fix this; after applying the patch do >> make gnumake >> in the root PETSc directory and relink your code. >> Thanks for reporting the problem >> Barry >>> On Dec 12, 2014, at 7:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> Pierre, >>> There is no rational, we will fix it. >>> Barry >>>> On Dec 12, 2014, at 11:47 AM, Pierre Jolivet <jolivet(a)ann.jussieu.fr> wrote: >>>> Hello, >>>> Taking http://www.mcs.anl.gov/petsc/petsc-current/src/vec/vec/examples/tutorials/e… and changing its 56th line from >>>> VecSetValues(x,1,&i,&one,ADD_VALUES); >>>> to >>>> VecSetValues(x,0,NULL,NULL,ADD_VALUES); >>>> yield the following error (at least --with-debug=1): >>>> [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- >>>> [0]PETSC ERROR: Invalid pointer >>>> [0]PETSC ERROR: Null Pointer: Parameter # 3 >>>> What is the rationale behind first checking the pointers, then doing the work or lack thereof, instead of, first checking if there is some work to do, and only then check the pointers (à la MPI) ? >>>> Thank you for your help, >>>> Pierre

1 0

Re: [petsc-dev] Zero sized VecSetValues
by Pierre Jolivet 13 Dec '14

13 Dec '14

Hello Barry, Thank you for the quick fix. On a completely unrelated note, in commit bbe210f1929f67cd37937d8e6757679d89b1c592 that you pushed to master recently, you introduced an unused variable Vec xx. Now if I do a make check, I end up with the somehow misleading message *******************Error detected during compile or link!******************* See http://www.mcs.anl.gov/petsc/documentation/faq.html /mnt/space/SVN/petsc/src/snes/examples/tutorials ex19 ********************************************************************************* because of -Wunused-variable. Could you please fix that ? Thank you in advance, Pierre On 2014-12-13 05:50, Barry Smith wrote: > Pierre, > > Please find attached a patch to fix this; after applying the patch > do > > make gnumake > > in the root PETSc directory and relink your code. > > Thanks for reporting the problem > > Barry > > >> On Dec 12, 2014, at 7:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> >> Pierre, >> >> There is no rational, we will fix it. >> >> Barry >> >> >>> On Dec 12, 2014, at 11:47 AM, Pierre Jolivet <jolivet(a)ann.jussieu.fr> >>> wrote: >>> >>> Hello, >>> Taking >>> http://www.mcs.anl.gov/petsc/petsc-current/src/vec/vec/examples/tutorials/e… >>> and changing its 56th line from >>> VecSetValues(x,1,&i,&one,ADD_VALUES); >>> to >>> VecSetValues(x,0,NULL,NULL,ADD_VALUES); >>> yield the following error (at least --with-debug=1): >>> [0]PETSC ERROR: --------------------- Error Message >>> -------------------------------------------------------------- >>> [0]PETSC ERROR: Invalid pointer >>> [0]PETSC ERROR: Null Pointer: Parameter # 3 >>> >>> What is the rationale behind first checking the pointers, then doing >>> the work or lack thereof, instead of, first checking if there is some >>> work to do, and only then check the pointers (à la MPI) ? >>> >>> Thank you for your help, >>> Pierre >>

1 0

Re: [petsc-dev] Zero sized VecSetValues
by Barry Smith 12 Dec '14

12 Dec '14

Pierre, Please find attached a patch to fix this; after applying the patch do make gnumake in the root PETSc directory and relink your code. Thanks for reporting the problem Barry > On Dec 12, 2014, at 7:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > Pierre, > > There is no rational, we will fix it. > > Barry > > >> On Dec 12, 2014, at 11:47 AM, Pierre Jolivet <jolivet(a)ann.jussieu.fr> wrote: >> >> Hello, >> Taking http://www.mcs.anl.gov/petsc/petsc-current/src/vec/vec/examples/tutorials/e… and changing its 56th line from >> VecSetValues(x,1,&i,&one,ADD_VALUES); >> to >> VecSetValues(x,0,NULL,NULL,ADD_VALUES); >> yield the following error (at least --with-debug=1): >> [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- >> [0]PETSC ERROR: Invalid pointer >> [0]PETSC ERROR: Null Pointer: Parameter # 3 >> >> What is the rationale behind first checking the pointers, then doing the work or lack thereof, instead of, first checking if there is some work to do, and only then check the pointers (à la MPI) ? >> >> Thank you for your help, >> Pierre >

1 0

Re: [petsc-dev] RegisterAllCalled visibility
by Barry Smith 12 Dec '14

12 Dec '14

> On Dec 12, 2014, at 7:55 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: >> That is just crappy engineering on our part. The RegisterAllCalled() >> should be idempotent just like PackageInitialize(). Does anyone >> disagree with this? > > I'm not sure it deserves to be a public interface. What is the use case > for XXRegisterAll() called from anywhere but XXInitializePackage? I don't see any reason for it to be public; it's publicity is probably an historical artifact from before XXXInitialize() existed. It can probably be made private and all the XXXRegisterAllCalled flags removed from the code? Plus the misleading text XXXRegisterAll() may be called several times could be removed? Toby, Since the only true way to understand something completely is to change it :-) do you want to make a pull request with these changes? :-) Barry

1 0

Re: [petsc-dev] RegisterAllCalled visibility
by Jed Brown 12 Dec '14

12 Dec '14

Matthew Knepley <knepley(a)gmail.com> writes: > That is just crappy engineering on our part. The RegisterAllCalled() > should be idempotent just like PackageInitialize(). Does anyone > disagree with this? I'm not sure it deserves to be a public interface. What is the use case for XXRegisterAll() called from anywhere but XXInitializePackage?

1 0

Re: [petsc-dev] Zero sized VecSetValues
by Barry Smith 12 Dec '14

12 Dec '14

Pierre, There is no rational, we will fix it. Barry > On Dec 12, 2014, at 11:47 AM, Pierre Jolivet <jolivet(a)ann.jussieu.fr> wrote: > > Hello, > Taking http://www.mcs.anl.gov/petsc/petsc-current/src/vec/vec/examples/tutorials/e… and changing its 56th line from > VecSetValues(x,1,&i,&one,ADD_VALUES); > to > VecSetValues(x,0,NULL,NULL,ADD_VALUES); > yield the following error (at least --with-debug=1): > [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- > [0]PETSC ERROR: Invalid pointer > [0]PETSC ERROR: Null Pointer: Parameter # 3 > > What is the rationale behind first checking the pointers, then doing the work or lack thereof, instead of, first checking if there is some work to do, and only then check the pointers (à la MPI) ? > > Thank you for your help, > Pierre

1 0

Re: [petsc-dev] RegisterAllCalled visibility
by Matthew Knepley 12 Dec '14

12 Dec '14

On Fri, Dec 12, 2014 at 12:43 PM, Tobin Isaac <tisaac(a)ices.utexas.edu> wrote: > > > Hi all, > > I'm trying to learn about PETSc's dynamic library framework. I've > noticed that XXXInitializePackage() routines are idempotent, but > XXXRegisterAll() routines are not, and usually have a visible > XXXRegisterAllCalled boolean to guard against multiple calls (but not > always). Then there are comments that say "In general, if there is > more than one DLL then XXXRegisterAll() may be called several times." > I don't understand the different handling between initialization and > registration, especially because the initialization routines generally > call the registration routines. Any help? > That is just crappy engineering on our part. The RegisterAllCalled() should be idempotent just like PackageInitialize(). Does anyone disagree with this? Thanks, Matt > Thanks, > Toby > -- 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