January 2015 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] changes coming to PETSc master branch
by Barry Smith 31 Jan '15

31 Jan '15

Updated in barry/feature-vec-lock and next Thanks Barry > On Jan 31, 2015, at 10:53 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > Barry, > > ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/01/30/filtered-mak… > > Perhaps the following fix? > > Satish > > ------------ > diff --git a/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c b/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c > index f76267e..52e8a4f 100644 > --- a/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c > +++ b/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c > @@ -182,8 +182,8 @@ PetscErrorCode MatSolve_MKL_PARDISO(Mat A,Vec b,Vec x) > > > mat_mkl_pardiso->nrhs = 1; > - ierr = VecGetArrayRead(x,&xarray);CHKERRQ(ierr); > - ierr = VecGetArray(b,&barray);CHKERRQ(ierr); > + ierr = VecGetArray(x,&xarray);CHKERRQ(ierr); > + ierr = VecGetArrayRead(b,&barray);CHKERRQ(ierr); > > /* solve phase */ > /*-------------*/ > @@ -207,8 +207,8 @@ PetscErrorCode MatSolve_MKL_PARDISO(Mat A,Vec b,Vec x) > > > if (mat_mkl_pardiso->err < 0) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_LIB,"Error reported by MKL_PARDISO: err=%d. Please check manual\n",mat_mkl_pardiso->err); > - ierr = VecRestoreArrayRead(x,&xarray);CHKERRQ(ierr); > - ierr = VecRestoreArray(b,&barray);CHKERRQ(ierr); > + ierr = VecRestoreArray(x,&xarray);CHKERRQ(ierr); > + ierr = VecRestoreArrayRead(b,&barray);CHKERRQ(ierr); > mat_mkl_pardiso->CleanUp = PETSC_TRUE; > PetscFunctionReturn(0); > }

1 0

Re: [petsc-dev] changes coming to PETSc master branch
by Satish Balay 31 Jan '15

31 Jan '15

Barry, ftp://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2015/01/30/filtered-mak… Perhaps the following fix? Satish ------------ diff --git a/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c b/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c index f76267e..52e8a4f 100644 --- a/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c +++ b/src/mat/impls/aij/seq/mkl_pardiso/mkl_pardiso.c @@ -182,8 +182,8 @@ PetscErrorCode MatSolve_MKL_PARDISO(Mat A,Vec b,Vec x) mat_mkl_pardiso->nrhs = 1; - ierr = VecGetArrayRead(x,&xarray);CHKERRQ(ierr); - ierr = VecGetArray(b,&barray);CHKERRQ(ierr); + ierr = VecGetArray(x,&xarray);CHKERRQ(ierr); + ierr = VecGetArrayRead(b,&barray);CHKERRQ(ierr); /* solve phase */ /*-------------*/ @@ -207,8 +207,8 @@ PetscErrorCode MatSolve_MKL_PARDISO(Mat A,Vec b,Vec x) if (mat_mkl_pardiso->err < 0) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_LIB,"Error reported by MKL_PARDISO: err=%d. Please check manual\n",mat_mkl_pardiso->err); - ierr = VecRestoreArrayRead(x,&xarray);CHKERRQ(ierr); - ierr = VecRestoreArray(b,&barray);CHKERRQ(ierr); + ierr = VecRestoreArray(x,&xarray);CHKERRQ(ierr); + ierr = VecRestoreArrayRead(b,&barray);CHKERRQ(ierr); mat_mkl_pardiso->CleanUp = PETSC_TRUE; PetscFunctionReturn(0); }

1 0

Re: [petsc-dev] [petsc-users] Is PetscViewerBinary special?
by Dave May 30 Jan '15

30 Jan '15

