April 2018 - petsc-dev - mailman3.cels.anl.gov

Error with --download-strumpack
by Junchao Zhang 24 Apr '18

24 Apr '18

Hi, Satish, This configure option --download-strumpack= https://github.com/pghysels/STRUMPACK/archive/v2.2.0.tar.gz does not work. It looks it is because the package uses upper case for its name. ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- Error during download/extract/detection of STRUMPACK: Looking for STRUMPACK at git.strumpack, hg.strumpack or a directory starting with ['strumpack'] --Junchao Zhang

1 0

Re: [petsc-dev] Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Smith, Barry F. 23 Apr '18

23 Apr '18

Let's just have the alt file for the chaco diffs and leave everything else the way it. I can't see the effort to change builds stuff worth it in this case. Barry > On Apr 23, 2018, at 2:13 PM, Balay, Satish <balay(a)mcs.anl.gov> wrote: > > I was thinking more in terms of: our download options should match > source distribution model of externalpackages [but not necessarily > build all components] > > I see chaco is primarily part of seacas and not distributed separately. > [and then seacas is redistributed in trilinos] > > So how about: > > --download-seacas [build chaco and exodusii] > > And remove the separate package support for exodusii and chaco [i.e > remove --download-exodusii --download-chaco] > > [and then somehow make the seacas build via trilinos match the standalone build] > > I see zoltan is distributed separately, in seacas and also in trilinos > [so current --download-zoltan is still ok?] > > ML is the odd one out - I guess we'll have to extract/repackage the > latest version from trilinos - and use it with --download-ml. > > Satish > > On Mon, 23 Apr 2018, Smith, Barry F. wrote: > >> >> Making people install all of Trilinos for just Chaco or just ML is just plain mean and we are not mean. >> >> Suitesparse is at least not huge and is well contained so just because we install all of it doesn't mean we should require the same route for Trilinos. >> >> Barry >> >> >> >>> On Apr 23, 2018, at 10:11 AM, Balay, Satish <balay(a)mcs.anl.gov> wrote: >>> >>> Ah - yes. I did check the difference in petsc code wrt >>> PETSC_HAVE_CHACO_INT_ASSIGNMENT - but didn't check the details inside >>> trilinos/chaco. So the available standalone chaco tarball is version >>> 2.2 but the version included inside seacas is 3.0.0 [with a switch >>> from short to int] >>> >>> We have these hierarchy of packages - and need to figure out a better >>> [install] interface so the same version is used irrespective of the >>> mode of install? >>> >>> Right now - --download-exodusii gets and installs seacas [with only >>> exodusii enabled] >>> >>> So we have: >>> >>> --download-ml --download-chaco --download-zoltan [separate packages] >>> >>> --download-exodusii [installs seacas - and enables only exodusii] >>> >>> --download-trilinos [installs trilinos which includes seacas(exodusii,chaco), ml - zoltan] >>> >>> since seacas is distributed separately and includes exodusii and chaco - have: >>> >>> --download-seacas=1 [with options exodusii=1,chaco=1 by default [or disabled?] >>> >>> --download-seacas=1 >>> --download-seacas=1 --download-seacas-exodusii=0 [only install chaco] >>> --download-seacas-chaco=0 [only install exodusii] >>> >>> [but zoltan, ml are not distributed separately?] >>> >>> Or should we always use trilinos? - if one wants any of the above >>> packages [a huge download]? and enable or disable selected >>> sub-components as desired? >>> >>> Another similar package is SuiteSparse. At some point we had install >>> for only sub-components(cholmod,umfpack) - and then merged them all >>> into --download-suitesparse. >>> >>> Satish >>> >>> On Mon, 23 Apr 2018, Vaclav Hapla wrote: >>> >>>> I can confirm --download-chaco vs --download-trilinos give different chaco partitioning - I can reproduce on my machine. So I made some investigation. >>>> >>>> PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. >>>> This macro makes difference only at 4 places: >>>> >>>> At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/plexpartition.c:1192: >>>> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) >>>> #include <chaco.h> >>>> #else >>>> /* Older versions of Chaco do not have an include file */ >>>> PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int *vwgts, >>>> float *ewgts, float *x, float *y, float *z, char *outassignname, >>>> char *outfilename, short *assignment, int architecture, int ndims_tot, >>>> int mesh_dims[3], double *goal, int global_method, int local_method, >>>> int rqi_flag, int vmax, int ndims, double eigtol, long seed); >>>> #endif >>>> >>>> At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/plexpartition.c:1227: >>>> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) >>>> int *assignment; >>>> #else >>>> short *assignment; >>>> #endif >>>> >>>> So it seems PETSc is not responsible for the different outputs. >>>> >>>> In Trilinos, Chaco is shipped within the Seacas package. The notice at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/seacas/#chaco> says >>>> "The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors." >>>> They also say >>>> "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h." >>>> Looking there, the version is 3.0.0. >>>> >>>> PETSc's configure --download-chaco gets this one: http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz <http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> >>>> It actually includes a git repo. There we can see it's the original author's version + some updates by Barry and Satish, mainly to avoid some name clashes. >>>> The original version is probably this one: https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.… <https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.…> >>>> Looking at the contents of the tarball, these sources data back to 2000. >>>> I tried comparing these two version but there are two many changes in formatting to identify crucial changes easily. But definitely these two versions differ and can give different results. >>>> >>>> The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c is testing HDF5 I/O with different formats and I just needed to somehow distribute the sequential mesh read from exodus file. So I will replace chaco by simple here. But still it's a question whether we want to do something about the confusing situation with Chaco. >>>> >>>> Vaclav >>>> >>>>> 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: >>>>> >>>>> On Sun, 22 Apr 2018, Smith, Barry F. wrote: >>>>> >>>>>>> It would be good to figure out exactly where the difference comes form >>>>>>> [wrt chaco from trilinos vs separate install of chaco - or some other >>>>>>> interaction from trilinos] >>>>>> >>>>>> Different random numbers being generated? >>>>> >>>>> Its trilinos vs non-trilinos build of packages - so I don't think its 'different random number generation' issue. >>>>> >>>>> Trilinos install does: >>>>> >>>>> if self.libraries.check(self.dlib, "interface"): >>>>> self.addDefine('HAVE_CHACO',1) >>>>> self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) >>>>> if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): >>>>> self.addDefine('HAVE_ML',1) >>>>> if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): >>>>> self.addDefine('HAVE_ZOLTAN',1) >>>>> if self.libraries.check(self.dlib, "ex_close"): >>>>> self.addDefine('HAVE_EXODUSII',1) >>>>> >>>>> >>>>> For one there is different chaco code in petsc based on this flag >>>>> HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the >>>>> difference. >>>>> >>>>> --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the >>>>> latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do >>>>> not know if chaco packaged by trilinos has changes that cause this >>>>> difference [clearly it added some change that resulted in us using the >>>>> flag HAVE_CHACO_INT_ASSIGNMENT] >>>>> >>>>> And then there is also exodus.. --download-exodus uses the latest >>>>> snapshot from https://github.com/gsjaardema/seacas/ >>>>> >>>>> Satish >>>> >>>> >>> >> >> >

