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

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

17 Mar '20

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… > > >> 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/> >

1 0

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

17 Mar '20

On , 2020Mar17, at 13:15, Mark Adams <mfadams(a)lbl.gov<mailto:[email protected]>> wrote: 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? I think petsc has switched to the mpi/f08 model where objects are no longer opaque pointers hiding in INTEGERs, but actual Fortran derived Type objects. At least in MPI these days MPI_COMM_NULL is not a constant but a Type(MPI_Comm) variable. Victor.

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: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. > 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. 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/>

1 0

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

17 Mar '20

> > 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 Matthew Knepley 17 Mar '20

17 Mar '20

On Tue, Mar 17, 2020 at 1:34 PM Mark Adams <mfadams(a)lbl.gov> wrote: > Our code broke in moving from v3.7 to current. The problem seems to be in > MatCreateVecs > > Our code has: > > Vec::XVec > Vec::BVec > > this%xVec2 = PETSC_NULL_VEC > this%bVec2 = PETSC_NULL_VEC > Passing NULL to MatCreateVecs() means that you do not want a vector out: 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. 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

MatCreateVecs from Fortran problem
by Mark Adams 17 Mar '20

17 Mar '20

Our code broke in moving from v3.7 to current. The problem seems to be in MatCreateVecs Our code has: Vec::XVec Vec::BVec this%xVec2 = PETSC_NULL_VEC this%bVec2 = PETSC_NULL_VEC 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); }

1 0

Re: [petsc-dev] print statements in fortran interface functions
by Satish Balay 17 Mar '20

17 Mar '20

This happens when the binary is not updated to use the new sources [i.e not rebuilt - or rebuilt with old obj files]. gdb should print a warning of type: warning: Source file is more recent than executable. Satish On Tue, 17 Mar 2020, Mark Adams wrote: > The app is running wrong but ex73f90t is running fine. > I fixed it by deleting both directories (arch and install). I saw the file > getting recompiled with make all, and installed, but it seemed to not take > somehow. > And I could step through the code and see the print statements but its like > it had the wrong object file but the right source info. Strange. > Thanks, > Mark > > > > On Tue, Mar 17, 2020 at 9:53 AM Matthew Knepley <knepley(a)gmail.com> wrote: > > > On different OSes, the buffering for printf is different. Do you mean that > > the program ends correctly and prints nothing, or > > do you mean that you execute a print but nothing immediately outputs to > > the screen. We do not explicitly flush, so it could > > be that this weird OS is buffering in a way you do not expect. > > > > Matt > > > > On Mon, Mar 16, 2020 at 11:02 PM Mark Adams <mfadams(a)lbl.gov> wrote: > > > >> Thanks, I have verified that PetscPrint with an installed libs works as > >> expected on my Mac (on ex73f90t). > >> I'll keep looking on Cori. > >> ThanksMark > >> > >> On Mon, Mar 16, 2020 at 10:37 PM Jacob Faibussowitsch < > >> jacob.fai(a)gmail.com> wrote: > >> > >>> May be an issue printing to STDOUT, HPC sometimes redirect STDOUT to > >>> some other log files. Maybe try redirecting your PetscInfo() or > >>> PetscPrintf() output to a file. For PetscInfo its just a filename after the > >>> info flag: ./yourCode -info somefile . As for the PetscPrintf you will have > >>> to change those calls in your src to PetscFPrintf(). > >>> > >>> Best regards, > >>> > >>> Jacob Faibussowitsch > >>> (Jacob Fai - booss - oh - vitch) > >>> Cell: (312) 694-3391 > >>> > >>> On Mar 16, 2020, at 9:26 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > >>> > >>> > >>> > >>> On Mon, Mar 16, 2020 at 9:50 PM Jacob Faibussowitsch < > >>> jacob.fai(a)gmail.com> wrote: > >>> > >>>> Hello Mark, > >>>> > >>>> If you are using PetscInfo to print, PetscInfo requires that you pass > >>>> “-info” as a command line flag in order to print anything. Sounds simple > >>>> enough to miss, did you run your code with it? i.e. ./yourCode -info? > >>>> > >>> > >>> Yea, I added -info. > >>> > >>> > >>>> > >>>> For what its worth, PetscPrintf on PETSC_COMM_WORLD will always print > >>>> but only from proc 0. PetscSynchronizedPrintf prints from all in order. > >>>> Might be more useful for debugging than PetscInfo! > >>>> > >>> > >>> Yea, I started with PetscPrintf. Started with WORLD then tried SELF. > >>> Still no output but I can step through the code and see the print > >>> statements, but nothing. > >>> > >>> This is on Cori/Haswell. I have now used printf on my Mac and it works. > >>> I did not do an install on my Mac, but I would not think that would > >>> matter... I should test that I suppose. > >>> > >>> > >>>> > >>>> Best regards, > >>>> > >>>> Jacob Faibussowitsch > >>>> (Jacob Fai - booss - oh - vitch) > >>>> Cell: (312) 694-3391 > >>>> > >>>> On Mar 16, 2020, at 7:54 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > >>>> > >>>> I am trying to debug an application code that works with v3.7 but fails > >>>> with master. The code works for "normal" solvers but for a solver that uses > >>>> FieldSplit it fails. It looks like vectors are not getting created from > >>>> MatCreateVecs with a matrix that is a MatNest (I can't run the code). > >>>> > >>>> I have put print statements in the interface files to try to see what > >>>> is going on but the print statements seem to disappear somehow. (I added > >>>> the same print statements in my installation of v3.7 to see what is > >>>> different) I was using PetscPrint and then found and example of a Fortran > >>>> PetscInfo and switched to that. I stepped through the code with DDT and see > >>>> the print statements but nothing goes to the output. I did this DDT stuff > >>>> with ex73f90t, which has a MatCreateNest. > >>>> > >>>> I am completely baffled. Does anyone have any ideas? > >>>> > >>>> Thanks, > >>>> Mark > >>>> > >>>> > >>>> > >>> > > > > -- > > 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] print statements in fortran interface functions
by Mark Adams 17 Mar '20

