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

getting norm type or pc side after resetting ksp type
by Lisandro Dalcin 26 Mar '12

26 Mar '12

Please look at the following example. The error is really unexpected for me, but I'm not sure how to fix it: In [1]: from petsc4py import PETSc In [2]: ksp = PETSc.KSP().create() In [3]: ksp.setType('gmres') In [4]: ksp.getNormType() Out[4]: 1 In [5]: ksp.setType('fgmres') # changing ksp type In [6]: ksp.getNormType() --------------------------------------------------------------------------- Error Traceback (most recent call last) /Users/dalcinl/Devel/PetIGA/demo/<ipython-input-6-40949252afeb> in <module>() ----> 1 ksp.getNormType() /Users/dalcinl/Library/Python/2.7/lib/python/site-packages/petsc4py/lib/arch-darwin-c-debug/PETSc.so in petsc4py.PETSc.KSP.getNormType (src/petsc4py.PETSc.c:106669)() Error: error code 56 [0] KSPGetNormType() line 317 in /Users/dalcinl/Devel/petsc-3.2/src/ksp/ksp/interface/itcreate.c [0] KSPSetUpNorms_Private() line 284 in /Users/dalcinl/Devel/petsc-3.2/src/ksp/ksp/interface/itcreate.c [0] No support for this operation for this object type [0] KSP fgmres does not support PRECONDITIONED with LEFT -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] buildsystem: cusp location
by Sean Farley 25 Mar '12

25 Mar '12

> > So you are arguing we should make life harder for users? > > --with-package-dir=dir currently has the model "look for any way we > know about" for installs underneath dir. > > Why is this a bad model? Why do you advocate something much more limited? > > Who agrees with Sean that we should cripple --with-package-dir=dir? > Expanding it sounds like a better idea. No, sorry, I wasn't really being clear. Jed said it better than I could: I'm for strict, precise semantics over fuzzy permissive semantics. I don't think being permissive is likely to cause harm, so I'm fine with checking both. I just don't want the extra /include to be a required part because it breaks consistency with other packages (none of which require the extra /include).

1 0

Re: [petsc-dev] buildsystem: cusp location
by Jed Brown 25 Mar '12

25 Mar '12

I'm for strict, precise semantics over fuzzy permissive semantics. I don't think being permissive is likely to cause harm, so I'm fine with checking both. I just don't want the extra /include to be a required part because it breaks consistency with other packages (none of which require the extra /include). On Mar 25, 2012 9:20 PM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: > > So you are arguing we should make life harder for users? > > --with-package-dir=dir currently has the model "look for any way we > know about" for installs underneath dir. > > Why is this a bad model? Why do you advocate something much more limited? > > Who agrees with Sean that we should cripple --with-package-dir=dir? > Expanding it sounds like a better idea. > > Barry > > > > On Mar 25, 2012, at 4:56 PM, Sean Farley wrote: > > > > > > > Yes, I think it would be far simpler to say: > > > > --with-package-dir = prefix install > > --with-package-{include,lib}dir = non-prefix type of package > > > > And then we'd have less ambiguity. Packages such as MKL are already > exceptions to whatever is defined currently, so there'd be no more code to > add to handle this, i.e. MKL would remain an exception in the new model. > > > > Sure better errors are useful. This is independent of the > > package-dir=prefix issue. [so you can add this stuff now.] > > > > That's true. > > > > apt-get install should already work. And --with-package-dir is > > generally for manual installs. > > > > apt-get only works because /usr/local is listed as a default search > path. Perhaps gcc should have been configured to add its own prefix but > that would have to be an issue taken up with each package manager. > >

1 0

Re: [petsc-dev] buildsystem: cusp location
by Barry Smith 25 Mar '12

25 Mar '12