1 0

Re: [petsc-dev] Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Matthew Knepley 23 Apr '18

23 Apr '18

On Mon, Apr 23, 2018 at 3:13 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > I was thinking more in terms of: our download options should match > source distribution model of externalpackages [but not necessarily > build all components] > > I see chaco is primarily part of seacas and not distributed separately. > [and then seacas is redistributed in trilinos] > Here is the problem with that. Chaco is not great. Its aggressively mediocre. The only reason to use it was its staggering lack of dependencies and simple build. Take that away and there is no reason whatsoever to have it. Matt > So how about: > > --download-seacas [build chaco and exodusii] > > And remove the separate package support for exodusii and chaco [i.e > remove --download-exodusii --download-chaco] > > [and then somehow make the seacas build via trilinos match the standalone > build] > > I see zoltan is distributed separately, in seacas and also in trilinos > [so current --download-zoltan is still ok?] > > ML is the odd one out - I guess we'll have to extract/repackage the > latest version from trilinos - and use it with --download-ml. > > Satish > > On Mon, 23 Apr 2018, Smith, Barry F. wrote: > > > > > Making people install all of Trilinos for just Chaco or just ML is > just plain mean and we are not mean. > > > > Suitesparse is at least not huge and is well contained so just > because we install all of it doesn't mean we should require the same route > for Trilinos. > > > > Barry > > > > > > > > > On Apr 23, 2018, at 10:11 AM, Balay, Satish <balay(a)mcs.anl.gov> wrote: > > > > > > Ah - yes. I did check the difference in petsc code wrt > > > PETSC_HAVE_CHACO_INT_ASSIGNMENT - but didn't check the details inside > > > trilinos/chaco. So the available standalone chaco tarball is version > > > 2.2 but the version included inside seacas is 3.0.0 [with a switch > > > from short to int] > > > > > > We have these hierarchy of packages - and need to figure out a better > > > [install] interface so the same version is used irrespective of the > > > mode of install? > > > > > > Right now - --download-exodusii gets and installs seacas [with only > > > exodusii enabled] > > > > > > So we have: > > > > > > --download-ml --download-chaco --download-zoltan [separate packages] > > > > > > --download-exodusii [installs seacas - and enables only exodusii] > > > > > > --download-trilinos [installs trilinos which includes > seacas(exodusii,chaco), ml - zoltan] > > > > > > since seacas is distributed separately and includes exodusii and chaco > - have: > > > > > > --download-seacas=1 [with options exodusii=1,chaco=1 by default [or > disabled?] > > > > > > --download-seacas=1 > > > --download-seacas=1 --download-seacas-exodusii=0 [only install chaco] > > > --download-seacas-chaco=0 [only install exodusii] > > > > > > [but zoltan, ml are not distributed separately?] > > > > > > Or should we always use trilinos? - if one wants any of the above > > > packages [a huge download]? and enable or disable selected > > > sub-components as desired? > > > > > > Another similar package is SuiteSparse. At some point we had install > > > for only sub-components(cholmod,umfpack) - and then merged them all > > > into --download-suitesparse. > > > > > > Satish > > > > > > On Mon, 23 Apr 2018, Vaclav Hapla wrote: > > > > > >> I can confirm --download-chaco vs --download-trilinos give different > chaco partitioning - I can reproduce on my machine. So I made some > investigation. > > >> > > >> PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. > > >> This macro makes difference only at 4 places: > > >> > > >> At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/ > plexpartition.c:1192: > > >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > > >> #include <chaco.h> > > >> #else > > >> /* Older versions of Chaco do not have an include file */ > > >> PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int > *vwgts, > > >> float *ewgts, float *x, float *y, float *z, char > *outassignname, > > >> char *outfilename, short *assignment, int > architecture, int ndims_tot, > > >> int mesh_dims[3], double *goal, int > global_method, int local_method, > > >> int rqi_flag, int vmax, int ndims, double eigtol, > long seed); > > >> #endif > > >> > > >> At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/ > plexpartition.c:1227: > > >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > > >> int *assignment; > > >> #else > > >> short *assignment; > > >> #endif > > >> > > >> So it seems PETSc is not responsible for the different outputs. > > >> > > >> In Trilinos, Chaco is shipped within the Seacas package. The notice > at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/ > seacas/#chaco> says > > >> "The short *assignment argument to the interface function has been > changed to int *assignment to permit decompositions with more than 32,768 > processors." > > >> They also say > > >> "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, > CHACO_VERSION_PATCH defines in chaco.h." > > >> Looking there, the version is 3.0.0. > > >> > > >> PETSc's configure --download-chaco gets this one: > http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz < > http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> > > >> It actually includes a git repo. There we can see it's the original > author's version + some updates by Barry and Satish, mainly to avoid some > name clashes. > > >> The original version is probably this one: > https://www3.cs.stonybrook.edu/~algorith/implement/chaco/ > distrib/Chaco-2.2.tar.gz <https://www3.cs.stonybrook. > edu/~algorith/implement/chaco/distrib/Chaco-2.2.tar.gz> > > >> Looking at the contents of the tarball, these sources data back to > 2000. > > >> I tried comparing these two version but there are two many changes in > formatting to identify crucial changes easily. But definitely these two > versions differ and can give different results. > > >> > > >> The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c > is testing HDF5 I/O with different formats and I just needed to somehow > distribute the sequential mesh read from exodus file. So I will replace > chaco by simple here. But still it's a question whether we want to do > something about the confusing situation with Chaco. > > >> > > >> Vaclav > > >> > > >>> 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: > > >>> > > >>> On Sun, 22 Apr 2018, Smith, Barry F. wrote: > > >>> > > >>>>> It would be good to figure out exactly where the difference comes > form > > >>>>> [wrt chaco from trilinos vs separate install of chaco - or some > other > > >>>>> interaction from trilinos] > > >>>> > > >>>> Different random numbers being generated? > > >>> > > >>> Its trilinos vs non-trilinos build of packages - so I don't think > its 'different random number generation' issue. > > >>> > > >>> Trilinos install does: > > >>> > > >>> if self.libraries.check(self.dlib, "interface"): > > >>> self.addDefine('HAVE_CHACO',1) > > >>> self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) > > >>> if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): > > >>> self.addDefine('HAVE_ML',1) > > >>> if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): > > >>> self.addDefine('HAVE_ZOLTAN',1) > > >>> if self.libraries.check(self.dlib, "ex_close"): > > >>> self.addDefine('HAVE_EXODUSII',1) > > >>> > > >>> > > >>> For one there is different chaco code in petsc based on this flag > > >>> HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the > > >>> difference. > > >>> > > >>> --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the > > >>> latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do > > >>> not know if chaco packaged by trilinos has changes that cause this > > >>> difference [clearly it added some change that resulted in us using > the > > >>> flag HAVE_CHACO_INT_ASSIGNMENT] > > >>> > > >>> And then there is also exodus.. --download-exodus uses the latest > > >>> snapshot from https://github.com/gsjaardema/seacas/ > > >>> > > >>> Satish > > >> > > >> > > > > > > > > > -- 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.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Satish Balay 23 Apr '18