Cool. I'm putting together a pull request for you to look at which does this re-factoring. > You also need to add a function call interface for turning on/off use > of MPIIO. Perhaps PetscViewerBinarySetUseMPIIO(viewer,PetscBool) and a > getter. > > Actually I had this ear-marked for another email. Since PetscViewerBinarySetSkipOptions() PetscViewerBinarySetSkipHeader() all have the args PetscViewer viewer, PetscBool skip I would propose that PetscViewerBinarySetMPIIO() should have the same calling patter, rather than just having the arg PetscViewer viewer. PetscViewerBinaryMPIIO() should behave like PetscViewerBinarySkipInfo() however the former function name is already used - I'll re-name that one to PetscViewerBinaryReadWriteMPIIO() I will clean this up and put it all in the fork/branch I've created. > > > [5] PetscViewerSetUp_Binary() would be called at the end of > PetscViewerSetFromOptions_Binary(), > > No it should not be called here. User may want to continue to do stuff > here. > Okay - I'll move it else where. > > or at the beginning of any of the getters associated with > PetscViewerBinary, e.g. PetscViewerBinaryGetDescriptor() > > > > and at the beginning of PetscViewerBinaryWrite() PetscViewerBinaryRead(). > > > > [6] PetscViewerBinaryOpen() would obviously call > PetscViewerSetFromOptions_Binary(). > > > > Or does this approach sound like a giant hack? > > Probably a new operation for the PetscViewer (setup) would be a nicer > way to go. > > This sounds reasonable to try. Not worth yet adding a setup for all > viewers. > > Okay, I also thought it wasn't worth the trouble of adding a new operation. Cheers Dave > Barry > > > > > I can put this in branch if you think it is worth while pursuing the > approach I propose. > > > > Cheers > > Dave > > > > On 30 January 2015 at 14:56, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > Dave, > > > > I did the mpiio hack originally and yes it is very ad hoc and could > do with a good reorganization. I am fine with accepting a branch that > treats the MPIIO one as a completely different class; the only reason not > to do this is if both classes have essentially the same code but no reuse > between them. > > > > Barry > > > > > On Jan 30, 2015, at 7:51 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > > > > > Thanks Matt. > > > > > > Given the PETSc way of doing things, I believe the following should be > possible: > > > [1] attach an option prefix to a viewer > > > [2] skip the header on some binary viewers > > > [3] use mpiio for some binary viewers, but not all of them. > > > > > > However, it doesn't appear to be completely simple to allow this > behaviour. > > > > > > For instance, replacing > > > ierr = > PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > > with > > > ierr = > PetscOptionsGetBool(((PetscObject)viewer)->prefix,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > > won't work as an option prefix will never have been set. > > > > > > If I was to add a PetscViewerSetFromOptions_Binary(), I would have to > ensure that PetscViewerSetFromOptions() was called before > PetscViewerFileSetName() was called as the latter this triggers a swap of > the functions used to open binary file, e.g. from > PetscViewerFileSetName_Binary() to PetscViewerFileSetName_MPIIO() > > > > > > Would it be simpler and cleaner to have MPIIO be defined as an > independent implementation which was a sub-class of the binary class? > > > > > > Then we could use command line flags to switch between implementations > at runtime > > > -xxx_viewer_type binary > > > versus > > > -xxx_viewer_type mpiio > > > rather than having to use > > > -xxx_viewer_type binary -viewer_binary_mpiio > > > which has obvious short comings like forcing all binary viewers, > independent of the prefix to use mpiio. It would also allow the PetscViewer > object to be used in a manner which follows the standard PETSc pattern of: > XXCreate(), XXSetOptionsPrefix(), XXSetType(), XXSetFromOptions(). > > > > > > Then we could do this > > > PetscViewerCreate() > > > PetscViewerSetOptionsPrefix() > > > PetscViewerSetType() > > > PetscViewerFileSetMode() > > > PetscViewerBinarySetSkipHeader() > > > PetscViewerFileSetName() > > > PetscViewerSetFromOptions() > > > and it wouldn't matter which order SetName(), BinarySkipHeader() etc > were called. > > > > > > What do people think? > > > > > > > > > Cheers > > > Dave > > > > > > > > > > > > > > > > > > On 30 January 2015 at 13:56, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > On Fri, Jan 30, 2015 at 2:06 AM, Dave May <dave.mayhem23(a)gmail.com> > wrote: > > > Hello, > > > > > > I've noticed the create function PetscViewerCreate_Binary() doesn't > appear to be using the options prefix attached to the PetscViewer. > > > Specifically, I see on line 1276 of > > > petsc-3.5.2/src/sys/classes/viewer/impls/binary/binv.c > > > the following > > > ierr = > PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > > > > > Is this an oversight or something intentional? > > > > > > This is an oversight. > > > > > > Matt > > > > > > Are PetscViewers in general behaving such that they cannot be > configured independently of each other if > > > PetscViewerSetOptionsPrefix() and PetscViewerSetFromOptions() are > called? > > > > > > > > > Cheers > > > Dave > > > > > > > > > > > > -- > > > 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] [petsc-users] Is PetscViewerBinary special?
by Barry Smith 30 Jan '15

