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

lazygit
by Lisandro Dalcin 20 Mar '20

20 Mar '20

Folks, I recommend this terminal-based UI for git: https://opensource.com/article/20/3/lazygit It is quite easy to do line-level stage, amend, rebase, fixup/squash, cherry-pick, etc. all without leaving the terminal. In https://github.com/jesseduffield/lazygit/releases, you can download a statically-linked binary (a bit heavy, ~ 15MB), just drop it in your ~/bin or ~/.local/bin, and you are ready to go. Profit! -- Lisandro Dalcin ============ Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

1 0

Re: [petsc-dev] Unions of IS and MatNest
by Matthew Knepley 19 Mar '20

19 Mar '20

On Fri, Mar 13, 2020 at 11:20 AM Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> wrote: > > > On 13 Mar 2020, at 2:36 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Fri, Mar 13, 2020 at 3:19 AM Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> > wrote: > >> >> >> On 12 Mar 2020, at 11:40 PM, Matthew Knepley <knepley(a)gmail.com> wrote: >> >> On Thu, Mar 12, 2020 at 5:59 PM Jed Brown <jed(a)jedbrown.org> wrote: >> >>> Pierre Jolivet <pierre.jolivet(a)enseeiht.fr> writes: >>> >>> > Hello, >>> > Has there been any follow-up on this >>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html >>> < >>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/024020.html >>> >? >>> > Given a 3x3 MatNest A = [A_00,0,0 ; 0,A_11,0 ; 0,0,A_22], I’d like to >>> setup a two-way fieldsplit coupling [A_00,0 ; 0,A_11] and [A_22] but I >>> can’t figure out the proper options. >>> >>> Are you looking for a Schur split or additive/multiplicative? >> >> >> Don’t know yet which will perform best, do you have a specific solution >> in mind for one scenario or the other? >> I was mostly wondering if it was possible in a general context, not >> taking -pc_fieldsplit_type into account. >> >> -pc_fieldsplit_field_0 0,1 -pc_fieldsplit_field_1 2 -pc_fieldsplit_type >> schur >> >> >> These flags, used with my .cpp, yield: >> [0]PETSC ERROR: Arguments are incompatible >> [0]PETSC ERROR: To use Schur complement preconditioner you must have >> exactly 2 fields >> If I use -pc_fieldsplit_%d_fields <a,b,..> as advocated in the manual >> (instead of -pc_fieldsplit_field_%d as you suggested), I get the same error. >> > > Okay it is -pc_fieldsplit_%d_fields. When you use this, how many fields > does it think you have? > > > Three. > In case it’s not clear, the MWE is at the bottom of my first email > (nest.cpp). > $ mpicxx nest.cpp -I$PETSC_DIR/$PETSC_ARCH/include -I$PETSC_DIR/include > -L$PETSC_DIR/$PETSC_ARCH/lib -lpetsc > $ ./a.out -pc_type fieldsplit -pc_fieldsplit_0_fields 0,1 > -pc_fieldsplit_1_fields 2 -pc_fieldsplit_type schur > […] > [0]PETSC ERROR: Arguments are incompatible > [0]PETSC ERROR: To use Schur complement preconditioner you must have > exactly 2 fields > […] > Split info: > Split number 0 Defined by IS > Split number 1 Defined by IS > Split number 2 Defined by IS > […] > I see now. If you call PCFieldsplitSetIS(), this overrides anything else. We do not even try to discover the split. If you want a split determined by command line arguments, you have to defer the split. It looks like it can get splits from the MatNest, so just do not call SetIS(). Thanks, Matt > Thanks, > Pierre > > Matt > >> I believe. >> >> Matt >> >> >>> > Jed, in this answer >>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html >>> < >>> https://lists.mcs.anl.gov/pipermail/petsc-users/2015-January/023993.html>, >>> you recommend not to use MatNest. What would you recommend instead? >>> >>> See src/snes/examples/tutorials/ex28.c for my preferred approach. >> >> >> I’m not using DM, so in terms of Mat, I guess this example shows that I >> pretty much need to reimplement the field splitting myself? >> >> Thanks, >> Pierre >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ >> <http://www.cse.buffalo.edu/~knepley/> >> >> >> > > -- > 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 > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> > > > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Mark Adams 17 Mar '20

17 Mar '20