23 Apr '18

I was thinking more in terms of: our download options should match source distribution model of externalpackages [but not necessarily build all components] I see chaco is primarily part of seacas and not distributed separately. [and then seacas is redistributed in trilinos] So how about: --download-seacas [build chaco and exodusii] And remove the separate package support for exodusii and chaco [i.e remove --download-exodusii --download-chaco] [and then somehow make the seacas build via trilinos match the standalone build] I see zoltan is distributed separately, in seacas and also in trilinos [so current --download-zoltan is still ok?] ML is the odd one out - I guess we'll have to extract/repackage the latest version from trilinos - and use it with --download-ml. Satish On Mon, 23 Apr 2018, Smith, Barry F. wrote: > > Making people install all of Trilinos for just Chaco or just ML is just plain mean and we are not mean. > > Suitesparse is at least not huge and is well contained so just because we install all of it doesn't mean we should require the same route for Trilinos. > > Barry > > > > > On Apr 23, 2018, at 10:11 AM, Balay, Satish <balay(a)mcs.anl.gov> wrote: > > > > Ah - yes. I did check the difference in petsc code wrt > > PETSC_HAVE_CHACO_INT_ASSIGNMENT - but didn't check the details inside > > trilinos/chaco. So the available standalone chaco tarball is version > > 2.2 but the version included inside seacas is 3.0.0 [with a switch > > from short to int] > > > > We have these hierarchy of packages - and need to figure out a better > > [install] interface so the same version is used irrespective of the > > mode of install? > > > > Right now - --download-exodusii gets and installs seacas [with only > > exodusii enabled] > > > > So we have: > > > > --download-ml --download-chaco --download-zoltan [separate packages] > > > > --download-exodusii [installs seacas - and enables only exodusii] > > > > --download-trilinos [installs trilinos which includes seacas(exodusii,chaco), ml - zoltan] > > > > since seacas is distributed separately and includes exodusii and chaco - have: > > > > --download-seacas=1 [with options exodusii=1,chaco=1 by default [or disabled?] > > > > --download-seacas=1 > > --download-seacas=1 --download-seacas-exodusii=0 [only install chaco] > > --download-seacas-chaco=0 [only install exodusii] > > > > [but zoltan, ml are not distributed separately?] > > > > Or should we always use trilinos? - if one wants any of the above > > packages [a huge download]? and enable or disable selected > > sub-components as desired? > > > > Another similar package is SuiteSparse. At some point we had install > > for only sub-components(cholmod,umfpack) - and then merged them all > > into --download-suitesparse. > > > > Satish > > > > On Mon, 23 Apr 2018, Vaclav Hapla wrote: > > > >> I can confirm --download-chaco vs --download-trilinos give different chaco partitioning - I can reproduce on my machine. So I made some investigation. > >> > >> PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. > >> This macro makes difference only at 4 places: > >> > >> At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/plexpartition.c:1192: > >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > >> #include <chaco.h> > >> #else > >> /* Older versions of Chaco do not have an include file */ > >> PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int *vwgts, > >> float *ewgts, float *x, float *y, float *z, char *outassignname, > >> char *outfilename, short *assignment, int architecture, int ndims_tot, > >> int mesh_dims[3], double *goal, int global_method, int local_method, > >> int rqi_flag, int vmax, int ndims, double eigtol, long seed); > >> #endif > >> > >> At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/plexpartition.c:1227: > >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > >> int *assignment; > >> #else > >> short *assignment; > >> #endif > >> > >> So it seems PETSc is not responsible for the different outputs. > >> > >> In Trilinos, Chaco is shipped within the Seacas package. The notice at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/seacas/#chaco> says > >> "The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors." > >> They also say > >> "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h." > >> Looking there, the version is 3.0.0. > >> > >> PETSc's configure --download-chaco gets this one: http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz <http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> > >> It actually includes a git repo. There we can see it's the original author's version + some updates by Barry and Satish, mainly to avoid some name clashes. > >> The original version is probably this one: https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.… <https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.…> > >> Looking at the contents of the tarball, these sources data back to 2000. > >> I tried comparing these two version but there are two many changes in formatting to identify crucial changes easily. But definitely these two versions differ and can give different results. > >> > >> The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c is testing HDF5 I/O with different formats and I just needed to somehow distribute the sequential mesh read from exodus file. So I will replace chaco by simple here. But still it's a question whether we want to do something about the confusing situation with Chaco. > >> > >> Vaclav > >> > >>> 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: > >>> > >>> On Sun, 22 Apr 2018, Smith, Barry F. wrote: > >>> > >>>>> It would be good to figure out exactly where the difference comes form > >>>>> [wrt chaco from trilinos vs separate install of chaco - or some other > >>>>> interaction from trilinos] > >>>> > >>>> Different random numbers being generated? > >>> > >>> Its trilinos vs non-trilinos build of packages - so I don't think its 'different random number generation' issue. > >>> > >>> Trilinos install does: > >>> > >>> if self.libraries.check(self.dlib, "interface"): > >>> self.addDefine('HAVE_CHACO',1) > >>> self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) > >>> if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): > >>> self.addDefine('HAVE_ML',1) > >>> if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): > >>> self.addDefine('HAVE_ZOLTAN',1) > >>> if self.libraries.check(self.dlib, "ex_close"): > >>> self.addDefine('HAVE_EXODUSII',1) > >>> > >>> > >>> For one there is different chaco code in petsc based on this flag > >>> HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the > >>> difference. > >>> > >>> --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the > >>> latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do > >>> not know if chaco packaged by trilinos has changes that cause this > >>> difference [clearly it added some change that resulted in us using the > >>> flag HAVE_CHACO_INT_ASSIGNMENT] > >>> > >>> And then there is also exodus.. --download-exodus uses the latest > >>> snapshot from https://github.com/gsjaardema/seacas/ > >>> > >>> Satish > >> > >> > > > >

