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

Re: --download-prometheus working again
by Matthew Knepley 20 Apr '05

20 Apr '05

Barry Smith <bsmith(a)mcs.anl.gov> writes: > After endless futzing I've gotten --download-prometheus working > with both --with-clanguage=C and C++ with petsc-dev on my Mac. Should work > everywhere :-). > > Satish, could you try adding it to a nightly build? You also need > --download-parmetis Thanks Sweet. This will hold us for a few thousand processors. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: --download-prometheus working again
by Satish Balay 20 Apr '05

20 Apr '05

Added to nightly builds [untested yet] Satish On Wed, 20 Apr 2005, Barry Smith wrote: > > After endless futzing I've gotten --download-prometheus working > with both --with-clanguage=C and C++ with petsc-dev on my Mac. Should work > everywhere :-). > > Satish, could you try adding it to a nightly build? You also need > --download-parmetis Thanks > > > Barry > >

1 0

--download-prometheus working again
by Barry Smith 20 Apr '05

20 Apr '05

After endless futzing I've gotten --download-prometheus working with both --with-clanguage=C and C++ with petsc-dev on my Mac. Should work everywhere :-). Satish, could you try adding it to a nightly build? You also need --download-parmetis Thanks Barry

1 0

more configure....
by Boyana Norris 19 Apr '05

19 Apr '05

First, thanks for the lightning fast response to my first petsc-dev question (or is it negative time, since Matt had already implemented what I asked for last night). My next configure wish list thing is to have a way to "restart" configure from a certain point. This is probably a bit tricky to implement. The syntax I am thinking of (and there may be better options) would be to have a --resume or --continue option given to configure, in addition to new or modified options. Then, it would restart from the "right" place, given the new set of options, while avoiding redundant checks. For example, if there was a bad mpi path given to petsc's configure, I would like to be able to rerun it with a corrected mpi location (everything else staying the same) and avoid rerunning all the other unrelated configuration checks that happen to come before it. Obviously this saves a lot of time for failures that occur near the end of configure. This is not like gnu configure's caching, which doesn't really work anyway. I'm not sure there is enough infrastructure right now to implement something like this; for example, the dependencies between various configure options are not apparent. I don't think, however, that a completely general solution is essential -- even something as simple as restarting at the last error would be great. In any case I think this would be a "use at your own risk" option since there will always be the fallback full rerun of configure. Boyana

1 0

Re: configure options
by Satish Balay 19 Apr '05

19 Apr '05

On Tue, 19 Apr 2005, Boyana Norris wrote: > Satish, > > Thanks, this is sufficient for most cases (the only exception I can think of > is when configure crashed or was interrupted before this file was created, > which has happened to me a few times). If thats the case - you have shell command history :) But Matt is adding the extra dump to configure.log - suitable for copy/paste with shell. And I'm refining the python side of things a bit. i.e the following should work: "Command line options should take precedence over predefined values in the script." For eg: I could have: config/configure.py --with-mpi-dir=/home/balay/mpich-1 -PETSC_ARCH=arch1 Now I should be able to do: ./bmake/arch1/configure.py --with-mpi-dir=/home/balay/mpich-2 -PETSC_ARCH=arch2 Satish

1 0

Re: configure options
by Boyana Norris 19 Apr '05

19 Apr '05

Satish, Thanks, this is sufficient for most cases (the only exception I can think of is when configure crashed or was interrupted before this file was created, which has happened to me a few times). Boyana Satish Balay wrote: > On Tue, 19 Apr 2005, Boyana Norris wrote: > > >>This is a suggestion for a trivial addition to what goes in configure.log >>(that is, if it's not already available elsewhere). One feature that I've >>found very handy in the otherwise unpleasant use of gnu configure is the >>ability to cut and paste the options given to configure from the config.log >>(or .status) file, in the case when building multiple versions or slightly >>differently configured builds. This doesn't seem to be available with PETSc's >>configure, or at least not obviously so. If I take the array of options from >>configure.log, I can't just paste it on the configure command line. > > > Currently this functionality is available as > bmake/${PETSC_ARCH}/configure.py. > > It gets created when configure is run. It can be run again with > additional options. Changing/removing options would mean editing the > python syntax. > > Satish > -- "Everything should be made as simple as possible, but not one bit simpler." Albert Einstein (1879 - 1955) (attributed)

1 0

Re: configure options
by Satish Balay 19 Apr '05

19 Apr '05

On Tue, 19 Apr 2005, Boyana Norris wrote: > This is a suggestion for a trivial addition to what goes in configure.log > (that is, if it's not already available elsewhere). One feature that I've > found very handy in the otherwise unpleasant use of gnu configure is the > ability to cut and paste the options given to configure from the config.log > (or .status) file, in the case when building multiple versions or slightly > differently configured builds. This doesn't seem to be available with PETSc's > configure, or at least not obviously so. If I take the array of options from > configure.log, I can't just paste it on the configure command line. Currently this functionality is available as bmake/${PETSC_ARCH}/configure.py. It gets created when configure is run. It can be run again with additional options. Changing/removing options would mean editing the python syntax. Satish

1 0

configure options
by Boyana Norris 19 Apr '05

19 Apr '05

This is a suggestion for a trivial addition to what goes in configure.log (that is, if it's not already available elsewhere). One feature that I've found very handy in the otherwise unpleasant use of gnu configure is the ability to cut and paste the options given to configure from the config.log (or .status) file, in the case when building multiple versions or slightly differently configured builds. This doesn't seem to be available with PETSc's configure, or at least not obviously so. If I take the array of options from configure.log, I can't just paste it on the configure command line. Boyana

1 0

libtool on osx
by Aron Ahmadia 17 Apr '05

17 Apr '05

Hi guys, Is there a reason we're using Apple's libtool instead of GNU libtool (glibtool) by default? I think we'd be able to build dynamic libraries a little more correctly if we used glibtool. Matt, we can activate the build bundles with a -module flag to glibtool, Apple's libtool can't do dynamically loaded libraries. ~Aron

1 0

default shared libraries turned off for a week or so
by Barry Smith 16 Apr '05

16 Apr '05

I have turned off the default use of shared libraries by PETSc for a few days. So if you want/need dynamic libraries remember to run configures and make.pys with --with-dynamic Barry We're making a push to get release 2.3 out this week.

1 0