17 Mar '20

The app is running wrong but ex73f90t is running fine. I fixed it by deleting both directories (arch and install). I saw the file getting recompiled with make all, and installed, but it seemed to not take somehow. And I could step through the code and see the print statements but its like it had the wrong object file but the right source info. Strange. Thanks, Mark On Tue, Mar 17, 2020 at 9:53 AM Matthew Knepley <knepley(a)gmail.com> wrote: > On different OSes, the buffering for printf is different. Do you mean that > the program ends correctly and prints nothing, or > do you mean that you execute a print but nothing immediately outputs to > the screen. We do not explicitly flush, so it could > be that this weird OS is buffering in a way you do not expect. > > Matt > > On Mon, Mar 16, 2020 at 11:02 PM Mark Adams <mfadams(a)lbl.gov> wrote: > >> Thanks, I have verified that PetscPrint with an installed libs works as >> expected on my Mac (on ex73f90t). >> I'll keep looking on Cori. >> ThanksMark >> >> On Mon, Mar 16, 2020 at 10:37 PM Jacob Faibussowitsch < >> jacob.fai(a)gmail.com> wrote: >> >>> May be an issue printing to STDOUT, HPC sometimes redirect STDOUT to >>> some other log files. Maybe try redirecting your PetscInfo() or >>> PetscPrintf() output to a file. For PetscInfo its just a filename after the >>> info flag: ./yourCode -info somefile . As for the PetscPrintf you will have >>> to change those calls in your src to PetscFPrintf(). >>> >>> Best regards, >>> >>> Jacob Faibussowitsch >>> (Jacob Fai - booss - oh - vitch) >>> Cell: (312) 694-3391 >>> >>> On Mar 16, 2020, at 9:26 PM, Mark Adams <mfadams(a)lbl.gov> wrote: >>> >>> >>> >>> On Mon, Mar 16, 2020 at 9:50 PM Jacob Faibussowitsch < >>> jacob.fai(a)gmail.com> wrote: >>> >>>> Hello Mark, >>>> >>>> If you are using PetscInfo to print, PetscInfo requires that you pass >>>> “-info” as a command line flag in order to print anything. Sounds simple >>>> enough to miss, did you run your code with it? i.e. ./yourCode -info? >>>> >>> >>> Yea, I added -info. >>> >>> >>>> >>>> For what its worth, PetscPrintf on PETSC_COMM_WORLD will always print >>>> but only from proc 0. PetscSynchronizedPrintf prints from all in order. >>>> Might be more useful for debugging than PetscInfo! >>>> >>> >>> Yea, I started with PetscPrintf. Started with WORLD then tried SELF. >>> Still no output but I can step through the code and see the print >>> statements, but nothing. >>> >>> This is on Cori/Haswell. I have now used printf on my Mac and it works. >>> I did not do an install on my Mac, but I would not think that would >>> matter... I should test that I suppose. >>> >>> >>>> >>>> Best regards, >>>> >>>> Jacob Faibussowitsch >>>> (Jacob Fai - booss - oh - vitch) >>>> Cell: (312) 694-3391 >>>> >>>> On Mar 16, 2020, at 7:54 PM, Mark Adams <mfadams(a)lbl.gov> wrote: >>>> >>>> I am trying to debug an application code that works with v3.7 but fails >>>> with master. The code works for "normal" solvers but for a solver that uses >>>> FieldSplit it fails. It looks like vectors are not getting created from >>>> MatCreateVecs with a matrix that is a MatNest (I can't run the code). >>>> >>>> I have put print statements in the interface files to try to see what >>>> is going on but the print statements seem to disappear somehow. (I added >>>> the same print statements in my installation of v3.7 to see what is >>>> different) I was using PetscPrint and then found and example of a Fortran >>>> PetscInfo and switched to that. I stepped through the code with DDT and see >>>> the print statements but nothing goes to the output. I did this DDT stuff >>>> with ex73f90t, which has a MatCreateNest. >>>> >>>> I am completely baffled. Does anyone have any ideas? >>>> >>>> Thanks, >>>> Mark >>>> >>>> >>>> >>> > > -- > 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] print statements in fortran interface functions
by Matthew Knepley 17 Mar '20