1 0

Re: [petsc-dev] Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Smith, Barry F. 23 Apr '18

23 Apr '18

Making people install all of Trilinos for just Chaco or just ML is just plain mean and we are not mean. Suitesparse is at least not huge and is well contained so just because we install all of it doesn't mean we should require the same route for Trilinos. Barry > On Apr 23, 2018, at 10:11 AM, Balay, Satish <balay(a)mcs.anl.gov> wrote: > > Ah - yes. I did check the difference in petsc code wrt > PETSC_HAVE_CHACO_INT_ASSIGNMENT - but didn't check the details inside > trilinos/chaco. So the available standalone chaco tarball is version > 2.2 but the version included inside seacas is 3.0.0 [with a switch > from short to int] > > We have these hierarchy of packages - and need to figure out a better > [install] interface so the same version is used irrespective of the > mode of install? > > Right now - --download-exodusii gets and installs seacas [with only > exodusii enabled] > > So we have: > > --download-ml --download-chaco --download-zoltan [separate packages] > > --download-exodusii [installs seacas - and enables only exodusii] > > --download-trilinos [installs trilinos which includes seacas(exodusii,chaco), ml - zoltan] > > since seacas is distributed separately and includes exodusii and chaco - have: > > --download-seacas=1 [with options exodusii=1,chaco=1 by default [or disabled?] > > --download-seacas=1 > --download-seacas=1 --download-seacas-exodusii=0 [only install chaco] > --download-seacas-chaco=0 [only install exodusii] > > [but zoltan, ml are not distributed separately?] > > Or should we always use trilinos? - if one wants any of the above > packages [a huge download]? and enable or disable selected > sub-components as desired? > > Another similar package is SuiteSparse. At some point we had install > for only sub-components(cholmod,umfpack) - and then merged them all > into --download-suitesparse. > > Satish > > On Mon, 23 Apr 2018, Vaclav Hapla wrote: > >> I can confirm --download-chaco vs --download-trilinos give different chaco partitioning - I can reproduce on my machine. So I made some investigation. >> >> PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. >> This macro makes difference only at 4 places: >> >> At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/plexpartition.c:1192: >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) >> #include <chaco.h> >> #else >> /* Older versions of Chaco do not have an include file */ >> PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int *vwgts, >> float *ewgts, float *x, float *y, float *z, char *outassignname, >> char *outfilename, short *assignment, int architecture, int ndims_tot, >> int mesh_dims[3], double *goal, int global_method, int local_method, >> int rqi_flag, int vmax, int ndims, double eigtol, long seed); >> #endif >> >> At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/plexpartition.c:1227: >> #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) >> int *assignment; >> #else >> short *assignment; >> #endif >> >> So it seems PETSc is not responsible for the different outputs. >> >> In Trilinos, Chaco is shipped within the Seacas package. The notice at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/seacas/#chaco> says >> "The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors." >> They also say >> "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h." >> Looking there, the version is 3.0.0. >> >> PETSc's configure --download-chaco gets this one: http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz <http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> >> It actually includes a git repo. There we can see it's the original author's version + some updates by Barry and Satish, mainly to avoid some name clashes. >> The original version is probably this one: https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.… <https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.…> >> Looking at the contents of the tarball, these sources data back to 2000. >> I tried comparing these two version but there are two many changes in formatting to identify crucial changes easily. But definitely these two versions differ and can give different results. >> >> The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c is testing HDF5 I/O with different formats and I just needed to somehow distribute the sequential mesh read from exodus file. So I will replace chaco by simple here. But still it's a question whether we want to do something about the confusing situation with Chaco. >> >> Vaclav >> >>> 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: >>> >>> On Sun, 22 Apr 2018, Smith, Barry F. wrote: >>> >>>>> It would be good to figure out exactly where the difference comes form >>>>> [wrt chaco from trilinos vs separate install of chaco - or some other >>>>> interaction from trilinos] >>>> >>>> Different random numbers being generated? >>> >>> Its trilinos vs non-trilinos build of packages - so I don't think its 'different random number generation' issue. >>> >>> Trilinos install does: >>> >>> if self.libraries.check(self.dlib, "interface"): >>> self.addDefine('HAVE_CHACO',1) >>> self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) >>> if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): >>> self.addDefine('HAVE_ML',1) >>> if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): >>> self.addDefine('HAVE_ZOLTAN',1) >>> if self.libraries.check(self.dlib, "ex_close"): >>> self.addDefine('HAVE_EXODUSII',1) >>> >>> >>> For one there is different chaco code in petsc based on this flag >>> HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the >>> difference. >>> >>> --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the >>> latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do >>> not know if chaco packaged by trilinos has changes that cause this >>> difference [clearly it added some change that resulted in us using the >>> flag HAVE_CHACO_INT_ASSIGNMENT] >>> >>> And then there is also exodus.. --download-exodus uses the latest >>> snapshot from https://github.com/gsjaardema/seacas/ >>> >>> Satish >> >> >