OK, so we could check if (obj==FORTRAN_TYPE_INITIALIZE) .... and remove all of our initializations. And then MatCreateVecs should work. On Tue, Mar 17, 2020 at 3:52 PM Satish Balay <balay(a)mcs.anl.gov> wrote: > Ah - found it. So PETSc is doing this initialization for you. > > config/BuildSystem/config/compilersFortran.py: > help.addArgument('Compilers', '-with-fortran-type-initialize=<bool>', > nargs.ArgBool(None, 1, 'Initialize PETSc objects in Fortran')) > config/BuildSystem/config/compilersFortran.py: > self.addDefine('FORTRAN_TYPE_INITIALIZE', ' = -2') > src/vec/f90-mod/petscvec.h: PetscFortranAddr:: v > PETSC_FORTRAN_TYPE_INITIALIZE > > Satish > > On Tue, 17 Mar 2020, Satish Balay wrote: > > > The issue is: > > > > C has: > > > > Vec v=NULL; > > Vec *v=NULL; > > > > However its not clear how to implement this with current f90 interface. > > > > I think we currently have: > > > > Vec v = PETSC_NULL_VEC = 0 => the second one. > > > > What you are looking for is the first one. I see this is automatically > > set. I don't see this initialization in petsc - so perhaps the > > compiler is doing this automatically? [atleast by gfortran] > > > > Satish > > > > ------------- > > > > Breakpoint 2, MAIN__ () at ex1f.F90:51 > > 51 x = PETSC_NULL_VEC > > (gdb) list 33 > > 28 ! > > 29 Vec x,b,u > > 30 Mat A > > 31 KSP ksp > > 32 PC pc > > 33 PetscReal norm,tol > > 34 PetscErrorCode ierr > > 35 PetscInt i,n,col(3),its,i1,i2,i3 > > 36 PetscBool flg > > 37 PetscMPIInt size > > (gdb) p x > > $2 = ( v = -2 ) > > (gdb) p b > > $3 = ( v = -2 ) > > (gdb) p u > > $4 = ( v = -2 ) > > (gdb) p A > > $5 = ( v = -2 ) > > (gdb) p ksp > > $6 = ( v = -2 ) > > (gdb) p pc > > $7 = ( v = -2 ) > > (gdb) c > > Continuing. > > > > Breakpoint 3, MAIN__ () at ex1f.F90:52 > > 52 call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr) > > (gdb) p x > > $8 = ( v = 0 ) > > (gdb) > > > > > > > > On Tue, 17 Mar 2020, Mark Adams wrote: > > > > > > > > > > Passing NULL to MatCreateVecs() means that you do not want a vector > out: > > > > > > > > > > > Yes, I want both vectors out and we pass it Vec that have been > initialized > > > with PETSC_NULL_VEC > > > > > > > > > > > > > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… > > > > > > > > I am guessing that this was broken in 3.7 so that it ignored NULL > input, > > > > but we fixed that. > > > > > > > > > > > v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code > > > > > > ex73f90t does not initialize the "x" vector that it gives > > > to matcreatevecs_. Should we just remove initialization of our vectors > to > > > PETSC_NUILL_VEC? > > > > > > Is the PETSc model that you don't inialized PETSc object to NULL > because > > > you check that pointers are valid PETSc pointers instead of testing on > > > NULL? So maybe we should remove all these initializations. > > > > > > Thanks, > > > Mark > > > > > > > > > > Thanks, > > > > > > > > Matt > > > > > > > > > > > >> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > > > >> > > > >> Petsc code: > > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec > *right,Vec > > > >> *left, int *ierr) > > > >> { > > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p > > > >> left=%p\n",right,left); > > > >> CHKFORTRANNULLOBJECT(right); > > > >> CHKFORTRANNULLOBJECT(left); > > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p > > > >> left=%p\n",right,left); > > > >> *ierr = MatCreateVecs(*mat,right,left); > > > >> } > > > >> > > > >> produces this: > > > >> > > > >> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 > > > >> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) > > > >> > > > >> Shouldn't this be? > > > >> > > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec > *right,Vec > > > >> *left, int *ierr) > > > >> { > > > >> *ierr = MatCreateVecs(*mat,right,left); > > > >> } > > > >> > > > >> > > > > > > > > -- > > > > 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 > > > > > > > > https://www.cse.buffalo.edu/~knepley/ > > > > <http://www.cse.buffalo.edu/~knepley/> > > > > > > > > > > > > >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Mark Adams 17 Mar '20

17 Mar '20

