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

Error in code documentation?
by Eric Chamberland 30 Nov '16

30 Nov '16

Hi, is there an error in code documentation in pvecimpl.h: typedef struct { VECHEADER PetscInt nghost; /* length of local portion including ghost padding */ isn't "nghost" the length of ghost padding only? Thanks, eric

1 0

Re: [petsc-dev] Bug in PCSetUp_FieldSplit/PCReset_FieldSplit
by Sander Arens 28 Nov '16

28 Nov '16

Barry, The branch resolves the difficulties. Sorry for the sloppy code, it was just a quick fix to illustrate something. Had I known you were going to use it as a patch I would have tested it more thoroughly. Thanks, Sander On 26 November 2016 at 06:02, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Sander, > > Thanks for the patch, I have put it into the branch > barry/Sander/fix-pcreset-fieldsplit and confirmed that it does > support reset (after fixing some bugs) and merged it into next for > testing. Can you try it and see if it resolves the difficulties you were > having? > > Barry > > Before submitting patches you should try the test codes with -malloc_test > or under valgrind, you would have found some memory leaks due to bugs in > your patch and from those found the bugs in the patch you sent. > > > > On Nov 22, 2016, at 3:10 AM, Sander Arens <Sander.Arens(a)UGent.be> wrote: > > > > It works now for the particular case when there's a SNESReset before a > SNESSolve, but when you put a SNESReset and SNESSolve again after the first > SNESSolve it breaks again (I noticed this first playing around with > TSArkimex when it broke at this line). > > > > Destroying the fieldsplit linked list in PCReset_FieldSplit seemed to > work (see diff file)... > > > > On 21 November 2016 at 21:02, Matthew Knepley <knepley(a)gmail.com> wrote: > > Okay, try out the fix in next. > > > > Thanks, > > > > Matt > > > > On Thu, Nov 17, 2016 at 3:11 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > > On Thu, Nov 17, 2016 at 1:22 PM, Sander Arens <Sander.Arens(a)ugent.be> > wrote: > > I think there's a bug in PCSetUp_FieldSplit or PCReset_FieldSplit. I can > get this by putting a SNESReset before the SNESSolve in snes ex77 and > running ./config/builder2.py check src/snes/examples/tutorials/ex77.c. > Can somebody reproduce this? > > > > You are right. Fixing... > > > > Matt > > > > Thanks, > > Sander > > > > > > > > -- > > 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 > > > > <fieldsplit.diff> > >

1 0

Re: [petsc-dev] Bug in PCSetUp_FieldSplit/PCReset_FieldSplit
by Barry Smith 25 Nov '16

25 Nov '16

Sander, Thanks for the patch, I have put it into the branch barry/Sander/fix-pcreset-fieldsplit and confirmed that it does support reset (after fixing some bugs) and merged it into next for testing. Can you try it and see if it resolves the difficulties you were having? Barry Before submitting patches you should try the test codes with -malloc_test or under valgrind, you would have found some memory leaks due to bugs in your patch and from those found the bugs in the patch you sent. > On Nov 22, 2016, at 3:10 AM, Sander Arens <Sander.Arens(a)UGent.be> wrote: > > It works now for the particular case when there's a SNESReset before a SNESSolve, but when you put a SNESReset and SNESSolve again after the first SNESSolve it breaks again (I noticed this first playing around with TSArkimex when it broke at this line). > > Destroying the fieldsplit linked list in PCReset_FieldSplit seemed to work (see diff file)... > > On 21 November 2016 at 21:02, Matthew Knepley <knepley(a)gmail.com> wrote: > Okay, try out the fix in next. > > Thanks, > > Matt > > On Thu, Nov 17, 2016 at 3:11 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Thu, Nov 17, 2016 at 1:22 PM, Sander Arens <Sander.Arens(a)ugent.be> wrote: > I think there's a bug in PCSetUp_FieldSplit or PCReset_FieldSplit. I can get this by putting a SNESReset before the SNESSolve in snes ex77 and running ./config/builder2.py check src/snes/examples/tutorials/ex77.c. Can somebody reproduce this? > > You are right. Fixing... > > Matt > > Thanks, > Sander > > > > -- > 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 > > <fieldsplit.diff>

1 0

Re: [petsc-dev] MatSetValues (Fortran)
by Barry Smith 22 Nov '16

22 Nov '16

We'll support this in a few days but for now just use PetscScalar :: m(1) instead of PetscScalar :: m(1,1) > On Nov 22, 2016, at 8:37 PM, Tabrez Ali <stali(a)geology.wisc.edu> wrote: > > Yes, that was the complete message (GNU FC). I am attaching a test case. > > Tabrez > > On 11/22/2016 07:51 PM, Satish Balay wrote: >> It will also work if you use MatSetValues11() or MatSetValues1n() - >> but then - you will be using F77 mode of calling that routine - and >> bypassing the f90 interface definition [that supporsedly provides type >> checks] >> >> It would be good to figure out whats hapenning here. Is what you sent >> the complete error message? How about a minimal code snippet that we >> can compile to reproduce the error? >> >> Satish >> >> On Tue, 22 Nov 2016, Tabrez Ali wrote: >> >>> Hello Satish >>> >>> It works fine if I use MatSetValues0 instead of MatSetValues. >>> >>> Tabrez >>> >>> On 11/22/2016 07:25 PM, Satish Balay wrote: >>>> f90 interface definitions for MatSetValues were added. So if you are >>>> including petscmat.h90 - there should interface check by the compiler. >>>> >>>> https://bitbucket.org/petsc/petsc/commits/4d03fd2beba63756fb8890bf1826f747a… >>>> >>>> Looks like this check is failing. Does the compiler print more info on >>>> why it didn't find a match? >>>> >>>> Or is the compiler complaining about using MatSetValues0 - instead of >>>> MatSetValues here? >>>> >>>> https://bitbucket.org/petsc/petsc/commits/3b494cfec78d3366d5cde5f82eed4f6ae… >>>> >>>> If you can reproduce this in a test code - that would help. >>>> >>>> Satish >>>> >>>> On Tue, 22 Nov 2016, Tabrez Ali wrote: >>>> >>>>> Hello >>>>> >>>>> I am using petsc-dev and today I got the following error (below) while >>>>> compiling the code. I guess this has to do with the Fortran interfaces but >>>>> I >>>>> cannot spot what's wrong. Any ideas? >>>>> >>>>> Tabrez >>>>> >>>>> /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 >>>>> -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include >>>>> -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include >>>>> -o main.o main.F90 >>>>> main.F90:177:75: >>>>> >>>>> call >>>>> MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) >>>>> 1 >>>>> Error: There is no specific subroutine for the generic ‘matsetvalues’ at >>>>> (1) >>>>> >>>>> >>> >>> > > <test.F90>

1 0

Re: [petsc-dev] MatSetValues (Fortran)
by Tabrez Ali 22 Nov '16

22 Nov '16

Yes, that was the complete message (GNU FC). I am attaching a test case. Tabrez On 11/22/2016 07:51 PM, Satish Balay wrote: > It will also work if you use MatSetValues11() or MatSetValues1n() - > but then - you will be using F77 mode of calling that routine - and > bypassing the f90 interface definition [that supporsedly provides type > checks] > > It would be good to figure out whats hapenning here. Is what you sent > the complete error message? How about a minimal code snippet that we > can compile to reproduce the error? > > Satish > > On Tue, 22 Nov 2016, Tabrez Ali wrote: > >> Hello Satish >> >> It works fine if I use MatSetValues0 instead of MatSetValues. >> >> Tabrez >> >> On 11/22/2016 07:25 PM, Satish Balay wrote: >>> f90 interface definitions for MatSetValues were added. So if you are >>> including petscmat.h90 - there should interface check by the compiler. >>> >>> https://bitbucket.org/petsc/petsc/commits/4d03fd2beba63756fb8890bf1826f747a… >>> >>> Looks like this check is failing. Does the compiler print more info on >>> why it didn't find a match? >>> >>> Or is the compiler complaining about using MatSetValues0 - instead of >>> MatSetValues here? >>> >>> https://bitbucket.org/petsc/petsc/commits/3b494cfec78d3366d5cde5f82eed4f6ae… >>> >>> If you can reproduce this in a test code - that would help. >>> >>> Satish >>> >>> On Tue, 22 Nov 2016, Tabrez Ali wrote: >>> >>>> Hello >>>> >>>> I am using petsc-dev and today I got the following error (below) while >>>> compiling the code. I guess this has to do with the Fortran interfaces but >>>> I >>>> cannot spot what's wrong. Any ideas? >>>> >>>> Tabrez >>>> >>>> /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 >>>> -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include >>>> -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include >>>> -o main.o main.F90 >>>> main.F90:177:75: >>>> >>>> call >>>> MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) >>>> 1 >>>> Error: There is no specific subroutine for the generic ‘matsetvalues’ at >>>> (1) >>>> >>>> >> >>

1 0

Re: [petsc-dev] MatSetValues (Fortran)
by Satish Balay 22 Nov '16

22 Nov '16

It will also work if you use MatSetValues11() or MatSetValues1n() - but then - you will be using F77 mode of calling that routine - and bypassing the f90 interface definition [that supporsedly provides type checks] It would be good to figure out whats hapenning here. Is what you sent the complete error message? How about a minimal code snippet that we can compile to reproduce the error? Satish On Tue, 22 Nov 2016, Tabrez Ali wrote: > Hello Satish > > It works fine if I use MatSetValues0 instead of MatSetValues. > > Tabrez > > On 11/22/2016 07:25 PM, Satish Balay wrote: > > f90 interface definitions for MatSetValues were added. So if you are > > including petscmat.h90 - there should interface check by the compiler. > > > > https://bitbucket.org/petsc/petsc/commits/4d03fd2beba63756fb8890bf1826f747a… > > > > Looks like this check is failing. Does the compiler print more info on > > why it didn't find a match? > > > > Or is the compiler complaining about using MatSetValues0 - instead of > > MatSetValues here? > > > > https://bitbucket.org/petsc/petsc/commits/3b494cfec78d3366d5cde5f82eed4f6ae… > > > > If you can reproduce this in a test code - that would help. > > > > Satish > > > > On Tue, 22 Nov 2016, Tabrez Ali wrote: > > > > > Hello > > > > > > I am using petsc-dev and today I got the following error (below) while > > > compiling the code. I guess this has to do with the Fortran interfaces but > > > I > > > cannot spot what's wrong. Any ideas? > > > > > > Tabrez > > > > > > /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 > > > -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include > > > -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include > > > -o main.o main.F90 > > > main.F90:177:75: > > > > > > call > > > MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) > > > 1 > > > Error: There is no specific subroutine for the generic ‘matsetvalues’ at > > > (1) > > > > > > > > >

1 0

Re: [petsc-dev] MatSetValues (Fortran)
by Tabrez Ali 22 Nov '16

22 Nov '16

Hello Satish It works fine if I use MatSetValues0 instead of MatSetValues. Tabrez On 11/22/2016 07:25 PM, Satish Balay wrote: > f90 interface definitions for MatSetValues were added. So if you are > including petscmat.h90 - there should interface check by the compiler. > > https://bitbucket.org/petsc/petsc/commits/4d03fd2beba63756fb8890bf1826f747a… > > Looks like this check is failing. Does the compiler print more info on > why it didn't find a match? > > Or is the compiler complaining about using MatSetValues0 - instead of > MatSetValues here? > > https://bitbucket.org/petsc/petsc/commits/3b494cfec78d3366d5cde5f82eed4f6ae… > > If you can reproduce this in a test code - that would help. > > Satish > > On Tue, 22 Nov 2016, Tabrez Ali wrote: > >> Hello >> >> I am using petsc-dev and today I got the following error (below) while >> compiling the code. I guess this has to do with the Fortran interfaces but I >> cannot spot what's wrong. Any ideas? >> >> Tabrez >> >> /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 >> -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include >> -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include >> -o main.o main.F90 >> main.F90:177:75: >> >> call MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) >> 1 >> Error: There is no specific subroutine for the generic ‘matsetvalues’ at (1) >> >>

1 0

Re: [petsc-dev] MatSetValues (Fortran)
by Satish Balay 22 Nov '16

22 Nov '16

f90 interface definitions for MatSetValues were added. So if you are including petscmat.h90 - there should interface check by the compiler. https://bitbucket.org/petsc/petsc/commits/4d03fd2beba63756fb8890bf1826f747a… Looks like this check is failing. Does the compiler print more info on why it didn't find a match? Or is the compiler complaining about using MatSetValues0 - instead of MatSetValues here? https://bitbucket.org/petsc/petsc/commits/3b494cfec78d3366d5cde5f82eed4f6ae… If you can reproduce this in a test code - that would help. Satish On Tue, 22 Nov 2016, Tabrez Ali wrote: > Hello > > I am using petsc-dev and today I got the following error (below) while > compiling the code. I guess this has to do with the Fortran interfaces but I > cannot spot what's wrong. Any ideas? > > Tabrez > > /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 > -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include > -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include > -o main.o main.F90 > main.F90:177:75: > > call MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) > 1 > Error: There is no specific subroutine for the generic ‘matsetvalues’ at (1) > >

1 0

MatSetValues (Fortran)
by Tabrez Ali 22 Nov '16

22 Nov '16

Hello I am using petsc-dev and today I got the following error (below) while compiling the code. I guess this has to do with the Fortran interfaces but I cannot spot what's wrong. Any ideas? Tabrez /opt/mpich3/bin/mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g -I/home/stali/petsc-dev/include -I/home/stali/petsc-dev/arch-linux2-c-debug/include -I/opt/mpich3/include -o main.o main.F90 main.F90:177:75: call MatSetValues(Mat_K,ef_eldof,indx,ef_eldof,indx,k,Add_Values,ierr) 1 Error: There is no specific subroutine for the generic ‘matsetvalues’ at (1)

1 0

Re: [petsc-dev] Bug in PCSetUp_FieldSplit/PCReset_FieldSplit
by Sander Arens 22 Nov '16

22 Nov '16

It works now for the particular case when there's a SNESReset before a SNESSolve, but when you put a SNESReset and SNESSolve again after the first SNESSolve it breaks again (I noticed this first playing around with TSArkimex when it broke at this line <https://bitbucket.org/petsc/petsc/src/7538c81a3e5819d80e753a9b491da681486bd…> ). Destroying the fieldsplit linked list in PCReset_FieldSplit seemed to work (see diff file)... On 21 November 2016 at 21:02, Matthew Knepley <knepley(a)gmail.com> wrote: > Okay, try out the fix in next. > > Thanks, > > Matt > > On Thu, Nov 17, 2016 at 3:11 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > >> On Thu, Nov 17, 2016 at 1:22 PM, Sander Arens <Sander.Arens(a)ugent.be> >> wrote: >> >>> I think there's a bug in PCSetUp_FieldSplit or PCReset_FieldSplit. I can >>> get this by putting a SNESReset before the SNESSolve in snes ex77 and >>> running ./config/builder2.py check src/snes/examples/tutorials/ex77.c. >>> Can somebody reproduce this? >>> >> >> You are right. Fixing... >> >> Matt >> >> >>> Thanks, >>> Sander >>> >> >> >> >> -- >> 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