30 Jan '15

> On Jan 30, 2015, at 8:53 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > Hi Barry, > > Okay - fair enough. Almost of all the code would be re-used with my suggestion. > > I hope you don't mind, I moved this discussion to the dev list as I wanted to propose a solution. > > What about this as an alternative? > > [1] I add PetscViewerSetFromOptions_Binary() > > [2] I add a setupcalled flag into PetscViewer_Binary > > [3] I modify PetscViewerFileSetName_Binary() to just set the file name string and defer actually opening of the file to within in a function PetscViewerSetUp_Binary(). > Depending on whether mpiio is set we call (essentially) the current contents of PetscViewerFileSetName_MPIIO() or PetscViewerFileSetName_Binary(). > However the parsing of options -viewer_binary_skip_info etc would be moved into PetscViewerSetFromOptions_Binary() > > [4] I modify the PetscViewerDestory_Binary() such that it calls the appropriate functions for mpiio or non-mpiio and remove PetscObjectComposeFunction() from PetscViewerBinarySetMPIIO_Binary() > You also need to add a function call interface for turning on/off use of MPIIO. Perhaps PetscViewerBinarySetUseMPIIO(viewer,PetscBool) and a getter. > [5] PetscViewerSetUp_Binary() would be called at the end of PetscViewerSetFromOptions_Binary(), No it should not be called here. User may want to continue to do stuff here. > or at the beginning of any of the getters associated with PetscViewerBinary, e.g. PetscViewerBinaryGetDescriptor() > and at the beginning of PetscViewerBinaryWrite() PetscViewerBinaryRead(). > > [6] PetscViewerBinaryOpen() would obviously call PetscViewerSetFromOptions_Binary(). > > Or does this approach sound like a giant hack? > Probably a new operation for the PetscViewer (setup) would be a nicer way to go. This sounds reasonable to try. Not worth yet adding a setup for all viewers. Barry > > I can put this in branch if you think it is worth while pursuing the approach I propose. > > Cheers > Dave > > On 30 January 2015 at 14:56, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Dave, > > I did the mpiio hack originally and yes it is very ad hoc and could do with a good reorganization. I am fine with accepting a branch that treats the MPIIO one as a completely different class; the only reason not to do this is if both classes have essentially the same code but no reuse between them. > > Barry > > > On Jan 30, 2015, at 7:51 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > > > Thanks Matt. > > > > Given the PETSc way of doing things, I believe the following should be possible: > > [1] attach an option prefix to a viewer > > [2] skip the header on some binary viewers > > [3] use mpiio for some binary viewers, but not all of them. > > > > However, it doesn't appear to be completely simple to allow this behaviour. > > > > For instance, replacing > > ierr = PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > with > > ierr = PetscOptionsGetBool(((PetscObject)viewer)->prefix,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > won't work as an option prefix will never have been set. > > > > If I was to add a PetscViewerSetFromOptions_Binary(), I would have to ensure that PetscViewerSetFromOptions() was called before PetscViewerFileSetName() was called as the latter this triggers a swap of the functions used to open binary file, e.g. from PetscViewerFileSetName_Binary() to PetscViewerFileSetName_MPIIO() > > > > Would it be simpler and cleaner to have MPIIO be defined as an independent implementation which was a sub-class of the binary class? > > > > Then we could use command line flags to switch between implementations at runtime > > -xxx_viewer_type binary > > versus > > -xxx_viewer_type mpiio > > rather than having to use > > -xxx_viewer_type binary -viewer_binary_mpiio > > which has obvious short comings like forcing all binary viewers, independent of the prefix to use mpiio. It would also allow the PetscViewer object to be used in a manner which follows the standard PETSc pattern of: XXCreate(), XXSetOptionsPrefix(), XXSetType(), XXSetFromOptions(). > > > > Then we could do this > > PetscViewerCreate() > > PetscViewerSetOptionsPrefix() > > PetscViewerSetType() > > PetscViewerFileSetMode() > > PetscViewerBinarySetSkipHeader() > > PetscViewerFileSetName() > > PetscViewerSetFromOptions() > > and it wouldn't matter which order SetName(), BinarySkipHeader() etc were called. > > > > What do people think? > > > > > > Cheers > > Dave > > > > > > > > > > > > On 30 January 2015 at 13:56, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Fri, Jan 30, 2015 at 2:06 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > Hello, > > > > I've noticed the create function PetscViewerCreate_Binary() doesn't appear to be using the options prefix attached to the PetscViewer. > > Specifically, I see on line 1276 of > > petsc-3.5.2/src/sys/classes/viewer/impls/binary/binv.c > > the following > > ierr = PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > > > Is this an oversight or something intentional? > > > > This is an oversight. > > > > Matt > > > > Are PetscViewers in general behaving such that they cannot be configured independently of each other if > > PetscViewerSetOptionsPrefix() and PetscViewerSetFromOptions() are called? > > > > > > Cheers > > Dave > > > > > > > > -- > > 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] changes coming to PETSc master branch
by Barry Smith 30 Jan '15

