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

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 25 Nov '09

25 Nov '09

On Nov 25, 2009, at 1:03 PM, Lisandro Dalcin wrote: > On Wed, Nov 25, 2009 at 3:19 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> >> Lisandro, >> >> That change will certainly NOT be reverted. PETSC_ARCH_NAME! >> what the >> heck kind of variable name is that? >> > > I agree the name could be messy or misleading. It is confusing because then PETSc has a PETSC_ARCH and a PETSC_ARCH_NAME variable and having two very similar names with related or identical functionality adds unneeded complexity. The whole point of --prefix is to eliminate the need for and concept of PETSC_ARCH, so to have it still be there (in that you need PETSC_ARCH_NAME) is bizarre and confusing. > But so is PETSC_ARCH, > which should actually be something like PETSC_CONF, right? > >> >> I need to understand the reason for PETSC_ARCH_NAME, then we >> can come up >> with some solution. > > OK. Let see. > >> What is the difference between >> PETSC_ARCH_NAME and PETSC_ARCH? >> > > None > >> Is it only needed when --prefix is used (so >> PETSC_ARCH does not exist), > > Yes. > >> if so, exactly why is it needed, the whole idea >> behind --prefix is to eliminate PETSC_ARCH, > > In the particular case of petsc4py, the Python extension module get's > installed as "lib/$PETSC_ARCH/PETSc.so". Then, for --prefix installs > of PETSc, I use the PETSC_ARCH_NAME (obtained from parsing makefiles, > as for many other configuration stuff). > >> >> so why is it needed? How is >> PETSC_ARCH_NAME used? >> > > I can certainly change my way of doing things in petsc4py. Perhaps I > should install as "lib/PETSc.so" for --prefix PETSc builds? Absolutely, the PETSC_ARCH should NOT be in the path there. By keeping the $PETSC_ARCH around when using the --prefix you are totally abusing the whole concept of --prefix and have some weird half-assed creature that is not really traditional PETSc or --prefix style. You are doing the --prefix stuff wrong (see my note below). > > I said this before, but let's go one more time: I find --prefix > installs of PETSc a bit useless for general-purpose installations. > Supose as sysadmin "make install" PETSc in a cluster. She likely built > using a C as language, double precision real scalars, 32bit integers, > (dbg/opt?). Such configuration does not fit all applications. Some > users may require C++, other may want complex, others may want to run > her own codes with a debug version. Then I see VERY little point on > --prefix builds of PETSc. Moreover, in our machines at CIMEC I > maintain central installations of PETSc at /usr/local/petsc/3.0.0. > This is not done at all with --prefix and "make install", instead, > "/usr/local/petsc/3.0.0" is a HG clone of release-3.0.0. > > For all these reasons, petsc4py stills support clearly separated > lib/$PETSC_ARCH/PETSc.so ext modules. For example, switching from > debug to optimized is just a matter of "export > PETSC_ARCH=opt-arch-name" and "python script.py". Perhaps now it is > the time to change a bit this, but I certainly need some > advice/discussion/comments from your side. > I do agree with your about --prefix. It is pandering to the crowd of "how gnu does things is the best and only way things should ever be done and if you don't do it that way then you are a complete idiot" school. But the reason we support it is that its is very commonly asked for and EXPECTED by many, many people. It is a hopeless cause to convince these people that our model is better. I ignored this crowd for many, many years but finally broke down and figured out a fairly reasonable (though perhaps not perfect) way of doing it the "gnu way" also so the many people who live and die with the "./configure -- prefix; make ; make install" are happy and can just do their approach (even though it is a silly and bad model). So basically I am asking you and Jose to support the traditional PETSc approach and the pure --prefix approach and not have some intermediate thing that does not fully follow the GNU --prefix model. Barry > > -- > Lisandro Dalcín > --------------- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 25 Nov '09

25 Nov '09