OK, I misspoke. We do use these x/bVec2 Vecs in our code sometimes. So PETSc did change from v3.7 (Albert and I have been chasing this down for a week). I don't understand why but we have been building the same code base with v3.7 and maint all week. It looks to me like optional pointer return arguments are not going to work in Fortran and we need to work around it. On Tue, Mar 17, 2020 at 3:09 PM Mark Adams <mfadams(a)lbl.gov> wrote: > I see what is happening. I think. We have: > > call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > call VecDuplicate(solver%bVec2,solver%rVec2,ierr) > > Well it turns out that [x|b]Vec2 are used only in debugging code that is > turned off. rVec2 is only used in a SNESSetFunction call. > > What we see in the code is that this call to VecDuplicate throws an error, > which we do not catch, in the current PETSc but is silent in v3.7.7. > Unless MatCreateVecs does create bVec2 in v3.7 (ie, CHKFORTRANNULLOBJECT did > not null it out back then, which BTW is not a great side effect of a "CHK" > macro IHMO). > > So we are are seeing a bunch of error messages but the code chugs along > after that, for a while. We do get another error eventually, that was a > NULL Vec as I recall. I am guessing that SNESSetFunction does not like to > get a NULL vector, but we will have to move on to debugging that. > (Did SNESSetFunction require a non-null vector since v3.7?) > > Thanks, > Mark > > > On Tue, Mar 17, 2020 at 2:52 PM Matthew Knepley <knepley(a)gmail.com> wrote: > >> On Tue, Mar 17, 2020 at 2:48 PM Mark Adams <mfadams(a)lbl.gov> wrote: >> >>> >>> >>> On Tue, Mar 17, 2020 at 2:25 PM Matthew Knepley <knepley(a)gmail.com> >>> wrote: >>> >>>> On Tue, Mar 17, 2020 at 2:16 PM Mark Adams <mfadams(a)lbl.gov> wrote: >>>> >>>>> >>>>> >>>>>> Passing NULL to MatCreateVecs() means that you do not want a vector >>>>>> out: >>>>>> >>>>>> >>>>> Yes, I want both vectors out and we pass it Vec that have been >>>>> initialized with PETSC_NULL_VEC >>>>> >>>> >>>> That is wrong. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… >>>>>> >>>>>> I am guessing that this was broken in 3.7 so that it ignored NULL >>>>>> input, but we fixed that. >>>>>> >>>>>> >>>>> v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code >>>>> >>>> >>>> How could v3.7 have the check? If so, you code would be broken. >>>> >>> >>> Barry did it 12 years ago: >>> >>> >>> https://gitlab.com/petsc/petsc/-/commit/7c54600c425fb8d0ad4ad4bb40f7fac17c9… >>> >> >> What you are saying does not make sense. You are saying: >> >> 1) We are passing in NULL Vec objects >> >> 2) Barry put in code to check for such objects >> >> 3) We are getting valid Vec objects back >> >> One of those statement is not true >> >> Thanks, >> >> Matt >> >> >>> >>>> >>>>> ex73f90t does not initialize the "x" vector that it gives >>>>> to matcreatevecs_. Should we just remove initialization of our vectors to >>>>> PETSC_NUILL_VEC? >>>>> >>>> >>>> Yes. >>>> >>>> >>>>> Is the PETSc model that you don't inialized PETSc object to NULL >>>>> because you check that pointers are valid PETSc pointers instead of testing >>>>> on NULL? So maybe we should remove all these initializations. >>>>> >>>> >>>> I am not sure what you are asking here. >>>> >>> >>> That we should not initialize our PETSc Vec,Mat,etc. with some sort of >>> NULL. I am sure this is the case. >>> >>> >>>> >>>> Matt >>>> >>>> >>>>> Thanks, >>>>> Mark >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>>> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) >>>>>>> >>>>>>> Petsc code: >>>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec >>>>>>> *right,Vec *left, int *ierr) >>>>>>> { >>>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p >>>>>>> left=%p\n",right,left); >>>>>>> CHKFORTRANNULLOBJECT(right); >>>>>>> CHKFORTRANNULLOBJECT(left); >>>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p >>>>>>> left=%p\n",right,left); >>>>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>>>> } >>>>>>> >>>>>>> produces this: >>>>>>> >>>>>>> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 >>>>>>> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) >>>>>>> >>>>>>> Shouldn't this be? >>>>>>> >>>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec >>>>>>> *right,Vec *left, int *ierr) >>>>>>> { >>>>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>>>> } >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> https://www.cse.buffalo.edu/~knepley/ >>>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>>> >>>>> >>>> >>>> -- >>>> 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 >>>> >>>> https://www.cse.buffalo.edu/~knepley/ >>>> <http://www.cse.buffalo.edu/~knepley/> >>>> >>> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ >> <http://www.cse.buffalo.edu/~knepley/> >> >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Satish Balay 17 Mar '20