1 0

Re: [petsc-dev] PETSc blame digest (next) 2018-04-23
by Smith, Barry F. 23 Apr '18

23 Apr '18

Dang, I fixed this yesterday but then forgot to merge the branch barry/bugfix-petscformatconvert into next for testing. Barry > On Apr 23, 2018, at 7:28 AM, PETSc checkBuilds <petsc-checkbuilds(a)mcs.anl.gov> wrote: > > > > Dear PETSc developer, > > This email contains listings of contributions attributed to you by > `git blame` that caused compiler errors or warnings in PETSc automated > testing. Follow the links to see the full log files. Please attempt to fix > the issues promptly or let us know at petsc-dev(a)mcs.anl.gov if you are unable > to resolve the issues. > > Thanks, > The PETSc development team > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/14416c0 > Insure PetscPrintf(), PetscVPrintfDefault(), PetscSynchronizedPrintf(), PetscSynchronizedFPrintf(), and PetscViewerASCIIPrintf() handle printed strings longer than the default buffer size of 8*1024 bytes properly > > src/sys/classes/viewer/impls/ascii/filev.c:991 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /usr/home/balay/petsc.next/src/sys/classes/viewer/impls/ascii/filev.c:991:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /home/sandbox/petsc/petsc.next-3/src/sys/classes/viewer/impls/ascii/filev.c:991:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next-2/src/sys/classes/viewer/impls/ascii/filev.c:991:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next/src/sys/classes/viewer/impls/ascii/filev.c:991:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next-3/src/sys/classes/viewer/impls/ascii/filev.c:991:43: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /usr/home/balay/petsc.next-2/src/sys/classes/viewer/impls/ascii/filev.c:991:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] > > src/sys/fileio/mprint.c:785 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next/src/sys/fileio/mprint.c:785:17: error: 'len' undeclared (first use in this function) > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next/src/sys/fileio/mprint.c:785:12: warning: unused variable 'buff' [-Wunused-variable] > > ---- > > warnings attributed to commit https://bitbucket.org/petsc/petsc/commits/df41390 > fixed problem with Matlab being nonresponsive when run with -nodisplay and built with MPI > > src/sys/fileio/mprint.c:788 > [http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2018/04/23/build_next_…] > /sandbox/petsc/petsc.next/src/sys/fileio/mprint.c:788:20: error: 'buf' undeclared (first use in this function) > > ---- > To opt-out from receiving these messages - send a request to petsc-dev(a)mcs.anl.gov.