On Nov 25, 2009, at 12:39 PM, Jose E. Roman wrote: > Barry, > > I think the use of PETSC_ARCH_NAME is motivated by a request I sent > in December last year, see http://lists.mcs.anl.gov/pipermail/petsc-dev/2008-December/001120.html > Ok, here is the message: SLEPc's configure.py uses the value of $PETSC_ARCH in order to setup everything for installation. We never had a $SLEPC_ARCH variable because our configure.py does not add platform-dependent functionality. Now the problem comes when PETSc has been configured with --prefix and installed with make install. In that case, $PETSC_ARCH is no longer available and SLEPc's configure.py is in trouble. A simple workaround would be that PETSc's configure (or make install) would add a variable (e.g. PETSC_ARCH_NAME) in file petscvariables. We parse this file so the arch name would be readily available even if $PETSC_ARCH is undefined. Can someone do this? Other solutions are welcome. Why does SLEPc's configure.py need to know PETSC_ARCH? PETSC_ARCH is a just a string that the user made up; in the --prefix case it means nothing at all and has no information associated with it. If you are installing a SLEPC based on a --prefix install of PETSc, you can just make up any PETSC_ARCH and use it doing your ./configure and make. If you are also doing a --prefix for SLEPC (which is likely when PETSc was done with --prefix) then once you have done make install the need for that PETSC_ARCH is gone. If you are not doing a -- prefix for SLEPc then that PETSC_ARCH is what the user will need to use when they use the SLEPc. Does this not work for some reason? Barry > We use it when configuring SLEPc with a prefix-based PETSc. If you > remove this variable, we will have to think about an alternative way > of supporting that case. > > Jose > > > On 25/11/2009, Barry Smith wrote: > >> >> Lisandro, >> >> That change will certainly NOT be reverted. PETSC_ARCH_NAME! >> what the heck kind of variable name is that? >> >> I need to understand the reason for PETSC_ARCH_NAME, then we can >> come up with some solution. What is the difference between >> PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is >> used (so PETSC_ARCH does not exist), if so, exactly why is it >> needed, the whole idea behind --prefix is to eliminate PETSC_ARCH, >> so why is it needed? How is PETSC_ARCH_NAME used? >> >> Barry >> >> >> >> On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote: >> >>> Barry, an outcome of the two changesets below: >>> >>> changeset: 14451:b289577caf8f >>> user: barrysmith(a)bsmith-laptop.mcs.anl.gov >>> date: Mon Oct 19 16:31:16 2009 -0500 >>> summary: update to install.py to ONLY use RDict.db (and not >>> command line) >>> >>> changeset: 14383:447d34bd2d4b >>> user: barrysmith(a)bsmith-laptop.mcs.anl.gov >>> date: Thu Oct 08 16:33:59 2009 -0500 >>> summary: finished cleaning up makefiles, moved >>> charactoristic.h to >>> include location standard place where it is easy to use >>> >>> >>> was that these two lines in config/PETSc/utilities/arch.py were >>> removed: >>> >>> # SLEPc configure need this info >>> self.addMakeMacro('PETSC_ARCH_NAME',self.arch) >>> >>> >>> SLEPc and petsc4py/slepc4py/tao4py relies on this variable being >>> defined in makefiles. There is now a new way to get the original >>> name >>> of the build-time $PETSC_ARCH? If not, any chance this change >>> could be >>> reverted? >>> >>> -- >>> Lisandro Dalcín >>> --------------- >>> Centro Internacional de Métodos Computacionales en Ingeniería >>> (CIMEC) >>> Instituto de Desarrollo Tecnológico para la Industria Química >>> (INTEC) >>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) >>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >> >

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 25 Nov '09

25 Nov '09

On Wed, Nov 25, 2009 at 3:19 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Lisandro, > > That change will certainly NOT be reverted. PETSC_ARCH_NAME! what the > heck kind of variable name is that? > I agree the name could be messy or misleading. But so is PETSC_ARCH, which should actually be something like PETSC_CONF, right? > > I need to understand the reason for PETSC_ARCH_NAME, then we can come up > with some solution. OK. Let see. > What is the difference between > PETSC_ARCH_NAME and PETSC_ARCH? > None > Is it only needed when --prefix is used (so > PETSC_ARCH does not exist), Yes. > if so, exactly why is it needed, the whole idea > behind --prefix is to eliminate PETSC_ARCH, In the particular case of petsc4py, the Python extension module get's installed as "lib/$PETSC_ARCH/PETSc.so". Then, for --prefix installs of PETSc, I use the PETSC_ARCH_NAME (obtained from parsing makefiles, as for many other configuration stuff). > > so why is it needed? How is > PETSC_ARCH_NAME used? > I can certainly change my way of doing things in petsc4py. Perhaps I should install as "lib/PETSc.so" for --prefix PETSc builds? I said this before, but let's go one more time: I find --prefix installs of PETSc a bit useless for general-purpose installations. Supose as sysadmin "make install" PETSc in a cluster. She likely built using a C as language, double precision real scalars, 32bit integers, (dbg/opt?). Such configuration does not fit all applications. Some users may require C++, other may want complex, others may want to run her own codes with a debug version. Then I see VERY little point on --prefix builds of PETSc. Moreover, in our machines at CIMEC I maintain central installations of PETSc at /usr/local/petsc/3.0.0. This is not done at all with --prefix and "make install", instead, "/usr/local/petsc/3.0.0" is a HG clone of release-3.0.0. For all these reasons, petsc4py stills support clearly separated lib/$PETSC_ARCH/PETSc.so ext modules. For example, switching from debug to optimized is just a matter of "export PETSC_ARCH=opt-arch-name" and "python script.py". Perhaps now it is the time to change a bit this, but I certainly need some advice/discussion/comments from your side. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Test mails
by Matthew Knepley 25 Nov '09