17 Mar '20

Ah - found it. So PETSc is doing this initialization for you. config/BuildSystem/config/compilersFortran.py: help.addArgument('Compilers', '-with-fortran-type-initialize=<bool>', nargs.ArgBool(None, 1, 'Initialize PETSc objects in Fortran')) config/BuildSystem/config/compilersFortran.py: self.addDefine('FORTRAN_TYPE_INITIALIZE', ' = -2') src/vec/f90-mod/petscvec.h: PetscFortranAddr:: v PETSC_FORTRAN_TYPE_INITIALIZE Satish On Tue, 17 Mar 2020, Satish Balay wrote: > The issue is: > > C has: > > Vec v=NULL; > Vec *v=NULL; > > However its not clear how to implement this with current f90 interface. > > I think we currently have: > > Vec v = PETSC_NULL_VEC = 0 => the second one. > > What you are looking for is the first one. I see this is automatically > set. I don't see this initialization in petsc - so perhaps the > compiler is doing this automatically? [atleast by gfortran] > > Satish > > ------------- > > Breakpoint 2, MAIN__ () at ex1f.F90:51 > 51 x = PETSC_NULL_VEC > (gdb) list 33 > 28 ! > 29 Vec x,b,u > 30 Mat A > 31 KSP ksp > 32 PC pc > 33 PetscReal norm,tol > 34 PetscErrorCode ierr > 35 PetscInt i,n,col(3),its,i1,i2,i3 > 36 PetscBool flg > 37 PetscMPIInt size > (gdb) p x > $2 = ( v = -2 ) > (gdb) p b > $3 = ( v = -2 ) > (gdb) p u > $4 = ( v = -2 ) > (gdb) p A > $5 = ( v = -2 ) > (gdb) p ksp > $6 = ( v = -2 ) > (gdb) p pc > $7 = ( v = -2 ) > (gdb) c > Continuing. > > Breakpoint 3, MAIN__ () at ex1f.F90:52 > 52 call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr) > (gdb) p x > $8 = ( v = 0 ) > (gdb) > > > > On Tue, 17 Mar 2020, Mark Adams wrote: > > > > > > > Passing NULL to MatCreateVecs() means that you do not want a vector out: > > > > > > > > Yes, I want both vectors out and we pass it Vec that have been initialized > > with PETSC_NULL_VEC > > > > > > > > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… > > > > > > I am guessing that this was broken in 3.7 so that it ignored NULL input, > > > but we fixed that. > > > > > > > > v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code > > > > ex73f90t does not initialize the "x" vector that it gives > > to matcreatevecs_. Should we just remove initialization of our vectors to > > PETSC_NUILL_VEC? > > > > Is the PETSc model that you don't inialized PETSc object to NULL because > > you check that pointers are valid PETSc pointers instead of testing on > > NULL? So maybe we should remove all these initializations. > > > > Thanks, > > Mark > > > > > > > Thanks, > > > > > > Matt > > > > > > > > >> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > > >> > > >> Petsc code: > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > > >> *left, int *ierr) > > >> { > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p > > >> left=%p\n",right,left); > > >> CHKFORTRANNULLOBJECT(right); > > >> CHKFORTRANNULLOBJECT(left); > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p > > >> left=%p\n",right,left); > > >> *ierr = MatCreateVecs(*mat,right,left); > > >> } > > >> > > >> produces this: > > >> > > >> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 > > >> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) > > >> > > >> Shouldn't this be? > > >> > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > > >> *left, int *ierr) > > >> { > > >> *ierr = MatCreateVecs(*mat,right,left); > > >> } > > >> > > >> > > > > > > -- > > > 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 > > > > > > https://www.cse.buffalo.edu/~knepley/ > > > <http://www.cse.buffalo.edu/~knepley/> > > > > > > >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Mark Adams 17 Mar '20

17 Mar '20