30 Jan '15

Pushed in barry/feature-vec-lock and next Thanks Barry > On Jan 30, 2015, at 12:36 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > There are nightlybuild errors with this. Perhaps the following is the fix? > > Satish > > ---------- > > diff --git a/include/petscvec.h b/include/petscvec.h > index 1369ff0..3c751d7 100644 > --- a/include/petscvec.h > +++ b/include/petscvec.h > @@ -457,9 +457,10 @@ PETSC_EXTERN PetscErrorCode VecLockPush(Vec); > PETSC_EXTERN PetscErrorCode VecLockPop(Vec); > #define VecLocked(x,arg) do {PetscInt _st; PetscErrorCode __ierr = VecLockGet(x,&_st); CHKERRQ(__ierr); if (_st > 0) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE," Vec is locked read only, argument # %d",arg);} while (0) > #else > -#define VecLockPush(x) do {} while (0) > -#define VecLockPop(x) do {} while (0) > -#define VecLocked(x,arg) do {} while (0) > +#define VecLockGet(x,arg) *(arg) = 0 > +#define VecLockPush(x) 0 > +#define VecLockPop(x) 0 > +#define VecLocked(x,arg) > #endif > > PETSC_EXTERN PetscErrorCode VecValidValues(Vec,PetscInt,PetscBool); > > > On Thu, 29 Jan 2015, Barry Smith wrote: > >> >> I have implemented Jed's excellant VecLockPush/Pop() idea into a branch and will be merging it into next today and then eventually into master. >> >> VecLockPush() puts a vector into read only state which can only be undone by the appropriate number of VecLockPop()s. Routines such as VecSetValues() and VecGetArray() check the read only state and generate errors when it is set. >> >> This means that everyone must be much more careful when using VecGetArray() and friends and default to VecGetArrayRead() and friends unless they are specifically changing the values. It also means that many more array variables need to be marked as const (which is always a good thing). I have updated the core PETSc with all these changes but users will need to change code and any outstanding branches may need these changes also to work cleanly with next. >> >> Barry >> >> It is a minor headache now but is a good move going forward. Why I didn't do it in 1994 I'll never know. >> >> >

1 0

Re: [petsc-dev] changes coming to PETSc master branch
by Satish Balay 30 Jan '15

30 Jan '15

There are nightlybuild errors with this. Perhaps the following is the fix? Satish ---------- diff --git a/include/petscvec.h b/include/petscvec.h index 1369ff0..3c751d7 100644 --- a/include/petscvec.h +++ b/include/petscvec.h @@ -457,9 +457,10 @@ PETSC_EXTERN PetscErrorCode VecLockPush(Vec); PETSC_EXTERN PetscErrorCode VecLockPop(Vec); #define VecLocked(x,arg) do {PetscInt _st; PetscErrorCode __ierr = VecLockGet(x,&_st); CHKERRQ(__ierr); if (_st > 0) SETERRQ1(PETSC_COMM_SELF,PETSC_ERR_ARG_WRONGSTATE," Vec is locked read only, argument # %d",arg);} while (0) #else -#define VecLockPush(x) do {} while (0) -#define VecLockPop(x) do {} while (0) -#define VecLocked(x,arg) do {} while (0) +#define VecLockGet(x,arg) *(arg) = 0 +#define VecLockPush(x) 0 +#define VecLockPop(x) 0 +#define VecLocked(x,arg) #endif PETSC_EXTERN PetscErrorCode VecValidValues(Vec,PetscInt,PetscBool); On Thu, 29 Jan 2015, Barry Smith wrote: > > I have implemented Jed's excellant VecLockPush/Pop() idea into a branch and will be merging it into next today and then eventually into master. > > VecLockPush() puts a vector into read only state which can only be undone by the appropriate number of VecLockPop()s. Routines such as VecSetValues() and VecGetArray() check the read only state and generate errors when it is set. > > This means that everyone must be much more careful when using VecGetArray() and friends and default to VecGetArrayRead() and friends unless they are specifically changing the values. It also means that many more array variables need to be marked as const (which is always a good thing). I have updated the core PETSc with all these changes but users will need to change code and any outstanding branches may need these changes also to work cleanly with next. > > Barry > > It is a minor headache now but is a good move going forward. Why I didn't do it in 1994 I'll never know. > >