25 Nov '09

I think we should make the log files into links in the test emails. Satish, which scripts generates these? Thanks, Matt -- 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: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Jose E. Roman 25 Nov '09

25 Nov '09

Barry, I think the use of PETSC_ARCH_NAME is motivated by a request I sent in December last year, see http://lists.mcs.anl.gov/pipermail/petsc-dev/2008-December/001120.html We use it when configuring SLEPc with a prefix-based PETSc. If you remove this variable, we will have to think about an alternative way of supporting that case. Jose On 25/11/2009, Barry Smith wrote: > > Lisandro, > > That change will certainly NOT be reverted. PETSC_ARCH_NAME! > what the heck kind of variable name is that? > > I need to understand the reason for PETSC_ARCH_NAME, then we can > come up with some solution. What is the difference between > PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is > used (so PETSC_ARCH does not exist), if so, exactly why is it > needed, the whole idea behind --prefix is to eliminate PETSC_ARCH, > so why is it needed? How is PETSC_ARCH_NAME used? > > Barry > > > > On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote: > >> Barry, an outcome of the two changesets below: >> >> changeset: 14451:b289577caf8f >> user: barrysmith(a)bsmith-laptop.mcs.anl.gov >> date: Mon Oct 19 16:31:16 2009 -0500 >> summary: update to install.py to ONLY use RDict.db (and not >> command line) >> >> changeset: 14383:447d34bd2d4b >> user: barrysmith(a)bsmith-laptop.mcs.anl.gov >> date: Thu Oct 08 16:33:59 2009 -0500 >> summary: finished cleaning up makefiles, moved charactoristic.h >> to >> include location standard place where it is easy to use >> >> >> was that these two lines in config/PETSc/utilities/arch.py were >> removed: >> >> # SLEPc configure need this info >> self.addMakeMacro('PETSC_ARCH_NAME',self.arch) >> >> >> SLEPc and petsc4py/slepc4py/tao4py relies on this variable being >> defined in makefiles. There is now a new way to get the original name >> of the build-time $PETSC_ARCH? If not, any chance this change could >> be >> reverted? >> >> -- >> Lisandro Dalcín >> --------------- >> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) >> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) >> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) >> PTLC - Güemes 3450, (3000) Santa Fe, Argentina >> Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 25 Nov '09

25 Nov '09

Lisandro, That change will certainly NOT be reverted. PETSC_ARCH_NAME! what the heck kind of variable name is that? I need to understand the reason for PETSC_ARCH_NAME, then we can come up with some solution. What is the difference between PETSC_ARCH_NAME and PETSC_ARCH? Is it only needed when --prefix is used (so PETSC_ARCH does not exist), if so, exactly why is it needed, the whole idea behind --prefix is to eliminate PETSC_ARCH, so why is it needed? How is PETSC_ARCH_NAME used? Barry On Nov 25, 2009, at 10:14 AM, Lisandro Dalcin wrote: > Barry, an outcome of the two changesets below: > > changeset: 14451:b289577caf8f > user: barrysmith(a)bsmith-laptop.mcs.anl.gov > date: Mon Oct 19 16:31:16 2009 -0500 > summary: update to install.py to ONLY use RDict.db (and not > command line) > > changeset: 14383:447d34bd2d4b > user: barrysmith(a)bsmith-laptop.mcs.anl.gov > date: Thu Oct 08 16:33:59 2009 -0500 > summary: finished cleaning up makefiles, moved charactoristic.h to > include location standard place where it is easy to use > > > was that these two lines in config/PETSc/utilities/arch.py were > removed: > > # SLEPc configure need this info > self.addMakeMacro('PETSC_ARCH_NAME',self.arch) > > > SLEPc and petsc4py/slepc4py/tao4py relies on this variable being > defined in makefiles. There is now a new way to get the original name > of the build-time $PETSC_ARCH? If not, any chance this change could be > reverted? > > -- > Lisandro Dalcín > --------------- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594