> > > > What you are looking for is the first one. Right. > I see this is automatically > set. I don't see this initialization in petsc - so perhaps the > compiler is doing this automatically? [atleast by gfortran] > Our code initialized PETSC objects to "NULL". I was thinking that we should remove this, like ex73f90t. But, yea, if the compiler initializes this to 0 (PETSC_NULL_VEC) then we are broken again. It looks like ex73f90t would fail if the compiler initialized the members of our Fortran types to 0 ... > Satish > > ------------- > > Breakpoint 2, MAIN__ () at ex1f.F90:51 > 51 x = PETSC_NULL_VEC > (gdb) list 33 > 28 ! > 29 Vec x,b,u > 30 Mat A > 31 KSP ksp > 32 PC pc > 33 PetscReal norm,tol > 34 PetscErrorCode ierr > 35 PetscInt i,n,col(3),its,i1,i2,i3 > 36 PetscBool flg > 37 PetscMPIInt size > (gdb) p x > $2 = ( v = -2 ) > (gdb) p b > $3 = ( v = -2 ) > (gdb) p u > $4 = ( v = -2 ) > (gdb) p A > $5 = ( v = -2 ) > (gdb) p ksp > $6 = ( v = -2 ) > (gdb) p pc > $7 = ( v = -2 ) > (gdb) c > Continuing. > > Breakpoint 3, MAIN__ () at ex1f.F90:52 > 52 call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr) > (gdb) p x > $8 = ( v = 0 ) > (gdb) > > > > On Tue, 17 Mar 2020, Mark Adams wrote: > > > > > > > Passing NULL to MatCreateVecs() means that you do not want a vector > out: > > > > > > > > Yes, I want both vectors out and we pass it Vec that have been > initialized > > with PETSC_NULL_VEC > > > > > > > > > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… > > > > > > I am guessing that this was broken in 3.7 so that it ignored NULL > input, > > > but we fixed that. > > > > > > > > v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code > > > > ex73f90t does not initialize the "x" vector that it gives > > to matcreatevecs_. Should we just remove initialization of our vectors to > > PETSC_NUILL_VEC? > > > > Is the PETSc model that you don't inialized PETSc object to NULL because > > you check that pointers are valid PETSc pointers instead of testing on > > NULL? So maybe we should remove all these initializations. > > > > Thanks, > > Mark > > > > > > > Thanks, > > > > > > Matt > > > > > > > > >> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > > >> > > >> Petsc code: > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > > >> *left, int *ierr) > > >> { > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p > > >> left=%p\n",right,left); > > >> CHKFORTRANNULLOBJECT(right); > > >> CHKFORTRANNULLOBJECT(left); > > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p > > >> left=%p\n",right,left); > > >> *ierr = MatCreateVecs(*mat,right,left); > > >> } > > >> > > >> produces this: > > >> > > >> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 > > >> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) > > >> > > >> Shouldn't this be? > > >> > > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > > >> *left, int *ierr) > > >> { > > >> *ierr = MatCreateVecs(*mat,right,left); > > >> } > > >> > > >> > > > > > > -- > > > 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 > > > > > > https://www.cse.buffalo.edu/~knepley/ > > > <http://www.cse.buffalo.edu/~knepley/> > > > > > > >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Satish Balay 17 Mar '20

17 Mar '20