17 Mar '20

On different OSes, the buffering for printf is different. Do you mean that the program ends correctly and prints nothing, or do you mean that you execute a print but nothing immediately outputs to the screen. We do not explicitly flush, so it could be that this weird OS is buffering in a way you do not expect. Matt On Mon, Mar 16, 2020 at 11:02 PM Mark Adams <mfadams(a)lbl.gov> wrote: > Thanks, I have verified that PetscPrint with an installed libs works as > expected on my Mac (on ex73f90t). > I'll keep looking on Cori. > ThanksMark > > On Mon, Mar 16, 2020 at 10:37 PM Jacob Faibussowitsch <jacob.fai(a)gmail.com> > wrote: > >> May be an issue printing to STDOUT, HPC sometimes redirect STDOUT to some >> other log files. Maybe try redirecting your PetscInfo() or PetscPrintf() >> output to a file. For PetscInfo its just a filename after the info flag: >> ./yourCode -info somefile . As for the PetscPrintf you will have to change >> those calls in your src to PetscFPrintf(). >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >> On Mar 16, 2020, at 9:26 PM, Mark Adams <mfadams(a)lbl.gov> wrote: >> >> >> >> On Mon, Mar 16, 2020 at 9:50 PM Jacob Faibussowitsch <jacob.fai(a)gmail.com> >> wrote: >> >>> Hello Mark, >>> >>> If you are using PetscInfo to print, PetscInfo requires that you pass >>> “-info” as a command line flag in order to print anything. Sounds simple >>> enough to miss, did you run your code with it? i.e. ./yourCode -info? >>> >> >> Yea, I added -info. >> >> >>> >>> For what its worth, PetscPrintf on PETSC_COMM_WORLD will always print >>> but only from proc 0. PetscSynchronizedPrintf prints from all in order. >>> Might be more useful for debugging than PetscInfo! >>> >> >> Yea, I started with PetscPrintf. Started with WORLD then tried SELF. >> Still no output but I can step through the code and see the print >> statements, but nothing. >> >> This is on Cori/Haswell. I have now used printf on my Mac and it works. I >> did not do an install on my Mac, but I would not think that would matter... >> I should test that I suppose. >> >> >>> >>> Best regards, >>> >>> Jacob Faibussowitsch >>> (Jacob Fai - booss - oh - vitch) >>> Cell: (312) 694-3391 >>> >>> On Mar 16, 2020, at 7:54 PM, Mark Adams <mfadams(a)lbl.gov> wrote: >>> >>> I am trying to debug an application code that works with v3.7 but fails >>> with master. The code works for "normal" solvers but for a solver that uses >>> FieldSplit it fails. It looks like vectors are not getting created from >>> MatCreateVecs with a matrix that is a MatNest (I can't run the code). >>> >>> I have put print statements in the interface files to try to see what is >>> going on but the print statements seem to disappear somehow. (I added the >>> same print statements in my installation of v3.7 to see what is different) >>> I was using PetscPrint and then found and example of a Fortran PetscInfo >>> and switched to that. I stepped through the code with DDT and see the print >>> statements but nothing goes to the output. I did this DDT stuff with >>> ex73f90t, which has a MatCreateNest. >>> >>> I am completely baffled. Does anyone have any ideas? >>> >>> Thanks, >>> Mark >>> >>> >>> >> -- 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] print statements in fortran interface functions
by Mark Adams 16 Mar '20