1 0

Re: [petsc-dev] [petsc-users] Is PetscViewerBinary special?
by Dave May 30 Jan '15

30 Jan '15

Hi Barry, Okay - fair enough. Almost of all the code would be re-used with my suggestion. I hope you don't mind, I moved this discussion to the dev list as I wanted to propose a solution. What about this as an alternative? [1] I add PetscViewerSetFromOptions_Binary() [2] I add a setupcalled flag into PetscViewer_Binary [3] I modify PetscViewerFileSetName_Binary() to just set the file name string and defer actually opening of the file to within in a function PetscViewerSetUp_Binary(). Depending on whether mpiio is set we call (essentially) the current contents of PetscViewerFileSetName_MPIIO() or PetscViewerFileSetName_Binary(). However the parsing of options -viewer_binary_skip_info etc would be moved into PetscViewerSetFromOptions_Binary() [4] I modify the PetscViewerDestory_Binary() such that it calls the appropriate functions for mpiio or non-mpiio and remove PetscObjectComposeFunction() from PetscViewerBinarySetMPIIO_Binary() [5] PetscViewerSetUp_Binary() would be called at the end of PetscViewerSetFromOptions_Binary(), or at the beginning of any of the getters associated with PetscViewerBinary, e.g. PetscViewerBinaryGetDescriptor() and at the beginning of PetscViewerBinaryWrite() PetscViewerBinaryRead(). [6] PetscViewerBinaryOpen() would obviously call PetscViewerSetFromOptions_Binary(). Or does this approach sound like a giant hack? Probably a new operation for the PetscViewer (setup) would be a nicer way to go. I can put this in branch if you think it is worth while pursuing the approach I propose. Cheers Dave On 30 January 2015 at 14:56, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Dave, > > I did the mpiio hack originally and yes it is very ad hoc and could do > with a good reorganization. I am fine with accepting a branch that treats > the MPIIO one as a completely different class; the only reason not to do > this is if both classes have essentially the same code but no reuse > between them. > > Barry > > > On Jan 30, 2015, at 7:51 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > > > Thanks Matt. > > > > Given the PETSc way of doing things, I believe the following should be > possible: > > [1] attach an option prefix to a viewer > > [2] skip the header on some binary viewers > > [3] use mpiio for some binary viewers, but not all of them. > > > > However, it doesn't appear to be completely simple to allow this > behaviour. > > > > For instance, replacing > > ierr = > PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > with > > ierr = > PetscOptionsGetBool(((PetscObject)viewer)->prefix,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > won't work as an option prefix will never have been set. > > > > If I was to add a PetscViewerSetFromOptions_Binary(), I would have to > ensure that PetscViewerSetFromOptions() was called before > PetscViewerFileSetName() was called as the latter this triggers a swap of > the functions used to open binary file, e.g. from > PetscViewerFileSetName_Binary() to PetscViewerFileSetName_MPIIO() > > > > Would it be simpler and cleaner to have MPIIO be defined as an > independent implementation which was a sub-class of the binary class? > > > > Then we could use command line flags to switch between implementations > at runtime > > -xxx_viewer_type binary > > versus > > -xxx_viewer_type mpiio > > rather than having to use > > -xxx_viewer_type binary -viewer_binary_mpiio > > which has obvious short comings like forcing all binary viewers, > independent of the prefix to use mpiio. It would also allow the PetscViewer > object to be used in a manner which follows the standard PETSc pattern of: > XXCreate(), XXSetOptionsPrefix(), XXSetType(), XXSetFromOptions(). > > > > Then we could do this > > PetscViewerCreate() > > PetscViewerSetOptionsPrefix() > > PetscViewerSetType() > > PetscViewerFileSetMode() > > PetscViewerBinarySetSkipHeader() > > PetscViewerFileSetName() > > PetscViewerSetFromOptions() > > and it wouldn't matter which order SetName(), BinarySkipHeader() etc > were called. > > > > What do people think? > > > > > > Cheers > > Dave > > > > > > > > > > > > On 30 January 2015 at 13:56, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Fri, Jan 30, 2015 at 2:06 AM, Dave May <dave.mayhem23(a)gmail.com> > wrote: > > Hello, > > > > I've noticed the create function PetscViewerCreate_Binary() doesn't > appear to be using the options prefix attached to the PetscViewer. > > Specifically, I see on line 1276 of > > petsc-3.5.2/src/sys/classes/viewer/impls/binary/binv.c > > the following > > ierr = > PetscOptionsGetBool(NULL,"-viewer_binary_mpiio",&useMPIIO,NULL);CHKERRQ(ierr); > > > > Is this an oversight or something intentional? > > > > This is an oversight. > > > > Matt > > > > Are PetscViewers in general behaving such that they cannot be configured > independently of each other if > > PetscViewerSetOptionsPrefix() and PetscViewerSetFromOptions() are called? > > > > > > Cheers > > Dave > > > > > > > > -- > > 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

changes coming to PETSc master branch
by Barry Smith 29 Jan '15

29 Jan '15

I have implemented Jed's excellant VecLockPush/Pop() idea into a branch and will be merging it into next today and then eventually into master. VecLockPush() puts a vector into read only state which can only be undone by the appropriate number of VecLockPop()s. Routines such as VecSetValues() and VecGetArray() check the read only state and generate errors when it is set. This means that everyone must be much more careful when using VecGetArray() and friends and default to VecGetArrayRead() and friends unless they are specifically changing the values. It also means that many more array variables need to be marked as const (which is always a good thing). I have updated the core PETSc with all these changes but users will need to change code and any outstanding branches may need these changes also to work cleanly with next. Barry It is a minor headache now but is a good move going forward. Why I didn't do it in 1994 I'll never know.

1 0

Re: [petsc-dev] installing external packages as shared?
by Eric Chamberland 29 Jan '15

29 Jan '15

On 09/08/2014 06:08 PM, Jed Brown wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> When should we install external packages as shared, currently if >> —with-PACKAGENAME-shared is set or if —with-shared-libraries is set >> we do it for some packages (like MPICH). Other packages, such as >> hypre don’t build properly as shared. So my question is if >> —with-shared-libraries is set should be build the packages that can >> be built with shared libraries or should we build static unless >> specifically requested for that package? > > What does --download intend to be? > > 1. A general-purpose package manager bundled with PETSc. Installs > packages in a way that makes sense on the user's computer and is > fully-functional independent of PETSc. > > 2. A quick and dirty way of installing dependencies to be used by PETSc. > Not intended to be used independent from PETSc (though it might work). > Package manager functionality like upgrades and uninstall are not > provided. > > > If 1, then packages should be installed in the way that makes most sense > on the target computer, so shared libraries in most cases where it is > possible. This is a busy space with lots of competitors that rarely > play well together. If 2, then it's okay to always build static > libraries (with -fPIC) and link them into libpetsc.so (when libpetsc.so > is dynamic). > I'm kind of late, but here is a thought: We link about 350 different executables in 2 flavors (debug and opt), so having shared libraries is a major benefit for the linking time of these 700 little beasts... So I would plead for having shared libraries for external packages, at least when it is possible without too much pain for PETSc developers... thanks, Eric

1 0

Re: [petsc-dev] [PATCH] threadcomm: Fix initialization for THREADCOMM_PROD.
by Barry Smith 28 Jan '15

28 Jan '15

Fixed in master. Thank you Barry > On Jan 26, 2015, at 3:30 PM, Eric Bavier <bavier(a)cray.com> wrote: > > Hello PETSc devs, > > Here's a simple patch against the master branch. It should be self-explanatory. > > `~Eric<0001-threadcomm-Fix-initialization-for-THREADCOMM_PROD.patch>

1 0