Well - if the issue is not catching errors - current petsc has cleaner mode of adding CHKERRA(ierr) in fortran. Satish On Tue, 17 Mar 2020, Mark Adams wrote: > I see what is happening. I think. We have: > > call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > call VecDuplicate(solver%bVec2,solver%rVec2,ierr) > > Well it turns out that [x|b]Vec2 are used only in debugging code that is > turned off. rVec2 is only used in a SNESSetFunction call. > > What we see in the code is that this call to VecDuplicate throws an error, > which we do not catch, in the current PETSc but is silent in v3.7.7. > Unless MatCreateVecs does create bVec2 in v3.7 (ie, CHKFORTRANNULLOBJECT did > not null it out back then, which BTW is not a great side effect of a "CHK" > macro IHMO). > > So we are are seeing a bunch of error messages but the code chugs along > after that, for a while. We do get another error eventually, that was a > NULL Vec as I recall. I am guessing that SNESSetFunction does not like to > get a NULL vector, but we will have to move on to debugging that. > (Did SNESSetFunction require a non-null vector since v3.7?) > > Thanks, > Mark > > > On Tue, Mar 17, 2020 at 2:52 PM Matthew Knepley <knepley(a)gmail.com> wrote: > > > On Tue, Mar 17, 2020 at 2:48 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > > >> > >> > >> On Tue, Mar 17, 2020 at 2:25 PM Matthew Knepley <knepley(a)gmail.com> > >> wrote: > >> > >>> On Tue, Mar 17, 2020 at 2:16 PM Mark Adams <mfadams(a)lbl.gov> wrote: > >>> > >>>> > >>>> > >>>>> Passing NULL to MatCreateVecs() means that you do not want a vector > >>>>> out: > >>>>> > >>>>> > >>>> Yes, I want both vectors out and we pass it Vec that have been > >>>> initialized with PETSC_NULL_VEC > >>>> > >>> > >>> That is wrong. > >>> > >>> > >>>> > >>>> > >>>>> > >>>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… > >>>>> > >>>>> I am guessing that this was broken in 3.7 so that it ignored NULL > >>>>> input, but we fixed that. > >>>>> > >>>>> > >>>> v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code > >>>> > >>> > >>> How could v3.7 have the check? If so, you code would be broken. > >>> > >> > >> Barry did it 12 years ago: > >> > >> > >> https://gitlab.com/petsc/petsc/-/commit/7c54600c425fb8d0ad4ad4bb40f7fac17c9… > >> > > > > What you are saying does not make sense. You are saying: > > > > 1) We are passing in NULL Vec objects > > > > 2) Barry put in code to check for such objects > > > > 3) We are getting valid Vec objects back > > > > One of those statement is not true > > > > Thanks, > > > > Matt > > > > > >> > >>> > >>>> ex73f90t does not initialize the "x" vector that it gives > >>>> to matcreatevecs_. Should we just remove initialization of our vectors to > >>>> PETSC_NUILL_VEC? > >>>> > >>> > >>> Yes. > >>> > >>> > >>>> Is the PETSc model that you don't inialized PETSc object to NULL > >>>> because you check that pointers are valid PETSc pointers instead of testing > >>>> on NULL? So maybe we should remove all these initializations. > >>>> > >>> > >>> I am not sure what you are asking here. > >>> > >> > >> That we should not initialize our PETSc Vec,Mat,etc. with some sort of > >> NULL. I am sure this is the case. > >> > >> > >>> > >>> Matt > >>> > >>> > >>>> Thanks, > >>>> Mark > >>>> > >>>> > >>>>> Thanks, > >>>>> > >>>>> Matt > >>>>> > >>>>> > >>>>>> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > >>>>>> > >>>>>> Petsc code: > >>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec > >>>>>> *right,Vec *left, int *ierr) > >>>>>> { > >>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p > >>>>>> left=%p\n",right,left); > >>>>>> CHKFORTRANNULLOBJECT(right); > >>>>>> CHKFORTRANNULLOBJECT(left); > >>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p > >>>>>> left=%p\n",right,left); > >>>>>> *ierr = MatCreateVecs(*mat,right,left); > >>>>>> } > >>>>>> > >>>>>> produces this: > >>>>>> > >>>>>> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 > >>>>>> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) > >>>>>> > >>>>>> Shouldn't this be? > >>>>>> > >>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec > >>>>>> *right,Vec *left, int *ierr) > >>>>>> { > >>>>>> *ierr = MatCreateVecs(*mat,right,left); > >>>>>> } > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> 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 > >>>>> > >>>>> https://www.cse.buffalo.edu/~knepley/ > >>>>> <http://www.cse.buffalo.edu/~knepley/> > >>>>> > >>>> > >>> > >>> -- > >>> 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 > >>> > >>> https://www.cse.buffalo.edu/~knepley/ > >>> <http://www.cse.buffalo.edu/~knepley/> > >>> > >> > > > > -- > > 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 > > > > https://www.cse.buffalo.edu/~knepley/ > > <http://www.cse.buffalo.edu/~knepley/> > > >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Satish Balay 17 Mar '20

17 Mar '20