1 0

Re: [petsc-dev] Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Satish Balay 23 Apr '18

23 Apr '18

Ah - yes. I did check the difference in petsc code wrt PETSC_HAVE_CHACO_INT_ASSIGNMENT - but didn't check the details inside trilinos/chaco. So the available standalone chaco tarball is version 2.2 but the version included inside seacas is 3.0.0 [with a switch from short to int] We have these hierarchy of packages - and need to figure out a better [install] interface so the same version is used irrespective of the mode of install? Right now - --download-exodusii gets and installs seacas [with only exodusii enabled] So we have: --download-ml --download-chaco --download-zoltan [separate packages] --download-exodusii [installs seacas - and enables only exodusii] --download-trilinos [installs trilinos which includes seacas(exodusii,chaco), ml - zoltan] since seacas is distributed separately and includes exodusii and chaco - have: --download-seacas=1 [with options exodusii=1,chaco=1 by default [or disabled?] --download-seacas=1 --download-seacas=1 --download-seacas-exodusii=0 [only install chaco] --download-seacas-chaco=0 [only install exodusii] [but zoltan, ml are not distributed separately?] Or should we always use trilinos? - if one wants any of the above packages [a huge download]? and enable or disable selected sub-components as desired? Another similar package is SuiteSparse. At some point we had install for only sub-components(cholmod,umfpack) - and then merged them all into --download-suitesparse. Satish On Mon, 23 Apr 2018, Vaclav Hapla wrote: > I can confirm --download-chaco vs --download-trilinos give different chaco partitioning - I can reproduce on my machine. So I made some investigation. > > PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. > This macro makes difference only at 4 places: > > At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/plexpartition.c:1192: > #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > #include <chaco.h> > #else > /* Older versions of Chaco do not have an include file */ > PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int *vwgts, > float *ewgts, float *x, float *y, float *z, char *outassignname, > char *outfilename, short *assignment, int architecture, int ndims_tot, > int mesh_dims[3], double *goal, int global_method, int local_method, > int rqi_flag, int vmax, int ndims, double eigtol, long seed); > #endif > > At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/plexpartition.c:1227: > #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) > int *assignment; > #else > short *assignment; > #endif > > So it seems PETSc is not responsible for the different outputs. > > In Trilinos, Chaco is shipped within the Seacas package. The notice at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/seacas/#chaco> says > "The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors." > They also say > "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h." > Looking there, the version is 3.0.0. > > PETSc's configure --download-chaco gets this one: http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz <http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> > It actually includes a git repo. There we can see it's the original author's version + some updates by Barry and Satish, mainly to avoid some name clashes. > The original version is probably this one: https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.… <https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.…> > Looking at the contents of the tarball, these sources data back to 2000. > I tried comparing these two version but there are two many changes in formatting to identify crucial changes easily. But definitely these two versions differ and can give different results. > > The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c is testing HDF5 I/O with different formats and I just needed to somehow distribute the sequential mesh read from exodus file. So I will replace chaco by simple here. But still it's a question whether we want to do something about the confusing situation with Chaco. > > Vaclav > > > 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: > > > > On Sun, 22 Apr 2018, Smith, Barry F. wrote: > > > >>> It would be good to figure out exactly where the difference comes form > >>> [wrt chaco from trilinos vs separate install of chaco - or some other > >>> interaction from trilinos] > >> > >> Different random numbers being generated? > > > > Its trilinos vs non-trilinos build of packages - so I don't think its 'different random number generation' issue. > > > > Trilinos install does: > > > > if self.libraries.check(self.dlib, "interface"): > > self.addDefine('HAVE_CHACO',1) > > self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) > > if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): > > self.addDefine('HAVE_ML',1) > > if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): > > self.addDefine('HAVE_ZOLTAN',1) > > if self.libraries.check(self.dlib, "ex_close"): > > self.addDefine('HAVE_EXODUSII',1) > > > > > > For one there is different chaco code in petsc based on this flag > > HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the > > difference. > > > > --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the > > latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do > > not know if chaco packaged by trilinos has changes that cause this > > difference [clearly it added some change that resulted in us using the > > flag HAVE_CHACO_INT_ASSIGNMENT] > > > > And then there is also exodus.. --download-exodus uses the latest > > snapshot from https://github.com/gsjaardema/seacas/ > > > > Satish > >