1 0

Re: ptypef.c: petscdatatypegetsize_
by Jed Brown 18 Nov '09

18 Nov '09

Satish Balay wrote: > Unfortunately PETSc does have a private one. I'll have to resync with > Bill so that the changes go into the regular tarball. Let me know when that happens and I'll update my package. > There were also some private updates for f90 interface.. > > http://petsc.cs.iit.edu/petsc/externalpackages/sowing-1.1.11/ My stubs are correct with this version. Jed

1 0

Re: ptypef.c: petscdatatypegetsize_
by Satish Balay 18 Nov '09

18 Nov '09

On Wed, 18 Nov 2009, Jed Brown wrote: > Satish Balay wrote: > > I have: > > > > void PETSC_STDCALL petscdatatypegetsize_(PetscDataType *ptype,size_t *size, int *__ierr ){ > > *__ierr = PetscDataTypeGetSize(*ptype,size); > > } > > <<<<<<< > > > > Perhaps you have an old sowing/bfort package? > > Perhaps, I have a system one rather than PETSc's (but I'm the maintainer > and would like to make it correct). > > http://aur.archlinux.org/packages.php?ID=20873 > > > It is 1.1.12, the version at > > ftp://ftp.mcs.anl.gov/pub/sowing/sowing.tar.gz > > Note that the web page claims that the latest version is 1.1.11. Does > PETSc have private mods? config/PETSc/packages/sowing.py downloads > > http://ftp.mcs.anl.gov/pub/petsc/externalpackages/sowing-1.1.11-a.tar.gz > > which one would think is not more recent than 1.1.12. Unfortunately PETSc does have a private one. I'll have to resync with Bill so that the changes go into the regular tarball. There were also some private updates for f90 interface.. http://petsc.cs.iit.edu/petsc/externalpackages/sowing-1.1.11/ Satish

1 0

Re: ptypef.c: petscdatatypegetsize_
by Jed Brown 18 Nov '09

18 Nov '09

Satish Balay wrote: > I have: > > void PETSC_STDCALL petscdatatypegetsize_(PetscDataType *ptype,size_t *size, int *__ierr ){ > *__ierr = PetscDataTypeGetSize(*ptype,size); > } > <<<<<<< > > Perhaps you have an old sowing/bfort package? Perhaps, I have a system one rather than PETSc's (but I'm the maintainer and would like to make it correct). http://aur.archlinux.org/packages.php?ID=20873 It is 1.1.12, the version at ftp://ftp.mcs.anl.gov/pub/sowing/sowing.tar.gz Note that the web page claims that the latest version is 1.1.11. Does PETSc have private mods? config/PETSc/packages/sowing.py downloads http://ftp.mcs.anl.gov/pub/petsc/externalpackages/sowing-1.1.11-a.tar.gz which one would think is not more recent than 1.1.12. Jed

1 0

Re: Should PetscObjectName be collective?
by Satish Balay 18 Nov '09

18 Nov '09

On Wed, 18 Nov 2009, Barry Smith wrote: > > On Nov 18, 2009, at 8:52 AM, Jed Brown wrote: > > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/ecbd2dcad71a > > > > Note that there are a couple other places where keyvals are created (with no > > way to free them). Does it make sense to put those fields into this one? > > > > Is there a reason that petscinitialize_() duplicates much of > > PetscInitialize()? Seems like we ought to have the common stuff in a > > PetscInitialize_Private(). > > There was a reason for this duplication many years ago. I do not know if it > is still needed. There is the business of the fortran "initialization" being > done twice which may be fragile. You could try merging but test it > relentlessly :-) My guess is that some operations had to be done in a different order from fortran [due the missing argc/argv].. Satish

1 0