The issue is: C has: Vec v=NULL; Vec *v=NULL; However its not clear how to implement this with current f90 interface. I think we currently have: Vec v = PETSC_NULL_VEC = 0 => the second one. What you are looking for is the first one. I see this is automatically set. I don't see this initialization in petsc - so perhaps the compiler is doing this automatically? [atleast by gfortran] Satish ------------- Breakpoint 2, MAIN__ () at ex1f.F90:51 51 x = PETSC_NULL_VEC (gdb) list 33 28 ! 29 Vec x,b,u 30 Mat A 31 KSP ksp 32 PC pc 33 PetscReal norm,tol 34 PetscErrorCode ierr 35 PetscInt i,n,col(3),its,i1,i2,i3 36 PetscBool flg 37 PetscMPIInt size (gdb) p x $2 = ( v = -2 ) (gdb) p b $3 = ( v = -2 ) (gdb) p u $4 = ( v = -2 ) (gdb) p A $5 = ( v = -2 ) (gdb) p ksp $6 = ( v = -2 ) (gdb) p pc $7 = ( v = -2 ) (gdb) c Continuing. Breakpoint 3, MAIN__ () at ex1f.F90:52 52 call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr) (gdb) p x $8 = ( v = 0 ) (gdb) On Tue, 17 Mar 2020, Mark Adams wrote: > > > > Passing NULL to MatCreateVecs() means that you do not want a vector out: > > > > > Yes, I want both vectors out and we pass it Vec that have been initialized > with PETSC_NULL_VEC > > > > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… > > > > I am guessing that this was broken in 3.7 so that it ignored NULL input, > > but we fixed that. > > > > > v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code > > ex73f90t does not initialize the "x" vector that it gives > to matcreatevecs_. Should we just remove initialization of our vectors to > PETSC_NUILL_VEC? > > Is the PETSc model that you don't inialized PETSc object to NULL because > you check that pointers are valid PETSc pointers instead of testing on > NULL? So maybe we should remove all these initializations. > > Thanks, > Mark > > > > Thanks, > > > > Matt > > > > > >> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) > >> > >> Petsc code: > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > >> *left, int *ierr) > >> { > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p > >> left=%p\n",right,left); > >> CHKFORTRANNULLOBJECT(right); > >> CHKFORTRANNULLOBJECT(left); > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p > >> left=%p\n",right,left); > >> *ierr = MatCreateVecs(*mat,right,left); > >> } > >> > >> produces this: > >> > >> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 > >> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) > >> > >> Shouldn't this be? > >> > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec > >> *left, int *ierr) > >> { > >> *ierr = MatCreateVecs(*mat,right,left); > >> } > >> > >> > > > > -- > > 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 > > > > https://www.cse.buffalo.edu/~knepley/ > > <http://www.cse.buffalo.edu/~knepley/> > > >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Mark Adams 17 Mar '20

17 Mar '20

I see what is happening. I think. We have: call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) call VecDuplicate(solver%bVec2,solver%rVec2,ierr) Well it turns out that [x|b]Vec2 are used only in debugging code that is turned off. rVec2 is only used in a SNESSetFunction call. What we see in the code is that this call to VecDuplicate throws an error, which we do not catch, in the current PETSc but is silent in v3.7.7. Unless MatCreateVecs does create bVec2 in v3.7 (ie, CHKFORTRANNULLOBJECT did not null it out back then, which BTW is not a great side effect of a "CHK" macro IHMO). So we are are seeing a bunch of error messages but the code chugs along after that, for a while. We do get another error eventually, that was a NULL Vec as I recall. I am guessing that SNESSetFunction does not like to get a NULL vector, but we will have to move on to debugging that. (Did SNESSetFunction require a non-null vector since v3.7?) Thanks, Mark On Tue, Mar 17, 2020 at 2:52 PM Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Mar 17, 2020 at 2:48 PM Mark Adams <mfadams(a)lbl.gov> wrote: > >> >> >> On Tue, Mar 17, 2020 at 2:25 PM Matthew Knepley <knepley(a)gmail.com> >> wrote: >> >>> On Tue, Mar 17, 2020 at 2:16 PM Mark Adams <mfadams(a)lbl.gov> wrote: >>> >>>> >>>> >>>>> Passing NULL to MatCreateVecs() means that you do not want a vector >>>>> out: >>>>> >>>>> >>>> Yes, I want both vectors out and we pass it Vec that have been >>>> initialized with PETSC_NULL_VEC >>>> >>> >>> That is wrong. >>> >>> >>>> >>>> >>>>> >>>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… >>>>> >>>>> I am guessing that this was broken in 3.7 so that it ignored NULL >>>>> input, but we fixed that. >>>>> >>>>> >>>> v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code >>>> >>> >>> How could v3.7 have the check? If so, you code would be broken. >>> >> >> Barry did it 12 years ago: >> >> >> https://gitlab.com/petsc/petsc/-/commit/7c54600c425fb8d0ad4ad4bb40f7fac17c9… >> > > What you are saying does not make sense. You are saying: > > 1) We are passing in NULL Vec objects > > 2) Barry put in code to check for such objects > > 3) We are getting valid Vec objects back > > One of those statement is not true > > Thanks, > > Matt > > >> >>> >>>> ex73f90t does not initialize the "x" vector that it gives >>>> to matcreatevecs_. Should we just remove initialization of our vectors to >>>> PETSC_NUILL_VEC? >>>> >>> >>> Yes. >>> >>> >>>> Is the PETSc model that you don't inialized PETSc object to NULL >>>> because you check that pointers are valid PETSc pointers instead of testing >>>> on NULL? So maybe we should remove all these initializations. >>>> >>> >>> I am not sure what you are asking here. >>> >> >> That we should not initialize our PETSc Vec,Mat,etc. with some sort of >> NULL. I am sure this is the case. >> >> >>> >>> Matt >>> >>> >>>> Thanks, >>>> Mark >>>> >>>> >>>>> Thanks, >>>>> >>>>> Matt >>>>> >>>>> >>>>>> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) >>>>>> >>>>>> Petsc code: >>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec >>>>>> *right,Vec *left, int *ierr) >>>>>> { >>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p >>>>>> left=%p\n",right,left); >>>>>> CHKFORTRANNULLOBJECT(right); >>>>>> CHKFORTRANNULLOBJECT(left); >>>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p >>>>>> left=%p\n",right,left); >>>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>>> } >>>>>> >>>>>> produces this: >>>>>> >>>>>> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 >>>>>> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) >>>>>> >>>>>> Shouldn't this be? >>>>>> >>>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec >>>>>> *right,Vec *left, int *ierr) >>>>>> { >>>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>>> } >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> https://www.cse.buffalo.edu/~knepley/ >>>>> <http://www.cse.buffalo.edu/~knepley/> >>>>> >>>> >>> >>> -- >>> 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 >>> >>> https://www.cse.buffalo.edu/~knepley/ >>> <http://www.cse.buffalo.edu/~knepley/> >>> >> > > -- > 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 > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> >