So you are arguing we should make life harder for users? --with-package-dir=dir currently has the model "look for any way we know about" for installs underneath dir. Why is this a bad model? Why do you advocate something much more limited? Who agrees with Sean that we should cripple --with-package-dir=dir? Expanding it sounds like a better idea. Barry On Mar 25, 2012, at 4:56 PM, Sean Farley wrote: > > > Yes, I think it would be far simpler to say: > > --with-package-dir = prefix install > --with-package-{include,lib}dir = non-prefix type of package > > And then we'd have less ambiguity. Packages such as MKL are already exceptions to whatever is defined currently, so there'd be no more code to add to handle this, i.e. MKL would remain an exception in the new model. > > Sure better errors are useful. This is independent of the > package-dir=prefix issue. [so you can add this stuff now.] > > That's true. > > apt-get install should already work. And --with-package-dir is > generally for manual installs. > > apt-get only works because /usr/local is listed as a default search path. Perhaps gcc should have been configured to add its own prefix but that would have to be an issue taken up with each package manager.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Sean Farley wrote: > ... or if a package is installed into a path that isn't search by default > with the compiler? > ./configure --with-cusp --with-cuda --with-thrust gives > > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for > details): > ------------------------------------------------------------------------------- > You must specify a path for cusp with --with-cusp-dir=<directory> > > even though mpicc -show gives > > /opt/local/bin/gcc-mp-4.6 -I/opt/local/include ... > > and /opt/local/include/cusp/version.h exists. > > Note: there is no such package for cusp/thrust to base a default - so > > the upstream default thats currently implemented is fine [we are > > supporting actuall use cases instead of fictious ones that don't > > exist]. > > > Huh? As Jed pointed out, archlinux has it. MacPorts also has it. Looks like MacPorts is not a 'distribution compliant' system. If it were - you wold have 'MacPorts compliant' install of cuda, and then cusp,thrust installed - in the same compliant way. [i.e cuda will also reside in /opt/local/ etc, and use gcc from /opt/local/ etc..] And Jed already mentioned cuda package in arch-linux is a hack [and mentioned both cuda,cusp break distribution rules]. Still - nvcc/gcc will find /usr/include/cusp automatically on arch. Satish

1 0

buildsystem: add hg log
by Sean Farley 25 Mar '12

25 Mar '12

Matt, Can you the ability for self.installNeeded to check the date from hg log for the particular package? Something such as: hg log -l 1 config/PETSc/packages/metis.py --template '{date|isodatesec}' 2012-03-20 15:11:27 -0500 and then redownload && reinstall based on this information (as well as the current method of checking options written to a file). Since buildsystem is already written in python, this could be implemented with a fancy call to a mercurial command server, or whatever you prefer. While we're at it, can the mkfile argument self.installNeeded be optional and default to self.package? Thanks!

1 0

Re: [petsc-dev] buildsystem: cusp location
by Sean Farley 25 Mar '12

25 Mar '12

> > For one if package managers install stuff [that are distribution > compliant] - users don't need to specify --with-package-dir option > at-all. Compilers automatically find includes/libs [ and package.py > defaults to checking this mode first.] > package-dir option is used primarily for non-[apt,yum] installed stuff > - either by user or sysadmin. > ... or if a package is installed into a path that isn't search by default with the compiler? ./configure --with-cusp --with-cuda --with-thrust gives UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- You must specify a path for cusp with --with-cusp-dir=<directory> even though mpicc -show gives /opt/local/bin/gcc-mp-4.6 -I/opt/local/include ... and /opt/local/include/cusp/version.h exists. Note: there is no such package for cusp/thrust to base a default - so > the upstream default thats currently implemented is fine [we are > supporting actuall use cases instead of fictious ones that don't > exist]. Huh? As Jed pointed out, archlinux has it. MacPorts also has it. > If such a package actually existed - then compilers would find > cusp/thrust automatically. > How? > I agree about the cleanup part. But thats beside the point. I thought > the motivation so far was user convinence [and autodetect as many user > configs as possible] - hence the extra code in buildsystem. > No, I'm really just trying to iron out a policy, more or less, about --with-package-dir. Implementation would need to follow that; but as I said before, I'm no good at Jenga. Specifically, I've tried to add search paths, such as /opt/local, but this always ends up breaking other use cases. I think we support this for packages that actually have a concept of > prefix-install. > It's supported for any package that sets self.includedir='include'. > But what you are actually saying is: if a user installs an > externalpackage separately [that doesn't comply with a prefix install] > - then s/he should reinstall [with some manual hacks] per some prefix > guidelines specified by petsc - so that s/he might provide > --with-package-dir option to petsc configure. > Not at all; no reinstall should be necessary. I'm suggesting that the user just specify --with-package-{include,lib}dir. Why do we have these options if not for this purpose? I don't claim the current mode works for all curent user installs - > but so far - when it failed - we would recommend --download-package as > a better alternative. [it also deals with other types of > incompatibilities aswell]. One of the sugestions in this thread was > for the user to specify --with-include/with-lib options instead of > --with-dir - for such cases. > Yes, I think it would be far simpler to say: --with-package-dir = prefix install --with-package-{include,lib}dir = non-prefix type of package And then we'd have less ambiguity. Packages such as MKL are already exceptions to whatever is defined currently, so there'd be no more code to add to handle this, i.e. MKL would remain an exception in the new model. Sure better errors are useful. This is independent of the > package-dir=prefix issue. [so you can add this stuff now.] > That's true. apt-get install should already work. And --with-package-dir is > generally for manual installs. apt-get only works because /usr/local is listed as a default search path. Perhaps gcc should have been configured to add its own prefix but that would have to be an issue taken up with each package manager.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Matthew Knepley 25 Mar '12

25 Mar '12

On Sun, Mar 25, 2012 at 4:53 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Sun, 25 Mar 2012, Jed Brown wrote: > > > On Sun, Mar 25, 2012 at 16:32, Matthew Knepley <knepley(a)gmail.com> > wrote: > > > > > Isn't the final point here that we are trying to let the user do the > > > dumbest, easiest thing? Maybe no Linux distribution > > > does this, but we are trying to cope with bad input from a user not > using > > > a nice distro. > > > > > > The price we would pay for cleaning up our internals is demanding that > > > users think more about the configure input. This > > > is not always a good tradeoff. > > > > > > > Simple compromise proposal: > > > > --with-cusp-dir=/prefix > > > > Looks in /prefix/include/ for the headers <cusp/version.h>. If > > unsuccessful, it tries /prefix/. > > Ok - for my part I've already agreed to this. [sean proposal (1)?] > > BuildSystem has a way of looping over libdir/libname options. Don't > know if it can currently do the same for includes. [Hence my initial > attempt to support cusp/thrust was to do a replace of the default > choice - instead of trying them all] Yes you can put different include options in the generator in the same way. Matt > > Satish > > > > > > > If you insisted, it could even search in the other order. What I don't > like > > is --with-cusp-dir=/prefix not looking for headers in /prefix/include/. > > > > -- 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] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Jed Brown wrote: > On Sun, Mar 25, 2012 at 16:32, Matthew Knepley <knepley(a)gmail.com> wrote: > > > Isn't the final point here that we are trying to let the user do the > > dumbest, easiest thing? Maybe no Linux distribution > > does this, but we are trying to cope with bad input from a user not using > > a nice distro. > > > > The price we would pay for cleaning up our internals is demanding that > > users think more about the configure input. This > > is not always a good tradeoff. > > > > Simple compromise proposal: > > --with-cusp-dir=/prefix > > Looks in /prefix/include/ for the headers <cusp/version.h>. If > unsuccessful, it tries /prefix/. Ok - for my part I've already agreed to this. [sean proposal (1)?] BuildSystem has a way of looping over libdir/libname options. Don't know if it can currently do the same for includes. [Hence my initial attempt to support cusp/thrust was to do a replace of the default choice - instead of trying them all] Satish > > > If you insisted, it could even search in the other order. What I don't like > is --with-cusp-dir=/prefix not looking for headers in /prefix/include/. >

1 0

Re: [petsc-dev] buildsystem: cusp location
by Jed Brown 25 Mar '12

25 Mar '12

On Sun, Mar 25, 2012 at 16:37, Satish Balay <balay(a)mcs.anl.gov> wrote: > echo "export CUSP_PATH=/usr/include" > $pkgdir/etc/profile.d/${pkgname}.sh > <<<< > > Isn't this contradictary to the prefix rule you mentioned before? > > > Also - do they package cuda aswell? If so where is is installed [wrt > includes]? > /opt/cuda-toolkit/ with a somewhat normal layout underneath. The cusp package is actually kinda amateur because it should also go in /opt/cuda-toolkit according to archlinux conventions. Thrust (packaged with latest cuda-toolkit) is in /opt/cuda-toolkit/include/thrust/*.h. The package couldn't install to /usr as normally recommended because CUDA insists on a non-conforming directory layout (/opt/cuda-toolkit/{libnvvp,open64,tools}).

1 0