[petsc-dev] no module named cmakegen
Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/ed6baea2/attachment.html
[petsc-dev] no module named cmakegen
Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/2eadc532/attachment.html
[petsc-dev] no module named cmakegen
Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/4e86d927/attachment.html
[petsc-dev] no module named cmakegen
Hi Aron, I try now to configure the Mercurial version of Petsc-dev. However, the script gets stuck in some kind of infinite loop, producing this text over and over again. What should I do now? -- The C compiler identification is GNU -- Check for working C compiler: /opt/local/bin/mpicc -- Check for working C compiler: /opt/local/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: mpif90 -- Check for working Fortran compiler: mpif90 -- works -- Checking whether mpif90 supports Fortran 90 -- Checking whether mpif90 supports Fortran 90 -- yes -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= mpif90 Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/74630eab/attachment.html
[petsc-dev] no module named cmakegen
Hi Leo, I haven't seen this problem before. What are you specifying to configure? You may want to send the configure.log (after killing it) to petsc-maint at mcs.anl.gov. I am not on that mailing list, but it's the right place to send potential bugs. Also, this goes without saying, but if you were doing anything strange, it's best to start with a clean copy of the repository (I don't know the *right* way to do this in Mercurial, but you can just do an hg clone of your petsc-dev into another directory) A On Mon, Aug 23, 2010 at 2:45 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I try now to configure the Mercurial version of Petsc-dev. However, the script gets stuck in some kind of infinite loop, producing this text over and over again. What should I do now? -- The C compiler identification is GNU -- Check for working C compiler: /opt/local/bin/mpicc -- Check for working C compiler: /opt/local/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: mpif90 -- Check for working Fortran compiler: mpif90 -- works -- Checking whether mpif90 supports Fortran 90 -- Checking whether mpif90 supports Fortran 90 -- yes -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= mpif90 Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/b35e86cc/attachment.html
[petsc-dev] no module named cmakegen
Jed, Looks like cmakegen is at bin/maint/cmakegen.py. However maint is excluded from the tarball - so it should go somewhere else.. perhaps config/cmake/xx? thanks, Satish On Mon, 23 Aug 2010, Leo van Kampenhout wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen ***
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Aron Ahmadia wrote: Hi Leo, I haven't seen this problem before. What are you specifying to configure? You may want to send the configure.log (after killing it) to petsc-maint at mcs.anl.gov. I am not on that mailing list, but it's the right place to send potential bugs. Also, this goes without saying, but if you were doing anything strange, it's best to start with a clean copy of the repository (I don't know the *right* way to do this in Mercurial, but you can just do an hg clone of your petsc-dev into another directory) Aron, One can do the following: cd petsc-dev hg status hg revert -a hg pull -u cd BuildSystem hg status hg revert -a hg pull -u Satish A On Mon, Aug 23, 2010 at 2:45 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I try now to configure the Mercurial version of Petsc-dev. However, the script gets stuck in some kind of infinite loop, producing this text over and over again. What should I do now? -- The C compiler identification is GNU -- Check for working C compiler: /opt/local/bin/mpicc -- Check for working C compiler: /opt/local/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: mpif90 -- Check for working Fortran compiler: mpif90 -- works -- Checking whether mpif90 supports Fortran 90 -- Checking whether mpif90 supports Fortran 90 -- yes -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= mpif90 Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen ***
[petsc-dev] Semantics for v.getArray()
On 23 August 2010 10:38, Matthew Knepley knepley at gmail.com wrote: I am unclear what they are. There is no restoreArray() and I do not understand setArray(). This is something we should have to discuss and eventually improve... * For older Python and NumPy versions (actually, not so older, let say Py=2.6), getArray() only works for 'native' PETSc vectors... it is implemented by calling VecGetArray() and immediatly VecRestoreArray(), but I hold the pointer value and use it for creating a NumPy array sharing memory with the vector. * For newer Python (2.7) and NumPy (1.5) versions, this is implemented using other Python protocols. In this case, when you call getArray(), VecGetArray() is called and a NumPy array is built... When the NumPy array is garbage collected, VecRestoreArray() is called. * vec.setArray(a) is just sugar for copying the contentes of array 'a' in the vector 'vec', i.e, VecGetArray()+memcpy()+VecRestoreArray(). Additionally, it handles scalar (i.e, non-array) arguments specially, eg. vec.setArray(vec.comm.rank) will fill with zeros at P0, with ones at P1, and so on (note that VecSet() would not work for this). getArray()/restoreArray() is unpythonic, and relying in garbage collection for calling restoreArray() is really dangerous. Perhaps I should add restoreArray() anyway? What do you think the semantics should be? What should happen with the NumPy array after restoreArray() ? I would hate to maintain in Python land a NumPy array with a dangling pointer. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] no module named cmakegen
1. you haven't mentioned the command you've invoked 2. you haven't sent the logfile as instructed. All discussions without the above are just guessing games. If you want to make progress - run with the additional configure option --with-cmake=0 Jed, shouldn't the cmake output [when invoked via configure] - go into configure.log - and not to stdout?. Satish On Mon, 23 Aug 2010, Leo van Kampenhout wrote: Hello, the problem with the infinite loop seems to be CMAKE related. Sorry to bother. Maybe the minimum required version of CMake should be changed from 2.6 to something higher. Herehttp://www.mail-archive.com/cmake at cmake.org/msg25107.htmlpeople discuss the same problem, where somebody suggest the problem of infinite looping is fixed in version 2.6.2http://www.cmake.org/files/v2.6/CMakeChangeLog-2.6.2 regards 2010/8/23 Matthew Knepley knepley at gmail.com This is not output from our configure. Are you running something else in the PETSc directory? Send configure.log Matt On Mon, Aug 23, 2010 at 11:45 AM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I try now to configure the Mercurial version of Petsc-dev. However, the script gets stuck in some kind of infinite loop, producing this text over and over again. What should I do now? -- The C compiler identification is GNU -- Check for working C compiler: /opt/local/bin/mpicc -- Check for working C compiler: /opt/local/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: mpif90 -- Check for working Fortran compiler: mpif90 -- works -- Checking whether mpif90 supports Fortran 90 -- Checking whether mpif90 supports Fortran 90 -- yes -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= mpif90 Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- 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
[petsc-dev] no module named cmakegen
Hi Satish, my problem is solved by now. I upgraded CMake from 2.6 to the latest version (2.8.2) and it works fine. Thanks for the help anyway. In case you really want to see it, i can reproduce the configure.log file but otherwise I consider this bug-report as solved. (since i've overwritten the log by now). cheers, Leo 2010/8/23 Satish Balay balay at mcs.anl.gov 1. you haven't mentioned the command you've invoked 2. you haven't sent the logfile as instructed. All discussions without the above are just guessing games. If you want to make progress - run with the additional configure option --with-cmake=0 Jed, shouldn't the cmake output [when invoked via configure] - go into configure.log - and not to stdout?. Satish On Mon, 23 Aug 2010, Leo van Kampenhout wrote: Hello, the problem with the infinite loop seems to be CMAKE related. Sorry to bother. Maybe the minimum required version of CMake should be changed from 2.6 to something higher. Herehttp://www.mail-archive.com/cmake at cmake.org/msg25107.htmlpeople discuss the same problem, where somebody suggest the problem of infinite looping is fixed in version 2.6.2http://www.cmake.org/files/v2.6/CMakeChangeLog-2.6.2 regards 2010/8/23 Matthew Knepley knepley at gmail.com This is not output from our configure. Are you running something else in the PETSc directory? Send configure.log Matt On Mon, Aug 23, 2010 at 11:45 AM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I try now to configure the Mercurial version of Petsc-dev. However, the script gets stuck in some kind of infinite loop, producing this text over and over again. What should I do now? -- The C compiler identification is GNU -- Check for working C compiler: /opt/local/bin/mpicc -- Check for working C compiler: /opt/local/bin/mpicc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: mpif90 -- Check for working Fortran compiler: mpif90 -- works -- Checking whether mpif90 supports Fortran 90 -- Checking whether mpif90 supports Fortran 90 -- yes -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_Fortran_COMPILER= mpif90 Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Yes. A On Mon, Aug 23, 2010 at 2:19 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi Aron, I'm using the nightly tarball. Do you propose using mercurial? I can try that. Leo 2010/8/23 Aron Ahmadia aron at ahmadia.net Hi Leo, Did you perform an hg pull; hg update in petsc-dev/config/BuildSystem? A On Mon, Aug 23, 2010 at 2:14 PM, Leo van Kampenhout lvankampenhout at gmail.com wrote: Hi all, I'm trying to install PETSc-dev on my desktop machine. This is what goes wrong. I suspect the line import cmakegen [line 409] in the configure.py is the cause. The version of Cmake installed on my system is 2.6 Best regards, Leo van Kampenhout csg4035 at wingtip70:~/install/petsc-dev$ ./configure === Configuring PETSc to compile on your system === TESTING: configureFortranFlush from PETSc.Configure(/net/users/csg/csg4035/download/petsc-dev/config/PETSc/Configure.py:652*** UNABLE to FIND MODULE for ./configure --- No module named cmakegen *** -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/b8ae627a/attachment.html
[petsc-dev] Problem with conjugate gradient solver
Hi, I was trying to compile and run the example file $PETSC_DIR/src/ksp/pc/examples/tutorials/ex3.c, which demonstrates PETSc's preconditioned conjugate gradient solver for a system of linear equations. After compiling, running make runex3 is supposed to throw up the error Divergence because of indefinite preconditioner and running make runex3_pd is supposed to work and give the correct solution. But instead I get the error Other kind of divergence: this should not happen. for the latter. Is there some bug in the code, or are there any other options that need to be set? Thanks, Anush -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/5e4dbb68/attachment.html
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010 08:40:02 -0500 (CDT), Satish Balay balay at mcs.anl.gov wrote: Jed, Looks like cmakegen is at bin/maint/cmakegen.py. However maint is excluded from the tarball - so it should go somewhere else.. perhaps config/cmake/xx? I think iphonebuilder.py also needs an alternate location since it's configure-time functionality. I was also discussing with Matt about what is required to portably import script (e.g. when the PETSC_DIR environment variable is not set). checkBuilds.py has something relatively involved, but also uses $PWD, which I think is more evil than requiring something in the environment. This is mostly a issue when running configure.py without setting PETSC_DIR. In the case of running scripts (via import xxx, xxx.main()), perhaps configure should put PETSC_DIR in it's exported environment? I just bumped the minimum cmake version from 2.6.0 to 2.6.2. As a longer-term matter, cmake should probably be run with a time limit and redirected stdout. I'll look at it shortly. Jed
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Jed Brown wrote:
On Mon, 23 Aug 2010 08:40:02 -0500 (CDT), Satish Balay balay at mcs.anl.gov
wrote:
Jed,
Looks like cmakegen is at bin/maint/cmakegen.py. However maint is
excluded from the tarball - so it should go somewhere else..
perhaps config/cmake/xx?
I think iphonebuilder.py also needs an alternate location since it's
configure-time functionality.
I was also discussing with Matt about what is required to portably
import script (e.g. when the PETSC_DIR environment variable is not
set). checkBuilds.py has something relatively involved, but also uses
$PWD, which I think is more evil than requiring something in the
environment. This is mostly a issue when running configure.py without
setting PETSC_DIR. In the case of running scripts (via import xxx,
xxx.main()), perhaps configure should put PETSC_DIR in it's exported
environment?
Well currently configure is to be invoked in PETSC_DIR - and the py scripts
generally use relative paths to find each other. For eg: config/configure.py
has:
# Should be run from the toplevel
configDir = os.path.abspath('config')
bsDir = os.path.join(configDir, 'BuildSystem')
Satish
I just bumped the minimum cmake version from 2.6.0 to 2.6.2. As a
longer-term matter, cmake should probably be run with a time limit and
redirected stdout. I'll look at it shortly.
Jed
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010 16:18:27 -0500 (CDT), Satish Balay balay at mcs.anl.gov
wrote:
Well currently configure is to be invoked in PETSC_DIR - and the py scripts
generally use relative paths to find each other. For eg: config/configure.py
has:
# Should be run from the toplevel
configDir = os.path.abspath('config')
bsDir = os.path.join(configDir, 'BuildSystem')
Right, and self.petscdir is set regardless of whether the environment
variable PETSC_DIR has been set. The trouble comes when you invoke a
script (that could be run stand-alone, even if that is advanced usage).
Even if you didn't mind requiring that PWD be chosen carefully before
calling the maintenance script (which I find ugly), we still don't want
to copy all the environment checks and error handling from configure.py,
but we can't find *any* PETSc modules without knowing PETSC_DIR or using
the relative path hacks.
In this case, the script has to be able to import script before the
PETScMaker type can be declared. Maybe the right thing to do is to move
the whole class definition into cmakeboot.main() which acquires petscdir
as an explicit argument, and can thus set things up correctly.
Any comments/suggestions on what I currently have in cmakeboot.py?
def main(petscdir, petscarch, argDB=None, framework=None,
logPrint=printFunction, args=[]):
# This can be called as a stand-alone program, or by importing it from
# python. The latter functionality is needed because argDB does not
# get written until the very end of configure, but we want to run this
# automatically during configure (if CMake is available).
#
# Strangely, we can't store logPrint in the PETScMaker because
# (somewhere) it creeps into framework (which I don't want to modify)
# and makes the result unpickleable. This is not a problem when run
# as a standalone program (because the database is read-only), but is
# not okay when called from configure.
PETScMaker(petscdir,petscarch,argDB,framework).cmakeboot(args,logPrint)
Note that cmakeboot.py can be called independently after configure, it
does not modify argDB at all, but I have it running during configure
just so that users of the cmake build don't have any extra steps to
remember (just configure as usual, the run make from the build
directory).
Jed
[petsc-dev] no module named cmakegen
Can you explain the logPrint() problem? It is not quite clear. I tried to be
careful
that Framework was picklable.
Matt
On Mon, Aug 23, 2010 at 9:37 PM, Jed Brown jed at 59a2.org wrote:
On Mon, 23 Aug 2010 16:18:27 -0500 (CDT), Satish Balay balay at mcs.anl.gov
wrote:
Well currently configure is to be invoked in PETSC_DIR - and the py
scripts
generally use relative paths to find each other. For eg:
config/configure.py has:
# Should be run from the toplevel
configDir = os.path.abspath('config')
bsDir = os.path.join(configDir, 'BuildSystem')
Right, and self.petscdir is set regardless of whether the environment
variable PETSC_DIR has been set. The trouble comes when you invoke a
script (that could be run stand-alone, even if that is advanced usage).
Even if you didn't mind requiring that PWD be chosen carefully before
calling the maintenance script (which I find ugly), we still don't want
to copy all the environment checks and error handling from configure.py,
but we can't find *any* PETSc modules without knowing PETSC_DIR or using
the relative path hacks.
In this case, the script has to be able to import script before the
PETScMaker type can be declared. Maybe the right thing to do is to move
the whole class definition into cmakeboot.main() which acquires petscdir
as an explicit argument, and can thus set things up correctly.
Any comments/suggestions on what I currently have in cmakeboot.py?
def main(petscdir, petscarch, argDB=None, framework=None,
logPrint=printFunction, args=[]):
# This can be called as a stand-alone program, or by importing it from
# python. The latter functionality is needed because argDB does not
# get written until the very end of configure, but we want to run this
# automatically during configure (if CMake is available).
#
# Strangely, we can't store logPrint in the PETScMaker because
# (somewhere) it creeps into framework (which I don't want to modify)
# and makes the result unpickleable. This is not a problem when run
# as a standalone program (because the database is read-only), but is
# not okay when called from configure.
PETScMaker(petscdir,petscarch,argDB,framework).cmakeboot(args,logPrint)
Note that cmakeboot.py can be called independently after configure, it
does not modify argDB at all, but I have it running during configure
just so that users of the cmake build don't have any extra steps to
remember (just configure as usual, the run make from the build
directory).
Jed
--
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/86ddcf4d/attachment.html
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Jed Brown wrote:
On Mon, 23 Aug 2010 16:18:27 -0500 (CDT), Satish Balay balay at mcs.anl.gov
wrote:
Well currently configure is to be invoked in PETSC_DIR - and the py scripts
generally use relative paths to find each other. For eg:
config/configure.py has:
# Should be run from the toplevel
configDir = os.path.abspath('config')
bsDir = os.path.join(configDir, 'BuildSystem')
Right, and self.petscdir is set regardless of whether the environment
variable PETSC_DIR has been set. The trouble comes when you invoke a
script (that could be run stand-alone, even if that is advanced usage).
Even if you didn't mind requiring that PWD be chosen carefully before
calling the maintenance script (which I find ugly), we still don't want
to copy all the environment checks and error handling from configure.py,
but we can't find *any* PETSc modules without knowing PETSC_DIR or using
the relative path hacks.
In this case, the script has to be able to import script before the
PETScMaker type can be declared. Maybe the right thing to do is to move
the whole class definition into cmakeboot.main() which acquires petscdir
as an explicit argument, and can thus set things up correctly.
Any comments/suggestions on what I currently have in cmakeboot.py?
def main(petscdir, petscarch, argDB=None, framework=None,
logPrint=printFunction, args=[]):
# This can be called as a stand-alone program, or by importing it from
# python. The latter functionality is needed because argDB does not
# get written until the very end of configure, but we want to run this
# automatically during configure (if CMake is available).
#
# Strangely, we can't store logPrint in the PETScMaker because
# (somewhere) it creeps into framework (which I don't want to modify)
# and makes the result unpickleable. This is not a problem when run
# as a standalone program (because the database is read-only), but is
# not okay when called from configure.
PETScMaker(petscdir,petscarch,argDB,framework).cmakeboot(args,logPrint)
Note that cmakeboot.py can be called independently after configure, it
does not modify argDB at all, but I have it running during configure
just so that users of the cmake build don't have any extra steps to
remember (just configure as usual, the run make from the build
directory).
config/install.py is an exaple of stand alone script requiring
PETSC_DIR/PETSC_ARCH - it also relies on being invoked in PETSC_DIR
Part of the issue with PETSC_DIR/PETSC_ARCH is: they are primarily
needed by 'makefiles' [for both building and using PETSc]. All other
build tools - hopefully don't need them - or can autodetect as needed.
Satish
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010 16:58:57 -0500 (CDT), Satish Balay balay at mcs.anl.gov wrote: config/install.py is an exaple of stand alone script requiring PETSC_DIR/PETSC_ARCH - it also relies on being invoked in PETSC_DIR Do you suggest copying it's first 25 lines into all new scripts? Part of the issue with PETSC_DIR/PETSC_ARCH is: they are primarily needed by 'makefiles' [for both building and using PETSc]. All other build tools - hopefully don't need them - or can autodetect as needed. FWIW, the CMake build doesn't use them anywhere. I just don't like copying the autodetection all over the place. The trouble is that even after wrapping up the autodetection, we still have to find it. Jed
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Jed Brown wrote: On Mon, 23 Aug 2010 16:58:57 -0500 (CDT), Satish Balay balay at mcs.anl.gov wrote: config/install.py is an exaple of stand alone script requiring PETSC_DIR/PETSC_ARCH - it also relies on being invoked in PETSC_DIR Do you suggest copying it's first 25 lines into all new scripts? I guess thats the current recomendation. From previous edits - Barry doesn't like these provided as command line arguments to the stand alone scripts. There is also config/builder.py - that doesn't work witout PETSC_DIR env variable. And I don't like over reliance on evn variables - when its not needed - esp for build tools. These give rise to undebuggable errors [wrong buildsytem used from a different PETSC_DIR source tree etc - or generated files are dumped into the wrong PETSc tree etc] Also we are opposed to CC CFLAGS etc in env variables. So in that line of things PETSC_DIR/PETSC_ARCH reliance should also be minimised - [avoided - when not needed] Now that there are more and more standalone scripts - perhaps we need a better consistant way to handle this - but I don't know what that is.. Satish Part of the issue with PETSC_DIR/PETSC_ARCH is: they are primarily needed by 'makefiles' [for both building and using PETSc]. All other build tools - hopefully don't need them - or can autodetect as needed. FWIW, the CMake build doesn't use them anywhere. I just don't like copying the autodetection all over the place. The trouble is that even after wrapping up the autodetection, we still have to find it.
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Satish Balay wrote: Now that there are more and more standalone scripts - perhaps we need a better consistant way to handle this - but I don't know what that is.. mercurial way is to have 'hg' be the frontend script to all commands. i.e no invocation of individual scripts .. Perhaps we should adopt that? Satish
[petsc-dev] no module named cmakegen
On Mon, Aug 23, 2010 at 10:21 PM, Satish Balay balay at mcs.anl.gov wrote: On Mon, 23 Aug 2010, Satish Balay wrote: Now that there are more and more standalone scripts - perhaps we need a better consistant way to handle this - but I don't know what that is.. mercurial way is to have 'hg' be the frontend script to all commands. i.e no invocation of individual scripts .. Perhaps we should adopt that? That requires a Mercurial 'install', which is not different than a) or c) namely c) Put PETSC_DIR in your PATH, which is env var manipulation a) Change /usr/bin, which is always in the path (like installing inside Python) Matt 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100823/58299f5d/attachment.html
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010, Matthew Knepley wrote: On Mon, Aug 23, 2010 at 10:21 PM, Satish Balay balay at mcs.anl.gov wrote: On Mon, 23 Aug 2010, Satish Balay wrote: Now that there are more and more standalone scripts - perhaps we need a better consistant way to handle this - but I don't know what that is.. mercurial way is to have 'hg' be the frontend script to all commands. i.e no invocation of individual scripts .. Perhaps we should adopt that? That requires a Mercurial 'install', which is not different than a) or c) namely c) Put PETSC_DIR in your PATH, which is env var manipulation a) Change /usr/bin, which is always in the path (like installing inside Python) I don't understand what you are saying here. Perhaps I should explain what I meant by 'hg' way.. currently we have: ./config/configure.py ./config/install.py ./config/builder.py and perhaps ./config/cmakegen.py All of them need to find buildsystem [and install.py needs to additionally find a priour build - i.e prior PETSC_ARCH used] so the interface coud be a single script ./config/script configure ./config/script install ./config/script builder ./config/script cmakegen Where ./config/script does the autodetection of buildsystem [common code - so that its not replicated in all the scripts - one of the issues Jed has alluded to] - and then invoke the correct underlying functional script underneath. Satish
[petsc-dev] no module named cmakegen
On Mon, 23 Aug 2010 17:21:52 -0500 (CDT), Satish Balay balay at mcs.anl.gov wrote: On Mon, 23 Aug 2010, Satish Balay wrote: Now that there are more and more standalone scripts - perhaps we need a better consistant way to handle this - but I don't know what that is.. mercurial way is to have 'hg' be the frontend script to all commands. i.e no invocation of individual scripts .. Perhaps we should adopt that? Interesting idea. Have one top-level petscconf with subcommands to configure, build (via make, builder.py, cmake), interrogate for linking options, etc. Matt, it doesn't require modification of PYTHONPATH since you would use the path in which the executable resides (may or may not be installed). You wouldn't normally put the executable in your path, instead run /path/to/installed-or-not/petsc-x.y/petscconf subcommand --options The only thing you couldn't do is to move petscconf to some other location (independent of the rest of the PETSc tree). This begs the question of how PETSC_ARCH would be handled. Either there would be separate top-level script for ARCH-specific and ARCH-agnostic functionality, or PETSC_ARCH would need to remain an environment or otherwise specified configuration variable. Jed
[petsc-dev] Problem with conjugate gradient solver
On Aug 23, 2010, at 2:31 PM, Anush Krishnan wrote: Hi, I was trying to compile and run the example file $PETSC_DIR/src/ksp/pc/examples/tutorials/ex3.c, which demonstrates PETSc's preconditioned conjugate gradient solver for a system of linear equations. After compiling, running make runex3 is supposed to throw up the error Divergence because of indefinite preconditioner and running make runex3_pd is supposed to work and give the correct solution. But instead I get the error Other kind of divergence: this should not happen. for the latter. Is there some bug in the code, or are there any other options that need to be set? Hmm, worked for me. Please hg pull; hg update then rebuild PETSc and run the make runex3 runex3_pd again and send the output. I added to that example what reason it did have to maybe help determine the problem. Or you can run the example with the options given in the makefile and also the option -ksp_converged_reason Barry Thanks, Anush