1 0

Re: [petsc-dev] MatCreateVecs from Fortran problem
by Matthew Knepley 17 Mar '20

17 Mar '20

On Tue, Mar 17, 2020 at 2:48 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > > On Tue, Mar 17, 2020 at 2:25 PM Matthew Knepley <knepley(a)gmail.com> wrote: > >> On Tue, Mar 17, 2020 at 2:16 PM Mark Adams <mfadams(a)lbl.gov> wrote: >> >>> >>> >>>> Passing NULL to MatCreateVecs() means that you do not want a vector out: >>>> >>>> >>> Yes, I want both vectors out and we pass it Vec that have been >>> initialized with PETSC_NULL_VEC >>> >> >> That is wrong. >> >> >>> >>> >>>> >>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateV… >>>> >>>> I am guessing that this was broken in 3.7 so that it ignored NULL >>>> input, but we fixed that. >>>> >>>> >>> v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code >>> >> >> How could v3.7 have the check? If so, you code would be broken. >> > > Barry did it 12 years ago: > > > https://gitlab.com/petsc/petsc/-/commit/7c54600c425fb8d0ad4ad4bb40f7fac17c9… > What you are saying does not make sense. You are saying: 1) We are passing in NULL Vec objects 2) Barry put in code to check for such objects 3) We are getting valid Vec objects back One of those statement is not true Thanks, Matt > >> >>> ex73f90t does not initialize the "x" vector that it gives >>> to matcreatevecs_. Should we just remove initialization of our vectors to >>> PETSC_NUILL_VEC? >>> >> >> Yes. >> >> >>> Is the PETSc model that you don't inialized PETSc object to NULL because >>> you check that pointers are valid PETSc pointers instead of testing on >>> NULL? So maybe we should remove all these initializations. >>> >> >> I am not sure what you are asking here. >> > > That we should not initialize our PETSc Vec,Mat,etc. with some sort of > NULL. I am sure this is the case. > > >> >> Matt >> >> >>> Thanks, >>> Mark >>> >>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> >>>>> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr) >>>>> >>>>> Petsc code: >>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec >>>>> *left, int *ierr) >>>>> { >>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p >>>>> left=%p\n",right,left); >>>>> CHKFORTRANNULLOBJECT(right); >>>>> CHKFORTRANNULLOBJECT(left); >>>>> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p >>>>> left=%p\n",right,left); >>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>> } >>>>> >>>>> produces this: >>>>> >>>>> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 >>>>> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil) >>>>> >>>>> Shouldn't this be? >>>>> >>>>> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec >>>>> *left, int *ierr) >>>>> { >>>>> *ierr = MatCreateVecs(*mat,right,left); >>>>> } >>>>> >>>>> >>>> >>>> -- >>>> 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 >>>> >>>> https://www.cse.buffalo.edu/~knepley/ >>>> <http://www.cse.buffalo.edu/~knepley/> >>>> >>> >> >> -- >> 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 >> >> https://www.cse.buffalo.edu/~knepley/ >> <http://www.cse.buffalo.edu/~knepley/> >> > -- 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 https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>

1 0