1 0

Chaco from --download-chaco vs --download-trilinos (Re: broken stuff in next for many days)
by Vaclav Hapla 23 Apr '18

23 Apr '18

I can confirm --download-chaco vs --download-trilinos give different chaco partitioning - I can reproduce on my machine. So I made some investigation. PETSC_HAVE_CHACO_INT_ASSIGNMENT is set only for --download-trilinos. This macro makes difference only at 4 places: At src/mat/partition/impls/chaco/chaco.c:8 and src/dm/impls/plex/plexpartition.c:1192: #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) #include <chaco.h> #else /* Older versions of Chaco do not have an include file */ PETSC_EXTERN int interface(int nvtxs, int *start, int *adjacency, int *vwgts, float *ewgts, float *x, float *y, float *z, char *outassignname, char *outfilename, short *assignment, int architecture, int ndims_tot, int mesh_dims[3], double *goal, int global_method, int local_method, int rqi_flag, int vmax, int ndims, double eigtol, long seed); #endif At src/mat/partition/impls/chaco/chaco.c:68 and src/dm/impls/plex/plexpartition.c:1227: #if defined(PETSC_HAVE_CHACO_INT_ASSIGNMENT) int *assignment; #else short *assignment; #endif So it seems PETSc is not responsible for the different outputs. In Trilinos, Chaco is shipped within the Seacas package. The notice at http://gsjaardema.github.io/seacas/#chaco <http://gsjaardema.github.io/seacas/#chaco> says "The short *assignment argument to the interface function has been changed to int *assignment to permit decompositions with more than 32,768 processors." They also say "There are also now a CHACO_VERSION_MAJOR, CHACO_VERSION_MINOR, CHACO_VERSION_PATCH defines in chaco.h." Looking there, the version is 3.0.0. PETSc's configure --download-chaco gets this one: http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz <http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p2.tar.gz> It actually includes a git repo. There we can see it's the original author's version + some updates by Barry and Satish, mainly to avoid some name clashes. The original version is probably this one: https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.… <https://www3.cs.stonybrook.edu/~algorith/implement/chaco/distrib/Chaco-2.2.…> Looking at the contents of the tarball, these sources data back to 2000. I tried comparing these two version but there are two many changes in formatting to identify crucial changes easily. But definitely these two versions differ and can give different results. The main intent of my tests in src/dm/impls/plex/examples/tutorials/ex5.c is testing HDF5 I/O with different formats and I just needed to somehow distribute the sequential mesh read from exodus file. So I will replace chaco by simple here. But still it's a question whether we want to do something about the confusing situation with Chaco. Vaclav > 22. 4. 2018 v 17:56, Satish Balay <balay(a)mcs.anl.gov>: > > On Sun, 22 Apr 2018, Smith, Barry F. wrote: > >>> It would be good to figure out exactly where the difference comes form >>> [wrt chaco from trilinos vs separate install of chaco - or some other >>> interaction from trilinos] >> >> Different random numbers being generated? > > Its trilinos vs non-trilinos build of packages - so I don't think its 'different random number generation' issue. > > Trilinos install does: > > if self.libraries.check(self.dlib, "interface"): > self.addDefine('HAVE_CHACO',1) > self.addDefine('HAVE_CHACO_INT_ASSIGNMENT',1) > if self.libraries.check(self.dlib, "ML_Set_PrintLevel"): > self.addDefine('HAVE_ML',1) > if self.libraries.check(self.dlib, "Zoltan_LB_Partition"): > self.addDefine('HAVE_ZOLTAN',1) > if self.libraries.check(self.dlib, "ex_close"): > self.addDefine('HAVE_EXODUSII',1) > > > For one there is different chaco code in petsc based on this flag > HAVE_CHACO_INT_ASSIGNMENT. Its not clear to me if this is causing the > difference. > > --download-chaco is using 'Chaco-2.2-p2.tar.gz'. This matches the > latest chaco tarball from their website [Chaco-2.2.tar.gz]. So I do > not know if chaco packaged by trilinos has changes that cause this > difference [clearly it added some change that resulted in us using the > flag HAVE_CHACO_INT_ASSIGNMENT] > > And then there is also exodus.. --download-exodus uses the latest > snapshot from https://github.com/gsjaardema/seacas/ > > Satish