16 Mar '20

Thanks, I have verified that PetscPrint with an installed libs works as expected on my Mac (on ex73f90t). I'll keep looking on Cori. ThanksMark On Mon, Mar 16, 2020 at 10:37 PM Jacob Faibussowitsch <jacob.fai(a)gmail.com> wrote: > May be an issue printing to STDOUT, HPC sometimes redirect STDOUT to some > other log files. Maybe try redirecting your PetscInfo() or PetscPrintf() > output to a file. For PetscInfo its just a filename after the info flag: > ./yourCode -info somefile . As for the PetscPrintf you will have to change > those calls in your src to PetscFPrintf(). > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > On Mar 16, 2020, at 9:26 PM, Mark Adams <mfadams(a)lbl.gov> wrote: > > > > On Mon, Mar 16, 2020 at 9:50 PM Jacob Faibussowitsch <jacob.fai(a)gmail.com> > wrote: > >> Hello Mark, >> >> If you are using PetscInfo to print, PetscInfo requires that you pass >> “-info” as a command line flag in order to print anything. Sounds simple >> enough to miss, did you run your code with it? i.e. ./yourCode -info? >> > > Yea, I added -info. > > >> >> For what its worth, PetscPrintf on PETSC_COMM_WORLD will always print but >> only from proc 0. PetscSynchronizedPrintf prints from all in order. Might >> be more useful for debugging than PetscInfo! >> > > Yea, I started with PetscPrintf. Started with WORLD then tried SELF. Still > no output but I can step through the code and see the print statements, but > nothing. > > This is on Cori/Haswell. I have now used printf on my Mac and it works. I > did not do an install on my Mac, but I would not think that would matter... > I should test that I suppose. > > >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >> On Mar 16, 2020, at 7:54 PM, Mark Adams <mfadams(a)lbl.gov> wrote: >> >> I am trying to debug an application code that works with v3.7 but fails >> with master. The code works for "normal" solvers but for a solver that uses >> FieldSplit it fails. It looks like vectors are not getting created from >> MatCreateVecs with a matrix that is a MatNest (I can't run the code). >> >> I have put print statements in the interface files to try to see what is >> going on but the print statements seem to disappear somehow. (I added the >> same print statements in my installation of v3.7 to see what is different) >> I was using PetscPrint and then found and example of a Fortran PetscInfo >> and switched to that. I stepped through the code with DDT and see the print >> statements but nothing goes to the output. I did this DDT stuff with >> ex73f90t, which has a MatCreateNest. >> >> I am completely baffled. Does anyone have any ideas? >> >> Thanks, >> Mark >> >> >> >

1 0