1 0

Re: [petsc-dev] PetscOptions defaults after PetscInitialize
by Matthew Knepley 22 Apr '18

22 Apr '18

On Sun, Apr 22, 2018 at 8:54 PM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > On Apr 22, 2018, at 7:45 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > > > > > Yuck, I think a far better user API is that PetscOptionsInsertFile() > be callable before PetscInitialize(). The problem is that people have > shoveled so much post-PetscInitialize() code into PetscOptionsInsertFile() > over the years that stripping it all out would be painful. Maybe get a > simplier pre- 2005 version of the routine and strip out the > post-PetscInitialize() material? > > > > You want every rank to open the file independently? Or > > PetscOptionsInsertFile somehow caches the file contents without using > > PetscMalloc and broadcasts it after reaching PetscInitialize? That > > seems a bit crazy. > > > > I am not for this "before PetcInitialize" strategy at all. > > Why not. It was just stupidity on my part 20 years ago that I didn't > think to make the various set options functions callable before > PetscInitialize(). Better just to fix that oversight. > > > > > However, I do think its far too fat. It initializes everything we can > think of without > > giving the user and entry points in to customize it. That is > compiler-level user disempowerment. > > > > I would rather see us rearchitect Init() so that you have better control > over options, logging, > > CUDA, and all the other initializations hiding in there. > > Make a concrete proposal. "better control" is pretty vague. We break up PetscInitialize() into - Lightweight initialization, PetscInit(), that does not - Process the command line - Init logging - Init CUDA - Do any other package-type inits - Inits of the various packages So PetscInitialize() would still do the same job. However, people wanting to do special processing can call the lightweight init, then configure the packages as they please, and then the package init loop. Matt > > > > Matt > > > > > Barry > > > > > > > > >> On Apr 22, 2018, at 5:54 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > >> > > >> For users that read their own configuration files and/or choose > > >> PetscOptionsInsertFile after PetscInitialize, we don't have a good way > > >> to avoid overwriting PETSC_OPTIONS or command-line options. The user > > >> could manually find argv and the environment variable, but that's a > poor > > >> abstraction. Should PetscOptionsInsertFile learn how to behave so as > to > > >> add new entries to the options database, but not supersede any that > > >> already exist? > > > > > > > > -- > > 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/ > > -- 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.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] PetscOptions defaults after PetscInitialize
by Smith, Barry F. 22 Apr '18

22 Apr '18

> On Apr 22, 2018, at 7:45 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Sun, Apr 22, 2018 at 8:41 PM, Jed Brown <jed(a)jedbrown.org> wrote: > "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > > > Yuck, I think a far better user API is that PetscOptionsInsertFile() be callable before PetscInitialize(). The problem is that people have shoveled so much post-PetscInitialize() code into PetscOptionsInsertFile() over the years that stripping it all out would be painful. Maybe get a simplier pre- 2005 version of the routine and strip out the post-PetscInitialize() material? > > You want every rank to open the file independently? Or > PetscOptionsInsertFile somehow caches the file contents without using > PetscMalloc and broadcasts it after reaching PetscInitialize? That > seems a bit crazy. > > I am not for this "before PetcInitialize" strategy at all. Why not. It was just stupidity on my part 20 years ago that I didn't think to make the various set options functions callable before PetscInitialize(). Better just to fix that oversight. > > However, I do think its far too fat. It initializes everything we can think of without > giving the user and entry points in to customize it. That is compiler-level user disempowerment. > > I would rather see us rearchitect Init() so that you have better control over options, logging, > CUDA, and all the other initializations hiding in there. Make a concrete proposal. "better control" is pretty vague. > > Matt > > > Barry > > > > > >> On Apr 22, 2018, at 5:54 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > >> For users that read their own configuration files and/or choose > >> PetscOptionsInsertFile after PetscInitialize, we don't have a good way > >> to avoid overwriting PETSC_OPTIONS or command-line options. The user > >> could manually find argv and the environment variable, but that's a poor > >> abstraction. Should PetscOptionsInsertFile learn how to behave so as to > >> add new entries to the options database, but not supersede any that > >> already exist? > > > > -- > 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/

1 0