[petsc-dev] easyinstall for petsc4py
On Thu, Aug 5, 2010 at 9:56 AM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 00:39, Lisandro Dalcin dalcinl at gmail.com wrote: On 4 August 2010 12:44, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro, We would like to help you make it possible for petsc4py to be installed by easyinstall and automatically install PETSc with it, thus making it trivial for Python users to start using petsc4py. How can we help make this happen? $ export PETSC_DIR=/path/to/petsc $ export PETSC_ARCH=arch-name $ easy_install petsc4py This should work and be enough (at least on Linux)... I confirm this works out of the box (on Linux) for prefix installs and non-prefix builds of petsc-3.1 All this assuming a previous installation/build of PETSc is available. Barry, Do you actually mean that easy_install petsc4py should handle the download and build of core PETSc? What I was hoping for is something along the lines of Atlas in numpy. If we find PETSc, use it. If not, do we find mpi4py? If so, use that and build plain vanilla PETSc. If not, build PETSc with mpiuni. That way, it will always work out of the box for everyone, and for savvy users, it does the right thing too. Matt -- 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 -- 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/20100805/4b53afba/attachment.html
[petsc-dev] PetscDLSym called on an empty handle
On Thu, Aug 5, 2010 at 11:40 AM, Dmitry Karpeev karpeev at mcs.anl.gov wrote: What is the intended behavior of PetscDLSym when called on an empty handle: PetscDLSym(handle=PETSC_NULL, symbol, value) My understanding was that this should look for symbol in the symbol table of the main executable. This is based on what happens in the Windows case (#ifdef PETSC_HAVE_WINDOWS_H), but when using dlopen (#ifdef PETSC_HAVE_DLFCN_H), this probably won't behave correctly,as currently implemented. This is because the above call will boil down to value = dlsym((dlhandle_t)0, symbol), which on many systems returns NULL (e.g., on Ubuntu 9.10). There is a relatively easy fix, which is to obtain the handle of the main executable with, for example, dlhandle = dlopen(0,RTLD_LOCAL|RTLD_LAZY) followed by value = dlsym(dlhandle,symbol) I have played around with it on my box, and it appears to work. I can push that fix, if that's what we decide we want, and if it doesn't alter the currently expected behavior. There is one caveat: symbols can be dlsym'ed from the executable only if they are exported as dynamically-loadable, which is not the default behavior for linking executable (so as not to pollute the dynamic symbol table). On linux the linker needs to get -Wl,--export-dynamic, but it would be nice to enable some sort of portable option at compile time. This is sharedLinkerFlags. Matt Incidentally, currently there appears to be no way to supply additional linker flags, as used to be the case with LDFLAGS. Dmitry. -- 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/20100805/659a4d9d/attachment.html
[petsc-dev] PetscDLSym called on an empty handle
On Thu, Aug 5, 2010 at 11:47 AM, Dmitry Karpeev karpeev at mcs.anl.gov wrote: On Thu, Aug 5, 2010 at 11:42 AM, Matthew Knepley knepley at gmail.comwrote: On Thu, Aug 5, 2010 at 11:40 AM, Dmitry Karpeev karpeev at mcs.anl.govwrote: What is the intended behavior of PetscDLSym when called on an empty handle: PetscDLSym(handle=PETSC_NULL, symbol, value) My understanding was that this should look for symbol in the symbol table of the main executable. This is based on what happens in the Windows case (#ifdef PETSC_HAVE_WINDOWS_H), but when using dlopen (#ifdef PETSC_HAVE_DLFCN_H), this probably won't behave correctly,as currently implemented. This is because the above call will boil down to value = dlsym((dlhandle_t)0, symbol), which on many systems returns NULL (e.g., on Ubuntu 9.10). There is a relatively easy fix, which is to obtain the handle of the main executable with, for example, dlhandle = dlopen(0,RTLD_LOCAL|RTLD_LAZY) followed by value = dlsym(dlhandle,symbol) I have played around with it on my box, and it appears to work. I can push that fix, if that's what we decide we want, and if it doesn't alter the currently expected behavior. There is one caveat: symbols can be dlsym'ed from the executable only if they are exported as dynamically-loadable, which is not the default behavior for linking executable (so as not to pollute the dynamic symbol table). On linux the linker needs to get -Wl,--export-dynamic, but it would be nice to enable some sort of portable option at compile time. This is sharedLinkerFlags. Whoops this is wrong. Its something different. Sorry, I meant configure-time option. Yes, it should be a configure option. Does sharedLinkerFlags alter the behavior of CLINKER? I thought we fixed LDFLAGS, but maybe not. Matt Unless there is another way to link an executable. Dmitry. Matt Incidentally, currently there appears to be no way to supply additional linker flags, as used to be the case with LDFLAGS. Dmitry. -- 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 -- 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/20100805/62f48846/attachment.html
[petsc-dev] easyinstall for petsc4py
On Thu, Aug 5, 2010 at 3:48 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 11:59, Matthew Knepley knepley at gmail.com wrote: What I was hoping for is something along the lines of Atlas in numpy. However, looking for Atlas availability is way simpler that asking numpy to download, build and install Atlas for you. I thought that Atlas was built by numpy. Matt -- 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 -- 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/20100805/3504beed/attachment.html
[petsc-dev] something to consider adding to PETSc
Prob will not help that much over Metis for MatMult, but fill-reducing orderings might be a big win for LU. Matt On Thu, Aug 12, 2010 at 1:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: From: Bas Fagginger Auer B.O.FaggingerAuer at uu.nl Date: Wed, 4 Aug 2010 15:02:44 +0200 Subject: Mondriaan 3.0 : Sparse Matrix Partitioning Package Mondriaan 3.0: Sparse matrix partitioning package We would like to announce the availability of version 3.0 of the Mondriaan package. Mondriaan can be used as a preprocessing tool for large sparse matrix-vector multiplications. It subdivides the nonzeros of the matrix into a desired number of parts and generates a permutation of the matrix based on this subdivision. This subdivision and permutation can be used to * minimise communication for sparse matrix-vector multiplication when the matrix is distributed among nodes of a large parallel system, * permute the matrix such that sparse matrix-vector multiplication is cache-oblivious, * permute the matrix to reduce fill-in during LU decomposition. Features of version 3.0: * algorithms to permute the matrix to Separated Block Diagonal or Bordered Block Diagonal form, * improved finegrain quality, * inclusion of the cut-net metric, * Matlab and PaToH interfaces, * visualisation of the partitioning process, * Mondriaan is built as a separate library, facilitating inclusion in existing programs, * extensive documentation with examples and unit tests. The package and related documentation can be obtained from: http://www.staff.science.uu.nl/~bisse101/Mondriaan/ Mondriaan is written in C and distributed under the GNU LGPL license. Rob Bisseling, Bas Fagginger Auer, Albert-Jan Yzelman Dept. Mathematics Utrecht University http://www.staff.science.uu.nl/~bisse101/ -- 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/20100812/e7835e21/attachment.html
[petsc-dev] something to consider adding to PETSc
On Thu, Aug 12, 2010 at 4:10 PM, Barry Smith bsmith at mcs.anl.gov wrote: It claims permute the matrix such that sparse matrix-vector multiplication Does anyone understand what this means? I understand cache-oblivious divideconquer where you just keep splitting until you are in cache (the original paper by Harald), but what is meant here? Matt is cache-oblivious, this would be a great feature to have it worked. Barry On Aug 12, 2010, at 3:07 PM, Matthew Knepley wrote: Prob will not help that much over Metis for MatMult, but fill-reducing orderings might be a big win for LU. Matt On Thu, Aug 12, 2010 at 1:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: From: Bas Fagginger Auer B.O.FaggingerAuer at uu.nl Date: Wed, 4 Aug 2010 15:02:44 +0200 Subject: Mondriaan 3.0 : Sparse Matrix Partitioning Package Mondriaan 3.0: Sparse matrix partitioning package We would like to announce the availability of version 3.0 of the Mondriaan package. Mondriaan can be used as a preprocessing tool for large sparse matrix-vector multiplications. It subdivides the nonzeros of the matrix into a desired number of parts and generates a permutation of the matrix based on this subdivision. This subdivision and permutation can be used to * minimise communication for sparse matrix-vector multiplication when the matrix is distributed among nodes of a large parallel system, * permute the matrix such that sparse matrix-vector multiplication is cache-oblivious, * permute the matrix to reduce fill-in during LU decomposition. Features of version 3.0: * algorithms to permute the matrix to Separated Block Diagonal or Bordered Block Diagonal form, * improved finegrain quality, * inclusion of the cut-net metric, * Matlab and PaToH interfaces, * visualisation of the partitioning process, * Mondriaan is built as a separate library, facilitating inclusion in existing programs, * extensive documentation with examples and unit tests. The package and related documentation can be obtained from: http://www.staff.science.uu.nl/~bisse101/Mondriaan/ Mondriaan is written in C and distributed under the GNU LGPL license. Rob Bisseling, Bas Fagginger Auer, Albert-Jan Yzelman Dept. Mathematics Utrecht University http://www.staff.science.uu.nl/~bisse101/ -- 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 -- 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/20100812/000486da/attachment.html
[petsc-dev] Triangular solve on the GPU
I am no longer as pessimistic as I once was. To start, this is a good report on prefix-sum in parallel: http://www.cs.cmu.edu/~blelloch/papers/Ble93.pdf It can solve first-order recurrences optimally. Higher order recurrences can be reduced to first-order, however it is not work optimal (too big by a factor of the order, m), which seems alright to me. Thus we should be able to solve bandwidth m matrices efficiently. Here is a nice implementation of prefix-sum http://code.google.com/p/cudpp/ This all leads me to believe that for a bounded number of nonzeros per row, we can get an efficient algorithm for triangular solve. 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100816/615d43d0/attachment.html
[petsc-dev] Stop breaking my build
libfast in: /PETSc3/petsc/petsc-dev/src/snes/impls/lsvi lsvi.c: In function 'PetscErrorCode SNESLSVIComputeMeritFunction(_p_Vec*, PetscScalar*)': lsvi.c:137: error: no matching function for call to 'VecNormBegin(_p_Vec*, NormType, PetscScalar*)' /PETSc3/petsc/petsc-dev/include/petscvec.h:468: note: candidates are: PetscErrorCode VecNormBegin(_p_Vec*, NormType, PetscReal*) /PETSc3/petsc/petsc-dev/include/petscvec.h:469: note: PetscErrorCode VecNormBegin(_p_Vec*, NormType) /PETSc3/petsc/petsc-dev/include/petscvec.h:470: note: PetscErrorCode VecNormBegin(_p_Vec*) lsvi.c:138: error: no matching function for call to 'VecNormEnd(_p_Vec*, NormType, PetscScalar*)' /PETSc3/petsc/petsc-dev/include/petscvec.h:471: note: candidates are: PetscErrorCode VecNormEnd(_p_Vec*, NormType, PetscReal*) /PETSc3/petsc/petsc-dev/include/petscvec.h:472: note: PetscReal VecNormEnd(_p_Vec*, NormType) /PETSc3/petsc/petsc-dev/include/petscvec.h:473: note: PetscReal VecNormEnd(_p_Vec*) lsvi.c: In function 'PetscErrorCode SNESLSVIComputeSSFunction(_p_SNES*, _p_Vec*, _p_Vec*)': lsvi.c:207: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + l) = -1.0e+20' lsvi.c:207: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + u) = 1.0e+20' lsvi.c:210: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + l) = -1.0e+20' lsvi.c:215: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + u) = 1.0e+20' lsvi.c: In function 'PetscErrorCode SNESLSVIComputeBsubdifferential(_p_SNES*, _p_Vec*, _p_Vec*, _p_Mat*, _p_Mat*, MatStructure*)': lsvi.c:279: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + l) = -1.0e+20' lsvi.c:279: error: no match for 'operator=' in '*(((PetscScalar*)(((long unsigned int)i) * 16ul)) + u) = 1.0e+20' lsvi.c: In function 'PetscErrorCode SNESLSVICheckDescentDirection(_p_SNES*, _p_Vec*, _p_Vec*, PetscTruth*)': lsvi.c:360: error: no matching function for call to 'VecNormBegin(_p_Vec*, NormType, PetscScalar*)' /PETSc3/petsc/petsc-dev/include/petscvec.h:468: note: candidates are: PetscErrorCode VecNormBegin(_p_Vec*, NormType, PetscReal*) /PETSc3/petsc/petsc-dev/include/petscvec.h:469: note: PetscErrorCode VecNormBegin(_p_Vec*, NormType) /PETSc3/petsc/petsc-dev/include/petscvec.h:470: note: PetscErrorCode VecNormBegin(_p_Vec*) lsvi.c:361: error: no matching function for call to 'VecNormEnd(_p_Vec*, NormType, PetscScalar*)' /PETSc3/petsc/petsc-dev/include/petscvec.h:471: note: candidates are: PetscErrorCode VecNormEnd(_p_Vec*, NormType, PetscReal*) /PETSc3/petsc/petsc-dev/include/petscvec.h:472: note: PetscReal VecNormEnd(_p_Vec*, NormType) /PETSc3/petsc/petsc-dev/include/petscvec.h:473: note: PetscReal VecNormEnd(_p_Vec*) lsvi.c:365: error: no match for 'operator' in 'dpsidotY rhs' lsvi.c: In function 'PetscErrorCode SNESSolve_LSVI(_p_SNES*)': lsvi.c:469: error: cannot convert 'PetscScalar' to 'PetscReal' in assignment lsvi.c:471: error: cannot convert 'PetscScalar' to 'double' in assignment lsvi.c:472: error: cannot convert 'PetscScalar' to 'PetscReal' in argument passing lsvi.c:475: error: cannot convert 'std::complexdouble' to 'PetscReal' in assignment lsvi.c:477: error: cannot convert 'PetscScalar' to 'PetscReal' in argument passing lsvi.c:521: error: cannot convert 'PetscScalar' to 'PetscReal' in assignment lsvi.c:522: error: cannot convert 'PetscScalar' to 'PetscReal' in argument passing lsvi.c:523: warning: cannot pass objects of non-POD type 'struct PetscScalar' through '...'; call will abort at runtime lsvi.c:545: error: cannot convert 'PetscScalar' to 'PetscReal' in assignment lsvi.c:551: error: cannot convert 'PetscScalar' to 'PetscReal' in argument passing ar: lsvi.o: No such file or directory 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100819/0a599e9b/attachment.html
[petsc-dev] Stop breaking my build
On Thu, Aug 19, 2010 at 5:37 PM, Satish Balay balay at mcs.anl.gov wrote: On Thu, 19 Aug 2010, Jed Brown wrote: On Thu, 19 Aug 2010 12:33:05 -0500 (CDT), Satish Balay balay at mcs.anl.gov wrote: Matt, Nobody knows how you build stuff. Atleast mention the configure command used so it can be reproduced and fixed.. Complex: http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/build_arch-linux-complex-gcov_steamroller.log yeah - I guess I should search and find it - but its more of a general comment to Matt. We expect all our users to send complete logs - whenreporting problems. we as developers should be able to include atleat minimal realvent info in such e-mails - which is the configure command used. I did not see the point here since we are all developers and know that 'complex' is broken from the error message. And I fixed the breakage twice before this. 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/20100819/580916d9/attachment.html
[petsc-dev] using consistant username for commits
I am going to vote for consistent formatting the way Jed and I have it now. Is that alright? Matt On Thu, Aug 19, 2010 at 6:56 PM, Satish Balay balay at mcs.anl.gov wrote: Currently some of us let hg choose the 'username' automatically in our commits. Some of us use 'username=value' in our ~/.hgrc - which is consistant - but each of us have a different format here.. petsc:/homes/balaycat ~/.hgrc [ui] verbose=true username=balay at mcs.anl.gov editor=emacs -nw Should we adopt a consistant naming convention for commits? Perhaps the following notation? [which would imply - I should change mine as well] user:Jed Brown jed at 59A2.org thanks, Satish --- asterix:/home/balay/tmp/petsc-devhg log | grep 'user:' | head -100 | sort | uniq user:balay at mcs.anl.gov user:Barry Smith bsmith at mcs.anl.gov user:Dmitry Karpeev karpeev at mcs.anl.gov user:hong at hmacair2010.local user:hong at hzhangmac.mcs.anl.gov user:hong at vis-v410v166.mcs.anl-external.org user:hzhang user:hzhang at mcs.anl.gov user:Jed Brown jed at 59A2.org user:Matt Knepley knepley at gmail.com user:Shri at dhcp147.swwn2.iit.edu user:Shri at mcswl134.mcs.anl.gov user:Shri at mcswl156.mcs.anl.gov user:Shri at mcswl165.mcs.anl.gov user:Shri at mcswl173.mcs.anl.gov user:Shri at shris-macbook-pro.local user:Victor Minden victorminden at gmail.com asterix:/home/balay/tmp/petsc-dev -- -- 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/20100819/d0d286cf/attachment.html
[petsc-dev] proceedings on preliminary work on PETSc with GPUs
I spoke to Scott MacLachlan today (Victor's advisor at Tufts). He would like a little blurb saying how good Victor was this summer. He wants to give it to the Dean and get him to give Victor money for this semester instead of grading. I can write something to start, or feel free if you have time. Matt On Thu, Aug 19, 2010 at 9:14 PM, Barry Smith bsmith at mcs.anl.gov wrote: Folks, Please find attached an easy proceedings paper on the preliminary work Victor did this summer on getting PETSc to run on GPUs. We would appreciate any comments or corrections to Barry, Victor and Matt at the cc list above. Thanks! Barry -- 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/20100819/a333055d/attachment.html
[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, 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, Aug 23, 2010 at 10:38 PM, Jed Brown jed at 59a2.org wrote: 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 .. Okay, I understand Satish. This sounds good. 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. I am fine with PETSC_ARCH being a script parameter, and having a default. Matt 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/20100824/a31c56c5/attachment.html
[petsc-dev] What's the point of D(A/M)GetGlobalVector?
Simply, in PETSc, getFoo() and restoreFoo() operate an object pool. Matt On Fri, Aug 27, 2010 at 11:23 AM, Jed Brown jed at 59a2.org wrote: On Fri, 27 Aug 2010 14:13:01 +0300, Aron Ahmadia aron.ahmadia at kaust.edu.sa wrote: What exactly is the purpose of these routines then? Is there a global Vector associated with a DA? If so, why are the values uninitialized? It's common to need work vectors in places like residual evaluation and Jacobian assembly. There is a little bit of setup cost to allocate a new vector each time, so usually we'd prefer that they be persistent and just reuse them. One option would be to make the user manage this themselves, but that's error prone because it's easy to accidentally alias the work vectors, so instead the DA keeps a cache of vectors. It starts out empty, and each time you call DAGetGlobalVector(), the cache is searched for an available vector. If none are found, a new one is allocated and the cache grows by one. DARestoreGlobalVector() checks a vector back in so it may be used elsewhere. These vectors are destroyed in DADestroy(). 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/20100827/3e5116e5/attachment.html
[petsc-dev] What's the point of D(A/M)GetGlobalVector?
I agree with DACreateMatrix().
Matt
On Fri, Aug 27, 2010 at 1:24 PM, Jed Brown jed at 59a2.org wrote:
On Fri, 27 Aug 2010 16:13:14 +0300, Aron Ahmadia
aron.ahmadia at kaust.edu.sa wrote:
Not to mention the various Get routines that are actually used to create
things, such as DAGetMatrix.
I think that should have been named DACreateMatrix(). Other XGetY() are
just accessors which create a managed object if needed. When there is a
Get/Restore pair, it implies that the access to that managed resource
has some sort of exclusivity. I think
{Get,Restore}{Local,Global}Vector() are actually the only functions with
that naming scheme that really manage a pool.
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/20100827/3c4594d7/attachment.html
[petsc-dev] What's the point of D(A/M)GetGlobalVector?
I would support a name change to Create(). However, we should be really sure before we do stuff like that since nothing pisses people off (Wolfgang) like name changes. Matt On Fri, Aug 27, 2010 at 5:49 PM, Barry Smith bsmith at mcs.anl.gov wrote: Hmmm, petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetColoring(DM,ISColoringType,const MatType,ISColoring*); petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetMatrix(DM, const MatType,Mat*); petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetInterpolation(DM,DM,Mat*,Vec*); petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetInterpolationScale(DM,DM,Mat,Vec*); petscda.h:EXTERN PetscErrorCode PETSCDM_DLLEXPORT DMGetAggregates(DM,DM,Mat*); should all of these be Create? In my mind usually Get means get something intrinsic to the underlying object (some property of it for example); Create means generate a new thing that while it may be associated with the DA is not owned or controlled by the DA. Another way to organize is Create() implies you later Destroy() that object, while for things you Get you do something else (like restore). I'm inclined to change all of these ones to Create() since they are all Destroyed() Barry On Aug 27, 2010, at 11:10 AM, Jed Brown wrote: On Fri, 27 Aug 2010 12:00:32 -0400, Kai Germaschewski kai.germaschewski at unh.edu wrote: And it also requires some more memory management framework which would call upon caches to expire long-unused objects when memory is running low. How would you detect this? Note that further allocation may be done external to PETSc, and perhaps even in a separate process. We're not in a managed environment, we can't get a reliable time to GC. If we could get that sort of signal, then I would be for such caching at all times, but I don't think we can, in which case I still think managed/pooled access versus owned creation needs to be explicitly different. 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/20100828/0ed5ce22/attachment.html
[petsc-dev] [GPU] Performance on Fermi
On Fri, Aug 27, 2010 at 7:19 PM, Keita Teranishi keita at cray.com wrote: Barry, Yes. It improves the performance dramatically, but the execution time for KSPSolve stays the same. MatMult 5.2 Gflops I will note that to put the matvec on the GPU you will also need -mat_type aijcuda. Matt Thanks, Keita Teranishi Scientific Library Group Cray, Inc. keita at cray.com -Original Message- From: petsc-dev-bounces at mcs.anl.gov [mailto:petsc-dev-bounces at mcs.anl.gov] On Behalf Of Barry Smith Sent: Friday, August 27, 2010 2:15 PM To: For users of the development version of PETSc Subject: [petsc-dev] [GPU] Performance on Fermi PETSc-dev folks, Please prepend all messages to petsc-dev that involve GPUs with [GPU] so they can be easily filtered. Keita, To run src/ksp/ksp/examples/tutorials/ex2.c with CUDA you need the flag -vec_type cuda Note also that this example is fine for simple ONE processor tests but should not be used for parallel testing because it does not do a proper parallel partitioning for performance Barry On Aug 27, 2010, at 2:04 PM, Keita Teranishi wrote: Hi, I ran ex2.c with a matrix from 512x512 grid. I set CG and Jacobi for the solver and preconditioner. GCC-4.4.4 and CUDA-3.1 are used to compile the code. BLAS and LAPAKCK are not optimized. MatMult Fermi:1142 MFlops 1 core Istanbul: 420 MFlops KSPSolve: Fermi:1.5 Sec 1 core Istanbul: 1.7 Sec Keita Teranishi Scientific Library Group Cray, Inc. keita at cray.com -Original Message- From: petsc-dev-bounces at mcs.anl.gov [mailto: petsc-dev-bounces at mcs.anl.gov] On Behalf Of Satish Balay Sent: Friday, August 27, 2010 1:49 PM To: For users of the development version of PETSc Subject: Re: [petsc-dev] Problem with petsc-dev On Fri, 27 Aug 2010, Satish Balay wrote: There was a problem with tarball creation for the past few days. Will try to respin manually today - and update you. the petsc-dev tarball is now updated on the website.. 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/20100828/38cd38a9/attachment.html
[petsc-dev] [GPU] Performance of ex19
On Tue, Aug 31, 2010 at 7:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Aug 31, 2010, at 3:14 PM, Keita Teranishi wrote: Does this PETSc use timers from CUDA? No, didn't know there were timers in CUDA. Yes, I use them when I really want to know how well I an utilizing the board, vs. how much improvement overall I can expect in the code. When compared with PETSc timers, they can give us an idea of the transfer overhead, which I do in my GPU FEM code. Matt We actually want to use the real world timers because each method is actually a call on the CPU so real world time is what matters. Barry Keita Teranishi Scientific Library Group Cray, Inc. keita at cray.com *From:* petsc-dev-bounces at mcs.anl.gov [mailto: petsc-dev-bounces at mcs.anl.gov] *On Behalf Of *Barry Smith *Sent:* Tuesday, August 31, 2010 2:03 PM *To:* For users of the development version of PETSc *Subject:* Re: [petsc-dev] [GPU] Performance of ex19 Your MatMult is now slower. Are your results reproducible, if you run 5 times how similar are them? Barry On Aug 31, 2010, at 2:57 PM, Keita Teranishi wrote: VecDot 2 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecMDot 2024 1.0 1.1560e+00 1.0 2.54e+09 1.0 0.0e+00 0.0e+00 0.0e+00 18 29 0 0 0 32 29 0 0 0 2201 VecNorm 2096 1.0 3.5999e-01 1.0 1.68e+08 1.0 0.0e+00 0.0e+00 0.0e+00 6 2 0 0 0 10 2 0 0 0 466 VecScale2092 1.0 2.1599e-01 1.0 8.37e+07 1.0 0.0e+00 0.0e+00 0.0e+00 3 1 0 0 0 6 1 0 0 0 387 VecCopy 2072 1.0 5.5997e-02 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 1 0 0 0 0 2 0 0 0 0 0 VecSet70 1.0 8.0004e-03 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecAXPY 108 1.0 2.7999e-02 1.0 8.64e+06 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 1 0 0 0 0 309 VecWAXPY 68 1.0 7.e-03 1.0 2.72e+06 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 340 VecMAXPY2092 1.0 5.8399e-01 1.0 2.71e+09 1.0 0.0e+00 0.0e+00 0.0e+00 9 31 0 0 0 16 31 0 0 0 4634 VecScatterBegin5 1.0 4.0002e-03 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecReduceArith 2 1.0 3.e-03 1.0 1.60e+05 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 040 VecReduceComm 1 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecCUDACopyTo 10 1.0 3.e-03 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 VecCUDACopyFrom5 1.0 4.0002e-03 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 SNESSolve 1 1.0 3.6119e+00 1.0 8.87e+09 1.0 0.0e+00 0.0e+00 0.0e+00 56100 0 0 0 100100 0 0 0 2456 SNESLineSearch 2 1.0 4.0002e-03 1.0 5.49e+06 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 1374 SNESFunctionEval 3 1.0 4.0002e-03 1.0 2.52e+06 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 630 SNESJacobianEval 2 1.0 3.1199e-01 1.0 3.85e+07 1.0 0.0e+00 0.0e+00 0.0e+00 5 0 0 0 0 9 0 0 0 0 123 KSPGMRESOrthog 2024 1.0 1.7120e+00 1.0 5.09e+09 1.0 0.0e+00 0.0e+00 0.0e+00 26 57 0 0 0 47 57 0 0 0 2972 KSPSetup 2 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 KSPSolve 2 1.0 3.2919e+00 1.0 8.83e+09 1.0 0.0e+00 0.0e+00 0.0e+00 51 99 0 0 0 91 99 0 0 0 2681 PCSetUp2 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 PCApply 2024 1.0 4.7998e-02 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 1 0 0 0 0 1 0 0 0 0 0 MatMult 2092 1.0 8.9998e-01 1.0 3.32e+09 1.0 0.0e+00 0.0e+00 0.0e+00 14 37 0 0 0 25 37 0 0 0 3689 MatAssemblyBegin 2 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 MatAssemblyEnd 2 1.0 1.2000e-02 1.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 MatZeroEntries 2 1.0 0.e+00 0.0 0.00e+00 0.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 0 MatFDColorApply2 1.0 3.1199e-01 1.0 3.85e+07 1.0 0.0e+00 0.0e+00 0.0e+00 5 0 0 0 0 9 0 0 0 0 123 MatFDColorFunc42 1.0 7.e-03 1.0 3.53e+07 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 4410 -- 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:
Should BuildSystem download updated external packages when they are out of date?
On Fri, Oct 2, 2009 at 9:11 AM, Richard Tran Mills rmills at climate.ornl.govwrote: BuildSystem Folks (Matt, mainly), This is not really a problem for me since I know about this behavior already, but I note that it can cause significant confusion when configure.py has been asked to download a package and a very out of date version of that package already exists in $PETSC_DIR/externalpackages. In this case, configure.py doesn't do anything since the package is already there, but in some cases the interfaces have changed and that package isn't actually usable. For instance, if hypre-2.0.0 is present, it won't work with the current petsc-dev, but the configure proceeds anyway, even though things won't work unless hypre-2.4.0b is downloaded. In such a case, deleting the hypre-2.0.0 directory and re-running configure.py will fix the problem, but it seems like this isn't very user-friendly and I know that it does cause some confusion. I am no BuildSystem hacker (I think I've committed a change maybed once, in 2005?). Can someone tell me if it is reasonable to make configure.py download the new package if the old one is too out of date? This is the versioning problem, which has no good resolution. The way I understand things, with a given version of PETSc, this problem cannot arise, UNLESS it is petsc-dev. I am willing to live with this problem in petsc-dev, rather than introduce some versioning scheme which is just as broken as the current scheme. Matt Sincerely, Richard -- 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/20091002/77bddb79/attachment.html
Where are the gcov HTML pages?
-- 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/20091012/b70a1172/attachment.html
Subsecond sleep
No. Matt On Fri, Oct 16, 2009 at 5:02 AM, Jed Brown jed at 59a2.org wrote: I sometimes want to slow down animation with a small problem size and -draw_pause is generally does what I want, but it can only take integer arguments and pausing for a whole second every time is often too much. There are subsecond sleep functions (like usleep and nanosleep) in POSIX, and I've rolled my own micro-sleep command-line option more than once now. Is there a compelling reason not to make -draw_pause and PetscSleep take a real value, thus offering higher resolution when it is available? 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/20091016/5a7b6488/attachment.html
Fwd: People who need to solve large systems?
This stuff is very cool, and based on very interesting mathematics. Anyone have matrices of this type? Thanks, Matt -- Forwarded message -- From: Gary Miller glmil...@cs.cmu.edu Date: Tue, Oct 20, 2009 at 2:46 PM Subject: People who need to solve large systems? To: Matthew Knepley knepley at gmail.com Cc: Yiannis Koutis jkoutis at cs.cmu.edu, Dave Tolliver tolliver at cs.cmu.edu Hi Matt, As you may know we have been developing a fast solver of symmetric diagonally dominate systems. We recent got some money for Microsoft to release a public version of the solver and are looking for users. The soft will be free, for now, and we can help people come up to speed on using it. We are looking for people who are solving problems with at lease 400,000 variables in 2D or 100,000 in 3D. For smaller systems other soft seems to work OK. Given that you worked on Petsc you may have a better idea who we could help. Thanks Gary Miller glmiller at cs.cmu.edu -- 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/20091021/770a2325/attachment.html
person who wrote PetscRandomGetValueReal() PetscRandomGetValueImaginary()
Done. However, Igot an unholy merge on builder.py. It is definitely screwed up. I can fix it when I get home on Sunday. Matt On Fri, Oct 23, 2009 at 2:07 PM, Barry Smith bsmith at mcs.anl.gov wrote: PetscRandomGetValueReal() and PetscRandomGetValueImaginary() have no mention in their manual pages what they do? Do they return random numbers with a zero imaginary part and a zero real part respectively? Manual page does not see. Also PetscRandomGetValue() does not have .seealso to these two functions, nor do these two functions have .seealso to the other. Whoever wrote these things please fix this. Barry -- 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/20091023/de058916/attachment.html
person who wrote PetscRandomGetValueReal() PetscRandomGetValueImaginary()
On Fri, Oct 23, 2009 at 2:31 PM, Barry Smith bsmith at mcs.anl.gov wrote: I thought I was working on builder.py? Crude, yes, but the way I want it :-). Were you adding code to builder.py? Yep. I am all for this. However, two people on such a small piece of code is hard. Also, didn't you ask me to put that stuff in? Matt Barry On Oct 23, 2009, at 2:26 PM, Matthew Knepley wrote: Done. However, Igot an unholy merge on builder.py. It is definitely screwed up. I can fix it when I get home on Sunday. Matt On Fri, Oct 23, 2009 at 2:07 PM, Barry Smith bsmith at mcs.anl.gov wrote: PetscRandomGetValueReal() and PetscRandomGetValueImaginary() have no mention in their manual pages what they do? Do they return random numbers with a zero imaginary part and a zero real part respectively? Manual page does not see. Also PetscRandomGetValue() does not have .seealso to these two functions, nor do these two functions have .seealso to the other. Whoever wrote these things please fix this. Barry -- 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 -- 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/20091023/43cf5a77/attachment.html
PetscRandomGetValue(), PetscRandomGetValueReal(), PetscRandomGetValueImaginary()
I am fine with that as long as the doc is clear. Matt On Mon, Oct 26, 2009 at 3:19 PM, Barry Smith bsmith at mcs.anl.gov wrote: There is a lack of symmetry in the meaning of PetscRandomGetValueReal() and PetscRandomGetValueImaginary(). The real returns a PetscReal with a random value in it. The imaginary returns a complex number with zero real part and some imaginary part. I have changed PetscRandomSetInterval() to allow the real or imaginary part of the interval to be zero. Thus one can get pure real complex numbers by setting the complex part of low to high and get pure imaginary complex numbers by setting the real part of low to high. Then we can eliminate PetscRandomGetValueImaginary(). I dislike it (since it is ugly, has no real equivalent version (for example to get a random number that is zero in the imaginary part I need to call PetscRandomGetValueReal() and then stick that real value into a complex number.)) What do you think? Barry -- 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/20091026/9865e8a7/attachment.html
changes for PetscMap
I wanted that 10 years ago. Matt On Tue, Oct 27, 2009 at 4:37 PM, Barry Smith bsmith at mcs.anl.gov wrote: PetscMap is a strange beast in PETSc. 1) it is not a PetscObject (that is it has no PETSc header) 2) it is used as a PetscMap* instead of PetscMap like most objects 3) it does not have a PetscMapCreate() instead it has a PetscMapInitialize() which is like a create except it does not malloc its memory 4) It does have a PetscMapDestroy() that DOES free the space. 5) Sometimes a PetscMalloc() is called before PetscMapInitialize() and sometimes a PetscMap is declared and a of the variable is passed in In this case it will crash if one calls PetscMapDestroy() is called on it. So instead one must call PetscFree(map-range); to free the interior space. This strange creature evolved over time because I did not want PetscMap to be a full heavy weight object, but it pretty much ended up being one anyways (for example it has reference counting). For a long time I hid PetscMap in the less public part of PETSc didn't want most people to have to deal with it. I still don't want it to be something most PETSc users need ever see, but it is time to fix it up and make it more consistent with other objects. So I propose to make a PetscMap just like other PETSc objects, with create(), destroy(), opaque definition except I will still not make it have a PETSc header. This will not require much change in the code but will simplify its usage. Any comments. Barry -- 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/20091027/4bd34f2c/attachment.html
Move src/sys/viewerimpl.h to include/private ?
Nope, get rid of it. Matt On Wed, Oct 28, 2009 at 12:32 PM, Jed Brown jed at 59a2.org wrote: I don't think external projects should have to include ../src/whatever because this doesn't work if PETSc is installed and it's a screwy API (even if most users don't see it). Any objections to this? 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/20091028/e4957b27/attachment.html
ML symbols in petscksp.so
You always have to link the ML library if you configure for ML, right? Matt On Wed, Oct 28, 2009 at 3:34 PM, Jed Brown jed at 59a2.org wrote: Something recently caused these symbols to get lost, meaning that users have to explicitly link the static libml.a. 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/20091028/12013374/attachment.html
ML symbols in petscksp.so
On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: You always have to link the ML library if you configure for ML, right? No, all the third party libs used to be put into the PETSc shared libs (but not the static libs). The easiest way to do this is with -Wl,--whole-archive though I haven't looked at the build system to see if this is how it is actually being done. All the others still behave this way, but ML is no longer included. Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Matt So if you are using shared libs, you only need to link libpetsc*.so. This is recommended practice with shared libs, you only explicitly link the interface libraries (those that your code actually calls into) and let the linker handle the dependencies. Of course when using static libs, you need to explicitly link all the dependencies. 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/20091028/d42e85c7/attachment.html
most efficient way to use local CSR matrix?
On Thu, Oct 29, 2009 at 1:46 PM, Chris Kees christopher.e.kees at usace.army.mil wrote: Mark, Barry, Thanks for the help. For now I'm sticking with the approach of copying the csr matrix and using the csr data structures to do the preallocations. I'll eventually get around to writing the code for assembling directly into the petsc matrix. I have two more questions. 1) On 1 processor, the linear solver is not converging in 1 iteration using -pc_type lu -pc_factor_mat_solver_package spooles. It converges in one iteration in parallel or on a single processor if I set -mat_type seqaij. Also, if I go back to the old way of constructing the matrix it DOES converge in 1 iteration on 1 processor. That is, if I replace the MatCreate/MatSetSizes/... calls from the earlier email, with what I had originally: MatCreateMPIAIJ(Py_PETSC_COMM_WORLD,n,n,N,N,1,PETSC_NULL,max_nNeighbors,PETSC_NULL,self-m); then the solver converges in 1 iteration as expected. This wouldn't be a big deal except that we're trying to verify that our quadratic finite elements are working, and the behavior for p1 and p2 elements is different. The above observations are for p2, while all the cases work as expected for p1. Should we just not be using mpiaij at all on 1 processor? No, you have a problem. 2) In the code snippet I took from the petsc example there are two preallocation calls (see below). Is that correct, or should I be checking the matrix type and calling only the preallocation function for the actual matrix type? i.e. something like MatCreate(... MatSetSizes(... MatSetFromOptions(... MatGetType(... if type==mpiaij: MatMPIAIJSetPreallocationCSR(... It does not hurt to call them all. Matt Chris On Oct 21, 2009, at 11:50 AM, Mark F. Adams wrote: Chris, just a note, Perhaps I missed something here but do something similar to you, eg overlapping partitions, and PETSc is setup very well to be intrusive in your code (I sometimes write a little 'addvalue' wrapper) and assemble your FE matrices directly into a global matrix. You use the (global) MatSetValues(...) and set the matrix option MAT_IGNORE_OFF_PROC_ENTRIES (or something like that) so that these off processor matrix entries, which are computed redundantly, are thrown away and you get the correct matrix. As Barry said you don't need exact non-zero counts to allocate storage in PETSC matrices, just don't underestimate. Mark On Oct 21, 2009, at 9:16 AM, Barry Smith wrote: On Oct 20, 2009, at 10:13 PM, Chris Kees wrote: Thanks. Just to make sure I'm following, when I create the matrix I do: MatCreate(PETSC_COMM_WORLD,self-m); MatSetSizes(self-m,n,n,N,N); MatSetType(self-m,MATMPIAIJ); MatSetFromOptions(self-m); MatSeqAIJSetPreallocationCSR(self-m,SMP(L)-A.rowptr,SMP(L)-A.colind,(double*)(SMP(L)-A.nzval)); MatMPIAIJSetPreallocationCSR(self-m,SMP(L)-A.rowptr,SMP(L)-A.colind,(double*)(SMP(L)-A.nzval)); and then I copy the matrix at each Newton iteration using the code in the first message below. You said ...PreallocationCSR() does the copy very efficiently, but I don't think I'm supposed to repeatedly call it, right? Looking at the output some more it does seem like building the preconditioner initially is taking much more time than the initial pass through MatSetValues. If the matrix nonzero structure stays the same then yes you need call MatMPIAIJSetPreallocationCSR() only once and use the MatSetValues() calls each Newton step to update the nonzeros. Barry Chris On Oct 20, 2009, at 8:32 PM, Barry Smith wrote: Here's the deal. In parallel PETSc does not use a single CSR matrix on each process to hold the MPIAIJ matrix. Hence if you store the matrix on a process as a single CSR matrix then it has to be copied into the PETSc datastructure. MatMPIAIJSetPreallocationCSR() does the copy very efficiently. But you are right, until you free YOUR rowpt[], colind[] and a[] there are two copies of the matrix. One could argue that this is ok, because anyways any preconditioner worth anything will take up at least that much memory later anyways. For example, if you use the PETSc default preconditioner, block Jacobi with ILU(0) on each block it will take pretty much the same amount of memory. For people who use SOR or some other preconditioner that requires very little memory this is not satisfactory because they feel they could run larger problems without the copy. I strongly recommend you use MatMPIAIJSetPreallocationCSR() and live with any memory limitation. The reason is that doing more than that has orders of magnitude more pain with generally little payoff. If you like pain then you can 1) change your code to not build directly into CSR, instead call MatSetValuesLocal() as you compute the entries. With this you need to figure out the preallocation which can be painful code. 2) write an entire matrix class that stores the matrix like you store it, not
missing CHKERRQ in MatNullSpaceRemove()
Pushed.
Matt
On Thu, Oct 29, 2009 at 1:59 PM, Lisandro Dalcin dalcinl at gmail.com wrote:
While trying to update petsc4py to latest changes in petsc-dev repo,
I've noticed that at the very end of MatNullSpaceRemove() we have:
if (sp-remove){
ierr = (*sp-remove)(sp,vec,sp-rmctx);
}
PetscFunctionReturn(0);
}
Any good reason for not CHKERRQ(ierr) after calling the userd-defined
remove function? I had a hard time figuring out what's going on
because a Python exception got lost at that point... Can any of you
fix this for me, please? BTW, perhaps CHKMEMQ macros should be used
there?
Thanks.
--
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
--
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/20091029/22b1856b/attachment.html
ML symbols in petscksp.so
On Thu, Oct 29, 2009 at 4:01 PM, Satish Balay balay at mcs.anl.gov wrote:
On Thu, 29 Oct 2009, Barry Smith wrote:
On Oct 29, 2009, at 3:52 PM, Lisandro Dalcin wrote:
On Thu, Oct 29, 2009 at 4:45 PM, Jed Brown jed at 59a2.org wrote:
I realize that the real problem here was OpenCV's libml and the fact
that linkers don't resolve symbols by starting with the most recent
-L
path [*], but we should at least remember that putting
-L{PETSC_LIB_DIR}
at the beginning of the line can completely change the way symbols
are
resolved.
I think that the real problem here is that developers should be
smarter and they should not use such short names for a library... ml
.. just two characters... What ml stand for? mailing list? the
internet country code for Mali at Africa? milliliter ? Markup
Language, ML the programming language? Well... I'll stop here...
:-)
IMHO, I think that what Jed suggested in previous mail about using
-Wl,-whole-archive ${PETSC_EXTERNAL_LIB} -Wl,-no-whole-archive when
--with-shared is in action could be a VERY good idea... Then PETSc
link lines will not need to refer at all to these static libs from
external packages...
This works for folks who use PETSc - and nothing else. But once you
have 2 packages doing this [say both add in hypre symbols] - and then
some user wants to use these two packages - you have conflicts. [esp
with multiple copies of global variables etc..]
The ideal solution is to have every library have its own .so
file.. [but this is not easy]
I am with Satish here. This smells like sticking pregenerated template stuff
in libraries,
which eventually gets heinous, and everyone always goes back to all headers.
I am
for keeping each package in its own libraries.
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/20091029/5d58c8da/attachment.html
PETSc in double-double and quad-double...
On Wed, Nov 4, 2009 at 2:06 PM, Barry Smith bsmith at mcs.anl.gov wrote: This is tricky because some C/C++ compilers long double uses 128 bits of space but actually (on Intel) only uses 80 of the bits (those are the bits that floating point unit handles). So you do not really get 128 bits. Also MPI may not properly handle the 128 bit doubles. I figured that his types were just C++ types once he said they were provided by a package. I am investigating qd now. Is there any MPI implementation that uses qd? Do you need MPI? Can't we just make a type the correct number of bytes long? Matt Barry On Nov 4, 2009, at 1:33 PM, Matthew Knepley wrote: If you are alright with EVERYTHING running with that, it already works. Just set PetscScalar to that type. I would help you setup a configure switch for it if needed. If you only want it for some operations, we would have to hear more specifics. Thanks, Matt On Wed, Nov 4, 2009 at 10:45 AM, Todd Munson tmunson at mcs.anl.gov wrote: Barry and Matt, I was wondering how hard it would be to modify PETSc to support double-double and quad-double arithmetic using the QD package from LBL? Its looking more and more likely that I may need this functionality for some upcoming projects that have bad scaling issues and I don't want to have to reimplement KSP and PC methods... Cheers, Todd. -- 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 -- 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/20091104/eb82322e/attachment.html
PETSc in double-double and quad-double...
On Wed, Nov 4, 2009 at 2:21 PM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: On Wed, Nov 4, 2009 at 2:06 PM, Barry Smith bsmith at mcs.anl.gov mailto:bsmith at mcs.anl.gov wrote: This is tricky because some C/C++ compilers long double uses 128 bits of space but actually (on Intel) only uses 80 of the bits (those are the bits that floating point unit handles). So you do not really get 128 bits. Also MPI may not properly handle the 128 bit doubles. I figured that his types were just C++ types once he said they were provided by a package. QD is honest quad-double (32 bytes, all of them significant) http://crd.lbl.gov/~dhbailey/mpdist/http://crd.lbl.gov/%7Edhbailey/mpdist/ They are C++ types with appropriate overloading, but the operations are implemented in terms of conventional double-precision where as long double is a different beast. Okay, then this should be no harder than complex. I am investigating qd now. Is there any MPI implementation that uses qd? Do you need MPI? Can't we just make a type the correct number of bytes long? I think so (on homogeneous hardware), but you have to create your own version of each MPI_Op that does the right thing with this longer type. Yep, we do that now for several things in PETSc. Matt 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/20091104/74a5998e/attachment.html
who broke PCFieldSplit code in petsc-dev?????????
Has this been broken for a while? It bombs in MatGetSubMatrix(), and this had an API change. The last change in fieldsplit.c is in July, by Jed. Matt On Wed, Nov 11, 2009 at 5:16 PM, Barry Smith bsmith at mcs.anl.gov wrote: See for example http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/examples_arch-linux-gcc-pgf90_grind.log search for PCSetUp_FieldSplit(). Please fix ASAP. Thanks. Barry And remember before pushing you should run make alltests to make sure you haven't introduced problems. -- 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/2009/0c705f4d/attachment.html
who broke PCFieldSplit code in petsc-dev?????????
I have 5 args for fieldsplit.c:290. Matt On Wed, Nov 11, 2009 at 5:27 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Wed, Nov 11, 2009 at 8:23 PM, Matthew Knepley knepley at gmail.com wrote: Has this been broken for a while? It bombs in MatGetSubMatrix(), and this had an API change. The last change in fieldsplit.c is in July, by Jed. BTW, the #arg is wrong, it should be #5... Matt On Wed, Nov 11, 2009 at 5:16 PM, Barry Smith bsmith at mcs.anl.gov wrote: See for example http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/examples_arch-linux-gcc-pgf90_grind.log search for PCSetUp_FieldSplit(). Please fix ASAP. Thanks. Barry And remember before pushing you should run make alltests to make sure you haven't introduced problems. -- 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 -- 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 -- 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/2009/37d14f80/attachment.html
who broke PCFieldSplit code in petsc-dev?????????
Fixed. Matt On Wed, Nov 11, 2009 at 5:46 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Wed, Nov 11, 2009 at 8:41 PM, Matthew Knepley knepley at gmail.com wrote: I have 5 args for fieldsplit.c:290. But the traceback Barry posted says arg #6 is wrong... In short, MatGetSubMatrix() needs a little fix in a couple of PetscValidHeaderSpecific ... Matt On Wed, Nov 11, 2009 at 5:27 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Wed, Nov 11, 2009 at 8:23 PM, Matthew Knepley knepley at gmail.com wrote: Has this been broken for a while? It bombs in MatGetSubMatrix(), and this had an API change. The last change in fieldsplit.c is in July, by Jed. BTW, the #arg is wrong, it should be #5... Matt On Wed, Nov 11, 2009 at 5:16 PM, Barry Smith bsmith at mcs.anl.gov wrote: See for example http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/examples_arch-linux-gcc-pgf90_grind.log search for PCSetUp_FieldSplit(). Please fix ASAP. Thanks. Barry And remember before pushing you should run make alltests to make sure you haven't introduced problems. -- 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 -- 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 -- 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 -- 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 -- 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/2009/12281e60/attachment.html
who broke PCFieldSplit code in petsc-dev?????????
On Wed, Nov 11, 2009 at 6:02 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt. That is not the fix; that is irrelevent. I know. According to my comment, I fixed the check, not the original problem. Matt A couple of weeks ago these examples ran fine and did not crash. Now they crash. Perhaps it was not a change to fieldsplit that caused the recent crashes, but it is a recent change to something. The examples ran fine after the change to MatGetSubMatrix() I am pretty sure. If we were smart we would keep the results of each nights nightly builds and then we could easily check what DAY things broke. Satish please have it save the old days stuff for each day. Barry On Nov 11, 2009, at 5:56 PM, Matthew Knepley wrote: Fixed. Matt On Wed, Nov 11, 2009 at 5:46 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Wed, Nov 11, 2009 at 8:41 PM, Matthew Knepley knepley at gmail.com wrote: I have 5 args for fieldsplit.c:290. But the traceback Barry posted says arg #6 is wrong... In short, MatGetSubMatrix() needs a little fix in a couple of PetscValidHeaderSpecific ... Matt On Wed, Nov 11, 2009 at 5:27 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Wed, Nov 11, 2009 at 8:23 PM, Matthew Knepley knepley at gmail.com wrote: Has this been broken for a while? It bombs in MatGetSubMatrix(), and this had an API change. The last change in fieldsplit.c is in July, by Jed. BTW, the #arg is wrong, it should be #5... Matt On Wed, Nov 11, 2009 at 5:16 PM, Barry Smith bsmith at mcs.anl.gov wrote: See for example http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/examples_arch-linux-gcc-pgf90_grind.log search for PCSetUp_FieldSplit(). Please fix ASAP. Thanks. Barry And remember before pushing you should run make alltests to make sure you haven't introduced problems. -- 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 -- 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 -- 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 -- 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 -- 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 -- 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/2009/d472425a/attachment.html
Fwd: [computational.science] CFP: Workshop on Large-Scale Parallel Processing (LSPP'10)
-- Forwarded message -- From: Robert A. van de Geijn r...@cs.utexas.edu Date: Fri, Nov 13, 2009 at 3:21 PM Subject: Fwd: [computational.science] CFP: Workshop on Large-Scale Parallel Processing (LSPP'10) To: flame_cs at cs.utexas.edu Begin forwarded message: *From: *Darren Kerbyson djk at lanl.gov *Date: *November 13, 2009 9:17:55 AM CST *To: *Computational Science Mailing List computational.science at lists.iccsa.org *Subject: **[computational.science] CFP: Workshop on Large-Scale Parallel Processing (LSPP'10)* [Please accepts our apologies if you receive multiple copies] - Call for papers: Workshop on LARGE-SCALE PARALLEL PROCESSING to be held in conjunction with IEEE International Parallel and Distributed Processing Symposium Atlanta, Georgia April 23rd, 2010 SUBMISSION DEADLINE: December 14th 2009 Selected work presented at the workshop will be published in a special issue of Parallel Processing Letters. - The workshop on Large-Scale Parallel Processing is a forum that focuses on computer systems that utilize thousands of processors and beyond. This is a very active area given the goals of many researchers world-wide to enhance science-by-simulation through installing large-scale multi-petaflop systems at the start of the next decade. Large-scale systems, referred to by some as extreme-scale and Ultra-scale, have many important research aspects that need detailed examination in order for their effective design, deployment, and utilization to take place. These include handling the substantial increase in multi-core on a chip, the ensuing interconnection hierarchy, communication, and synchronization mechanisms. The workshop aims to bring together researchers from different communities working on challenging problems in this area for a dynamic exchange of ideas. Work at early stages of development as well as work that has been demonstrated in practice is equally welcome. Of particular interest are papers that identify and analyze novel ideas rather than providing incremental advances in the following areas: - LARGE-SCALE SYSTEMS : exploiting parallelism at large-scale, the coordination of large numbers of processing elements, synchronization and communication at large-scale, programming models and productivity - MULTI-CORE : utilization of increased parallelism on a single chip (MPP on a chip such as the Cell and GPUs), the possible integration of these into large-scale systems, and dealing with the resulting hierarchical connectivity. - NOVEL ARCHITECTURES AND EXPERIMENTAL SYSTEMS : the design of novel systems, the use of processors in memory (PIMS), parallelism in emerging technologies, future trends. - APPLICATIONS : novel algorithmic and application methods, experiences in the design and use of applications that scale to large-scales, overcoming of limitations, performance analysis and insights gained. Results of both theoretical and practical significance will be considered, as well as work that has demonstrated impact at small-scale that will also affect large-scale systems. Work may involve algorithms, languages, various types of models, or hardware. - SUBMISSION GUIDELINES Papers should not exceed eight single-space pages (including figures, tables and references) using a 12-point font on 8.5x11 inch pages. Submissions in PostScript or PDF should be made using EDAS (www.edas.info). Informal enquiries can be made to djk at lanl.gov. Submissions will be judged on correctness, originality, technical strength, significance, presentation quality and appropriateness. Submitted papers should not have appeared in or under consideration for another venue. IMPORTANT DATES Submission deadline: December 14th 2009 Notification of acceptance: January 15th 2010 Camera-Ready Papers due: February 1st 2010 - WORKSHOP CO-CHAIRS Darren J. Kerbyson Los Alamos National Laboratory Ram RajamonyIBM Austin Research Lab Charles Weems University of Massachusetts STEERING COMMITTEE Johnnie Baker Kent State University Alex Jones University of Pittsburgh H.J. Siegel Colorado State University PROGRAM COMMITTEE Ghoerge Almasi IBM T.J. Watson Research Lab Taisuke BokuUniversity of Tsukuba, Japan Marco Daneluto University of Pisa Martin Herbordt Boston University Lei Huang University of Houston Daniel Katz University of Chicago Jesus Labarta Barcelona Supercomputer Center, Spain John Michalakes NCAR, Boulder Celso MendesUniversity of Illinois Urbana-Champagne Bernd Mohr
Why did you removed PETSC_ARCH_NAME variable in makefiles?
Why not just hash the RDict.db?
Matt
On Fri, Nov 27, 2009 at 1:24 PM, Lisandro Dalcin dalcinl at gmail.com wrote:
On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay balay at mcs.anl.gov wrote:
The way I look at it - the primary complexity here is from PETSc
buildsystem.
Because PETSc buildsystem supports both types of builds - 'prefix' and
'regular' - one is forced to use PETSC_ARCH 'during build process' -
even with a prefix build [even though it doesn't make any sense to
this gnu build model].
Once we force this on users - I don't think we are justified in
removing traces of this intermediate step - if slepc/petsc4py would
like to use info.
Indeed. SLEPc/TAO and {petsc|slepc|tao}4py are not normal users of PETSc.
To me - it makes perfect sense for these packages to mimick both the
PETSc build modes as closly as possible [both modes]. So if they need
PETSC_ARCH used during PETSc build - then thats fine. Perhaps it
should be named PETSC_ARCH_value_used_at_build_time - or a more
descriptive name to satisfy Barry's concerns.
The whole point of my concerns is that I need to have some sort of
unique-identifier that let me know a SLEPc build match a PETSc
build. For non-prefix builds of PETSc and SLEPc, that is PETSC_ARCH.
For prefix installs, I've somewhat lost my way to make sure PETSc and
SLEPc builds match each other.
Could we devise a way to generate a Makefile variable embeding some
info from the most basic configuration setup, for example a string
with coma-separated key:value pairs, something like,
PETSC_CONF =
platform:linux2,arch:i686,compiler:gnu,language:c,debug:no,integer:32bit,scalar:real,precision:double
and any other important bit I could be missing?
This way, SLEPc's configure could get the value from parsing PETSc
makefiles, and then SLEPc could save that value in its own makefiles.
Then petsc4py/slepc4py could use that info (at build time and runtime)
to have some sort of assurance that libraries from the PETSc build and
the SLEPc build are more or less compatible, and can be used together.
You know, errors should never pass silently :-)
What do you think?
--
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
--
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/20091127/5095cfbc/attachment.html
PETSC_ARCH variable -- PETSC_CONF
I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? Barry -- 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/20091130/bb928fec/attachment.html
PETSC_ARCH variable -- PETSC_CONF
On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? Barry -- 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 -- 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/20091130/b548f1cb/attachment.html
TS: high-order with Galerkin spatial discretization, semi-explicit index-1 DAE
I could not understand the post. We will have to go more slowly. To begin,
I cannot understand why you cannot use TSSetMatrices()
http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-dev/docs/manualpages/TS/TSSetMatrices.html#TSSetMatrices
Thanks,
Matt
On Tue, Mar 17, 2009 at 9:15 PM, Jed Brown jed at 59a2.org wrote:
I have a use for high-order implicit strong stability preserving
integrators and plan to write a TS implementation based on some known
optimal methods (cf. Gottlieb, Ketcheson, Shu 2009). There are two
cases of interest that I don't think TS can currently handle.
Suppose we are using a Galerkin discretization so that the mass matrix
is not the identity, but we still want to use high-order temporal
discretization. In particular, for high-order spatial discretizations,
lumping the mass matrix is usually not acceptable so it would have dense
inverse. In these cases, MatShift is not sufficient [*]. One option is
to allow shifts by an assembled mass matrix, but this is awkward with
JFNK and requires significant storage when the mass matrix is not
lumped.
Perhaps a better option is for function evaluation and Jacobian assembly
to observe the time-step (or a_{kk}*dt for Runge-Kutta methods). This
also works in the more general setting of semi-explicit index-1 DAE,
presented in the form
V u_t = F(u,t)
where F is the spatial discretization and V is typically block diagonal
with mass matrices for differential variables and zero for algebraic
variables. To integrate such systems, the user would provide functions
to evaluate
G(u,u_i,t,dt) = V u - F(dt*u+u_i,t)
(u_i is a known inhomogeneous part) and assemble the
Jacobian/preconditioner G'(u,t,dt). This is sufficient for multistep
and Diagonally Implicit Runge-Kutta (DIRK) methods. For example, in the
case of DIRK, stage k is computed by solving
G(u^k, u_0 + dt \sum_{l=0}^{k-1} a_{kl} u^l, t^k, dt a_{kk}) = 0
for u^k. For singly implicit Runge-Kutta (SIRK, a_{kk} constant)
methods, lagging the preconditioner is perfectly acceptable since the
time-step does not change frequently. For JFNK with non-SIRK methods
and with high-order multistep methods, the preconditioner would often
have to be refactored to accommodate the shift, hence the inability to
effectively lag the preconditioner is an unavoidable weakness. Of
course it is common that assembly is more expensive than PC setup in
which case assembling F' and shifting by the mass matrix is appealing
(assuming that storage for an assembled mass matrix is available).
To summarize, asking the user to provide G,G' has the pros:
+ consistent mass matrices with minimal cost
+ DAE
+ moving meshes
and cons:
- not compatible with current F,F'
- shifts requiring reassembly are more expensive
Asking the user to observe the time-step is at odds with the current
interface where the user only provides F and F'. Are the
performance/flexibility benefits worth it? How about a middle ground
where the application can provide a lumped mass matrix (identity by
default) and either functions F,F' or G,G' (where if G' is provided and
the preconditioning matrix is different from the Jacobian, the
preconditioner would be shifted using the lumped mass matrix)?
I'd love to hear comments or suggestions.
Jed
[*] For my purposes, I don't actually need an assembled consistent mass
matrix because my Jacobian is available via MatShell or MFFD (i.e. since
shifting by the lumped mass matrix still produces a good preconditioner,
the generalization of MatShift would be sufficient). However, some
people use the same matrix for the Jacobian and for preconditioning,
hence a general scheme probably ought to be able to handle this.
--
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/20090318/b8e57f5e/attachment.html
TS: high-order with Galerkin spatial discretization, semi-explicit index-1 DAE
On Wed, Mar 18, 2009 at 5:27 PM, Jed Brown jed at 59a2.org wrote: On Wed 2009-03-18 13:59, Matthew Knepley wrote: I cannot understand why you cannot use TSSetMatrices() TSSetMatrices is only for linear problems and doesn't generalize nicely to nonlinear problems, especially with matrix-free methods. The functionality I'm looking for involves a possibly variable, possibly singular (with huge null space for DAE), possibly nonlinear (as with fully implicit moving mesh schemes) Alhs. With my high-order Galerkin scheme, Alhs can only be available as MatShell (so MatAXPY is hard to implement) because an assembled Alhs would be an order of magnitude denser than the preconditioning matrix associated with the unshifted Jacobian (J=F' if we are solving Alhs(u,t) u_t = F(u,t)). This can all be handled in a way that would work nicely with JFNK and avoid storing Alhs in any form, but I think the user's function evaluation and matrix assembly needs to provide shifted versions (such as 1/dt*Alhs-J where J = F'(u)). The shift is usually a trivial amount of work during function evaluation and matrix assembly. Preconditioners can still be lagged effectively as long as the shift does not change rapidly. Even if the shift does change rapidly, reassembling the preconditioning matrix could still often be avoided by just doing a lumped shift (function evaluation and matrix-free Jacobians can change the shift, using a consistent mass matrix, at zero cost). Is this more clear? Not a whole lot. Needs to go slower, since I think there are a bunch of embedded assumptions, and I worry that the most simple, general interface cannot be seen until they are clarified. I want it spelled out very very explicitly. So, to begin, you are unhappy with A_lhs(t) u_t = F(u,t) where A_lhs is a linear operator. Is this true? For now, I will assume that A_lhs(t) is actually a nonlinear operator O_lhs(u,u_t,t). Then we have O_lhs(u,u_t,t) - F(u,t) = 0 So if we do Backward-Euler, O_lhs(u^n+1,t^n+1) - dt F(u^n+1,t^n+1) - O_lhs(u^n,t^n) = G = 0 so for Newton (O'_lhs - dt F') du = G So are you asking for a nonlinear operator O? After I understand the answers to these, I can start to understand the comments about shifts, etc. that talk about implementing this new model. I just want to clarify the movement away from the original TS model. Matt 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/20090318/a231dffd/attachment.html
TS: high-order with Galerkin spatial discretization, semi-explicit index-1 DAE
Okay, I understand now. You are correct that this formulation should be available. In fact, I think it should be possible to make this the bottom of the hierarchy, with the linear case a specialization, and the identity case a specialization of that (with a MF application). This is a good chance to redesign TS. Next question. How should we do it? We can continue the discussion on email, but that makes it hard to refer back to pieces of code, or suggested interfaces. I think for a collaborative job, we need to augment the email discussion with a Wiki of some type (I was very impressed with Tim Gowers' polymath experiment). Satish, do we have a Wiki, or could we setup one in short order? Thanks, Matt On Thu, Mar 19, 2009 at 5:28 AM, Jed Brown jed at 59a2.org wrote: On Wed 2009-03-18 18:34, Matthew Knepley wrote: Not a whole lot. Needs to go slower, since I think there are a bunch of embedded assumptions, and I worry that the most simple, general interface cannot be seen until they are clarified. I want it spelled out very very explicitly. So, to begin, you are unhappy with A_lhs(t) u_t = F(u,t) where A_lhs is a linear operator. Is this true? Yes, I agree that this would be the natural generalization of the existing design for linear problems. I think it is not a good option for several reasons, most notably that it will often double the required storage and/or double the required computation per time-step when used with matrix-free methods. Also see the end of this message for the case of general index-1 DAE where it is not possible to separate A_lhs from F. For now, I will assume that A_lhs(t) is actually a nonlinear operator O_lhs (u,u_t,t). Then we have O_lhs(u,u_t,t) - F(u,t) = 0 So if we do Backward-Euler, O_lhs(u^n+1,t^n+1) - dt F(u^n+1,t^n+1) - O_lhs(u^n,t^n) = G = 0 so for Newton (O'_lhs - dt F') du = G So are you asking for a nonlinear operator O? Yes, so shifted function evaluation is O = O_lhs - dt F and the shifted Jacobian is O' = O'_lhs - dt F' . My proposal is that there are significant space- and time-savings if the user can supply O and O' for an arbitrary shift dt, instead of O_lhs, O'_lhs, F, F'. For most problems, computing O and O' is essentially the same amount of work as F and F', and computing O_lhs, O'_lhs may require a similar amount of work (in my case) and often requires a similar amount of storage (the preconditioning matrix for O'_lhs often has the same nonzero pattern as F'). The purpose of O_lhs, O'_lhs are only to compute shifts and are never used alone (indeed cannot be used alone for DAE). Use of O, O' generalizes to high-order multistep and multistage implicit methods. After I understand the answers to these, I can start to understand the comments about shifts, etc. that talk about implementing this new model. I just want to clarify the movement away from the original TS model. Yes, of course. My motivation comes from integrating DAE using a moving-mesh scheme where the spatial discretization does not assemble the real Jacobian, only a much sparser (factor 10--100) preconditioning matrix. Evaluating the action of the Jacobian is less expensive than function evaluation only because transcendental functions don't need to be reevaluated, and much of the cost comes from evaluating tensor-product operations at quadrature points. Keeping O_lhs and F separate means that application of O' (this is what is actually needed by the integrator) needs to be applied by applying O'_lhs and F' separately, essentially doubling the cost (this is also the case if O'_lhs is available via MFFD). If O'_lhs and F' are assembled, it doubles the required storage and may double the assembly time. I think the advantages of keeping O_lhs separate is only realized when it is constant and F' is assembled, or when O_lhs is diagonal. CVODE (Sundials) requires that O_lhs is the identity (there is no way to change it) while IDA (the DAE solver) essentially asks the user for the shifted versions. Indeed, for general index-1 DAE G(u_t,u,t)=0, it is not possible to separate O_lhs and F. There is probably no advantage to restricting ourselves to the semi-explicit case. Maybe it's clearer in the context of general index-1 DAE, equations of the form F(u_t, u, t) = 0 . Solution using multistep (e.g. BDF) and multistage (Implicit Runge-Kutta) methods requires solving algebraic systems of the form G(u) = F(known + alpha u, u, t) The required Jacobian is G'(u) = alpha dF/du_t + dF/du . These are analogous to the shifted operators I've been talking about, but apply in more general circumstances. 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
building PETSc on Windows
On Mon, Mar 23, 2009 at 8:23 AM, Lisandro Dalcin dalcinl at gmail.com wrote: The Cygwin way works, but let me say that it is a bit of pain... as a novice in this crapy environment, I've spent a lot of time just to get all the Cygwin stuff properly installed... I'm exploring the possibility of using an alternative, that is, using stock Python for Windows + MinGW + MSYS. MSYS provides a minimal UNIX-like shell and bundles development utilities like make. IMHO, it is a much lighter approach to Cygwin... I believe the alternative is possible... However, I have some issues that have to be addressed, and I would need your help... 1) As I'm using the stock Python for Windows, the select module does not work on pipes.. Then the machinery for executing things in the shell and get stdout and stderr stuff needs to be reeimplemented... Do not worry about this, I can take this. 2) BuildSystem assumes that the shell is '/bin/sh'... I would need it to find sh in the $PATH instead... Where is this assumption? In BuildSystem/config/programs.py we explicitly search for 'sh', so it is available, we just need to use it everywhere. 3) When checking for make, BuildSystem uses 'strings' somewhere.. Again, I need strings to be searched in $PATH. Okay, I fixed this. Matt Can any of you try to fix (2) and (3) ? Anyway, that would be a good change even for Unix-like systems, right? -- 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 -- 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/20090323/8ae99161/attachment.html
building PETSc on Windows
On Mon, Mar 23, 2009 at 11:00 AM, Lisandro Dalcin dalcinl at gmail.com wrote: On Mon, Mar 23, 2009 at 10:57 AM, Satish Balay balay at mcs.anl.gov wrote: The main issue is - win32fe works with cygwin PATHs - not windows paths.. Sorry, I'm do not know what are you talking about ... Is win32fe a compiler wrapper? Note I want to support the stock Python for win + MinGW (outside cygwin) + MSYS (minimal system)... The issue here is supporting the Windows compilers. What you propose would probably work for gcc, but we use win32fe in order to support all the compilers made the MS programming environment. 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/20090323/af35e5cf/attachment.html
building PETSc on Windows
On Mon, Mar 23, 2009 at 11:09 AM, Lisandro Dalcin dalcinl at gmail.com wrote: On Mon, Mar 23, 2009 at 11:48 AM, Matthew Knepley knepley at gmail.com wrote: 2) BuildSystem assumes that the shell is '/bin/sh'... I would need it to find sh in the $PATH instead... Where is this assumption? In BuildSystem/config/programs.py we explicitly search for 'sh', so it is available, we just need to use it everywhere. Check this file: config/PETSc/utilities/petscdir.py See the lines host = config.base.Configure.executeShellCommand(self.shell+' '+configGuess, log = self.framework.log)[0] output = config.base.Configure.executeShellCommand(self.shell+' '+configSub+' '+host, log = self.framework.log)[0] then see that 'self.shell' is naively defined to '/bin/sh' in Script.__init__() in the file below config/BuildSystem/script.py Fixed. I left script the way it is, but fixed the configure stuff. I do not want to entangle config stuff in there. Let me know if this stuff works. Thanks, Matt -- 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 -- 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/20090323/76b72724/attachment.html
MatMult_Scatter woes
On Mon, Mar 30, 2009 at 5:52 AM, Jed Brown jed at 59a2.org wrote: The current implementation of MatMult_Scatter and MatMultTranspose_Scatter do not actually have matrix semantics unless the index sets are permutations. For example, it's generally desirable that MatMult(A,x,y); agrees with VecZeroEntries(y); MatMultAdd(A,x,y,y); Similarly for MatMultTranspose. In addition, MatMultTranspose should actually be the transpose of MatMult. Consider the scatter defined by scatter : x - y isx = [0 0] isy = [0 1] where x has length 1 and y has length 2. This forward scatter is equivalent to a 2x1 matrix A = [1;1] Indeed A*[1] = [1;1] but A'*[1;1] = [2] where as MatMultTranspose_Scatter(A,y=[1;1],x) gives x=[1]. This can be corrected by changing the body of MatMultTranspose_Scatter from ierr = VecScatterBegin(scatter-scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter-scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); to ierr = VecZeroEntries(y);CHKERRQ(ierr); ierr = VecScatterBegin(scatter-scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter-scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); and similarly for MatMult_Scatter. Unfortunately, these modifications roughly double the cost of typical sequential scatters and could be much worse (scattering from a small vector to a very large one). I think that correctness is more important here and users would typically not use MatScatter when this would have significant impact or when INSERT_VALUES semantics are desired. Of course some performance can be recovered by having MatScatter use INSERT_VALUES when the destination index set is a permutation. I would vote for checking for a square matrix, and otherwise use the expensive form. Also, what is the ssh url for the repo? I've tried some variations on ssh://petsc at petsc.cs.iit.edu/petsc/petsc-dev without success. It is ssh://petsc at petsc.cs.iit.edu//hg/petsc/petsc-dev Matt 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/20090330/0a8fcfa6/attachment.html
MatMult_Scatter woes
On Mon, Mar 30, 2009 at 6:13 PM, Barry Smith bsmith at mcs.anl.gov wrote: I don't think square has anything to do with it. It depends on whether all the entries in y[i] are hit or if some are skipped, this depends exactly on the scatter. The first time the mult is called, duplicate x and y temporarility, fill a xdup with all 1s. Do the scatter, locate all entries of ydup that are zero, keep a list of these. destroy xdup, ydup. Now do the MatMult() by zeroing all the entires in the list and then do the scatter, now you have an efficient and correct MatMult. The drawback of course is the setup time, but in fact that cost is only one scatter (MatMult()) so is likely worth it. One could do a similar setup for the transpose? I must misunderstand you. The problem above is that INSERT_VALUES is used, but when two input locations map to the same output location, they should be added. You are right, that square matrices can still have this property. However, I do not see how the above sequence fixes this. I can't see how you would get around an addition. Matt Barry On Mar 30, 2009, at 7:04 PM, Matthew Knepley wrote: On Mon, Mar 30, 2009 at 5:52 AM, Jed Brown jed at 59a2.org wrote: The current implementation of MatMult_Scatter and MatMultTranspose_Scatter do not actually have matrix semantics unless the index sets are permutations. For example, it's generally desirable that MatMult(A,x,y); agrees with VecZeroEntries(y); MatMultAdd(A,x,y,y); Similarly for MatMultTranspose. In addition, MatMultTranspose should actually be the transpose of MatMult. Consider the scatter defined by scatter : x - y isx = [0 0] isy = [0 1] where x has length 1 and y has length 2. This forward scatter is equivalent to a 2x1 matrix A = [1;1] Indeed A*[1] = [1;1] but A'*[1;1] = [2] where as MatMultTranspose_Scatter(A,y=[1;1],x) gives x=[1]. This can be corrected by changing the body of MatMultTranspose_Scatter from ierr = VecScatterBegin(scatter-scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter-scatter,x,y,INSERT_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); to ierr = VecZeroEntries(y);CHKERRQ(ierr); ierr = VecScatterBegin(scatter-scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); ierr = VecScatterEnd(scatter-scatter,x,y,ADD_VALUES,SCATTER_REVERSE);CHKERRQ(ierr); and similarly for MatMult_Scatter. Unfortunately, these modifications roughly double the cost of typical sequential scatters and could be much worse (scattering from a small vector to a very large one). I think that correctness is more important here and users would typically not use MatScatter when this would have significant impact or when INSERT_VALUES semantics are desired. Of course some performance can be recovered by having MatScatter use INSERT_VALUES when the destination index set is a permutation. I would vote for checking for a square matrix, and otherwise use the expensive form. Also, what is the ssh url for the repo? I've tried some variations on ssh://petsc at petsc.cs.iit.edu/petsc/petsc-dev without success. It is ssh://petsc at petsc.cs.iit.edu//hg/petsc/petsc-dev Matt 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 -- 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/20090330/ea22e9e4/attachment.html
GPU related stuff
On Thu, Jul 9, 2009 at 6:15 AM, Farshid Mossaiby mossaiby at yahoo.com wrote: Hi all, Some time ago on this list, there was some discussion about GPU and a GPU version of PETSc. I would like to know if there has been any progress. Also, I need some advice on preconditioners suitable for GPU platforms. We have been progressing, but will not make a release until the fall. PCs which have high flop to memory access ratios look good. No surprise there. May I know what platform/language you are using, e.g. nVidia/CUDA, ATI/ATI Stream SDK or OpenCL? CUDA. Matt Best regards, Farshid Mossaiby -- 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/20090709/1609129e/attachment.html
GPU related stuff
On Thu, Jul 9, 2009 at 7:31 AM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: PCs which have high flop to memory access ratios look good. No surprise there. My concern here is that almost all good preconditioners are multiplicative in the fine-grained kernels or do significant work on coarse levels. Both of these are very bad for putting on a GPU. Switching from SOR or ILU to Jacobi or red-black GS will greatly improve the throughput on a GPU, but is normally much less effective. Since the GPU typically needs thousands of threads to attain high performance, it's really hard to use on all but the finest level. I agree with all these comments. I have no idea how to make those PCs work. I am counting on Barry's genius here. One of the more interesting preconditioners would be 3-level balancing or overlapping DD with very small subdomains (like thousands of subdomains per process). There would then be 1 subregion per process and a global coarse level. This would allow the PC to be additive with chunks of the right block size, while keeping a minimal amount of work on the coarser levels (which are handled by the CPU). (It's really hard to get multigrid to coarsen this rapidly, as in 1M dofs to 10 dofs in 2 levels.) Unfortunately, this sort of scheme is rather problem- and discretization-dependent, as well as rather complex to implement. With regard to targets, my strategy is to implement things that I can prove work well on a GPU. For starters, we have FMM. We have done a complete computational model and can prove that this will scale almost indefinitely. The first paper is out, and the other 2 are almost done. We are also implementing wavelets, since the structure and proofs are very similar to FMM. The strategy is to use FMM/Wavelets for problems they can solve to precondition more complex problems. The prototype is Stokes preconditioning variable viscosity Stokes, which I am working on with Dave May and Dave Yuen. I'll be interested to see what sort of performance you can get for real preconditioners on a GPU. Felipe Cruz has preliminary numbers for FMM: 500 GF on a single 1060C! That is probably 10 times what you can hope to achieve with traditional relaxation (I think). Matt 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/20090709/d32d160d/attachment.html
Python 2.6 and deprecated modules
On Mon, Jul 13, 2009 at 4:56 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On Mon, Jul 13, 2009 at 6:47 PM, Matt Knepleyknepley at gmail.com wrote: I like 1) as well. However someone needs to test the fixes on ancient RH python. No problem, I have custom installs of old Python's starting from 2.3 and up to current SVN trunk (2.7)... Do you remember what version is the ancient RH Python you are talking about? I think 2.3 is alright. It still needs foo(object) and stuff. Matt Matt From the phone On Jul 13, 2009, at 1:15 PM, Lisandro Dalcin dalcinl at gmail.com wrote: Fedora 11 moved to Python 2.6. Now many Python stdlib modules are deprecated (as part of the transition to Python 3.x series). /u/dalcinl/Devel/PETSc/petsc-dev/config/BuildSystem/config/compilers.py:7: DeprecationWarning: the sets module is deprecated import sets /u/dalcinl/Devel/PETSc/petsc-dev/config/PETSc/package.py:7: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 /u/dalcinl/Devel/PETSc/petsc-dev/config/BuildSystem/script.py:101: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import popen2 We could take two approaches to remove these warnings (I bet all you hate warnings as much as me): 1) Reimplement things using the modern API's, perhaps by using conditional code depending on the Python version and/or using import with try/except blocks. In particular, this will require: a) use the builtin 'set' type (available since Python 2.4) b) use the 'hashlib' module (available since Python 2.5) c) moving from using 'peopen2' to 'subprocess' (BTW, available since Python2.4) will likely remove the need to use 'select', which I commented some time ago it is not supported (for pipes) in native Windows Python (yes, some day I'll have some working code with the native Windows Python). 2) Silent these warnings. I do not think these modules will be ever removed from 2.x series, and porting the whole BuildSystem beast to Python 3.0 is not going to be a 10-minutes task anyway. I personally prefer (1) and volunteer to provide the fixes, even if that is more work than (2). I would like to know your opinions before start to work on this. -- 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 -- 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 -- 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/20090713/edf89643/attachment.html
Chat for coding collaboration
I have found chat to be the best way to resolve simple problems when coding, especially questions about parts I did not write. It would be nice if we all had access to the same chat program to facilitate this kind of interaction in our small group. I tend to prefer GChat. Does anyone else have a preference? or really hate chat? 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090720/98f5d28a/attachment.html
Chat for coding collaboration
I use my mail reader for GChat. I think Apple can do that. Matt On Mon, Jul 20, 2009 at 2:53 PM, Barry Smith bsmith at mcs.anl.gov wrote: I want to use may mail reader as my front end Barry It happens to be Mail.app but that is not important On Jul 20, 2009, at 2:41 PM, Andy Ray Terrel wrote: This is what irc is for and why lots of open source codes are on freenode servers. http://freenode.net/ Then you can pick what ever chat front end you want, log things for others to see, and so on. -- Andy On Mon, Jul 20, 2009 at 2:34 PM, Matthew Knepleyknepley at gmail.com wrote: I have found chat to be the best way to resolve simple problems when coding, especially questions about parts I did not write. It would be nice if we all had access to the same chat program to facilitate this kind of interaction in our small group. I tend to prefer GChat. Does anyone else have a preference? or really hate chat? 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 -- 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/20090720/31184f58/attachment.html
Chat for coding collaboration
The steps are simple: 1) Invite partychat2 at gmail.com to chat using the contacts on the left 2) Open a chat with partychat2 3) In the window type '/join petsc' 4) Then we can all talk at once, and it will be saved I think Matt On Mon, Jul 20, 2009 at 4:02 PM, Andy Ray Terrel andy.terrel at gmail.comwrote: I guess by using GChat you really mean use PartyChat ( http://techwalla.googlepages.com/home )? No google doesn't support IMAP or POP with GChat. There are some codes out there that do turn any jabber server into emails but they don't seem very polished ( http://people.happycoders.org/dax/projects/jmc ). I guess since most people are into gchat I shouldn't go on about irc. If you are going to use chat rooms I would also recommend getting to know dpaste ( http://dpaste.com ) which I find invaluable when debugging someone's code over a chat room. -- Andy -- 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/20090720/9ceb5f52/attachment.html
Setting options on matrices obtained from a DM
Actually, this seems like the same problem that Lisandro is having, just with different functions. I propose making data structures do the work for us rather than complicated organization in an imperative program. We could use the same mechanism we use in configure to handle issues of object setup. We have a setup object that takes a) an object to be setup b) a set of functions to be called for setup, and c) any functions which must be called prior to each given function This way we can flexibly add as many functions as necessary, and then they can be topologically sorted and executed. There will be some implementation issues in C, due to severe limitations with calling conventions, but I think these can all be solved. Comments? Matt On Tue, Jul 21, 2009 at 7:47 PM, Jed Brown jed at 59a2.org wrote: Barry Smith wrote: Could you call MatSetFromOptions() twice, once before the DAGetMatrix() call to set the type and then after the DAGetMatrix() to set particular options for what you set? This is okay as long as we don't get more global matrix options (this state appears to be stable). It's a little clumsy to have to call that function twice, and because preallocation comes last in the usual idiom: MatCreate MatSetSizes MatSetFromOptions MatXXXSetPreallocation If the matrix type wants anything (programmatic) to be done before preallocation, we don't have a way to do it with your scheme. That is, although we might have set the type before calling DAGetMatrix(), the type isn't actually set until the sizes are known, so we can't call any MatXXXSetYYY() before calling DAGetMatrix(). At the moment, I can't think of a case were this would be a problem. The same applies to anything that could be set by MatSetFromOptions_XXX, but needs to be done before preallocation. The hypothetical DMGetMatrix /* sets sizes, not preallocation or type */ MatSetOptionsPrefix MatSetFromOptions DMSetMatPreallocation makes it possible to set all the options in MatSetFromOptions, and allows any MatXXXSetYYY to be called before preallocation. I can't think of a case where this is more limiting, but that doesn't mean it doesn't exist. It does mean two DM functions rather than one which is not ideal. We decided along time ago to cluster all the option setting in XXXSetFromOptions() but it does impose some limitations. Too many limitations. Are there other models? Having random XXGetOption() in any old method is dangerous because it is hard to know what and where options are going to be set so I think we are stuck with the XXXSetFromOptions() model. I agree that keeping as much as possible in XXXSetFromOptions is the best alternative. I've seen the mess caused by having too many places in which options are consulted. The PETSc creation model is much nicer to work with than factory objects which enforce more sequencing. 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/20090721/072f81e6/attachment.html
Setting options on matrices obtained from a DM
No comments? Not even This is complete shit!? Matt On Tue, Jul 21, 2009 at 8:56 PM, Matthew Knepley knepley at gmail.com wrote: Actually, this seems like the same problem that Lisandro is having, just with different functions. I propose making data structures do the work for us rather than complicated organization in an imperative program. We could use the same mechanism we use in configure to handle issues of object setup. We have a setup object that takes a) an object to be setup b) a set of functions to be called for setup, and c) any functions which must be called prior to each given function This way we can flexibly add as many functions as necessary, and then they can be topologically sorted and executed. There will be some implementation issues in C, due to severe limitations with calling conventions, but I think these can all be solved. Comments? Matt On Tue, Jul 21, 2009 at 7:47 PM, Jed Brown jed at 59a2.org wrote: Barry Smith wrote: Could you call MatSetFromOptions() twice, once before the DAGetMatrix() call to set the type and then after the DAGetMatrix() to set particular options for what you set? This is okay as long as we don't get more global matrix options (this state appears to be stable). It's a little clumsy to have to call that function twice, and because preallocation comes last in the usual idiom: MatCreate MatSetSizes MatSetFromOptions MatXXXSetPreallocation If the matrix type wants anything (programmatic) to be done before preallocation, we don't have a way to do it with your scheme. That is, although we might have set the type before calling DAGetMatrix(), the type isn't actually set until the sizes are known, so we can't call any MatXXXSetYYY() before calling DAGetMatrix(). At the moment, I can't think of a case were this would be a problem. The same applies to anything that could be set by MatSetFromOptions_XXX, but needs to be done before preallocation. The hypothetical DMGetMatrix /* sets sizes, not preallocation or type */ MatSetOptionsPrefix MatSetFromOptions DMSetMatPreallocation makes it possible to set all the options in MatSetFromOptions, and allows any MatXXXSetYYY to be called before preallocation. I can't think of a case where this is more limiting, but that doesn't mean it doesn't exist. It does mean two DM functions rather than one which is not ideal. We decided along time ago to cluster all the option setting in XXXSetFromOptions() but it does impose some limitations. Too many limitations. Are there other models? Having random XXGetOption() in any old method is dangerous because it is hard to know what and where options are going to be set so I think we are stuck with the XXXSetFromOptions() model. I agree that keeping as much as possible in XXXSetFromOptions is the best alternative. I've seen the mess caused by having too many places in which options are consulted. The PETSc creation model is much nicer to work with than factory objects which enforce more sequencing. 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 -- 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/20090722/0a1e13cc/attachment.html
Setting options on matrices obtained from a DM
On Thu, Jul 23, 2009 at 8:15 AM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: On Wed, Jul 22, 2009 at 3:57 PM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: No comments? Not even This is complete shit!? Heh, it might be overkill and, if I understand you correctly, I think it could be a headache. There is a reasonable amount of code in the various interfaces to ensure some sequencing, but delayed evaluation is tough to reason about. When I call a function, I expect strict evaluation, but if you somehow store that call away until it's dependencies are satisfied, I'm likely to see confusing behavior. They way we resole this in configure is to have an execute function. I think this would be pretty much the behavior people expect. What would the calling sequence look like for getting a Mat from a DM? MatCreate() in any order the setup functions, such as MatSetSizes() MatPreallocate() MatSetType() each one of these calls a private function like MatSetSizes_outoforder() which registers the method and user data for later processing MatSetUp() (which can be called by anyone, executes) Who calls execute? Am I not allowed to call MatSetXXX() after Whoever calls setup. This allows the user to choose to do it, or not, and its the current paradigm for most objects in PETSc. MatExecute()? What about MatGetXXX() before MatExecute()? It will reregister that function, so you would need another SetUp() call, exactly the same interface we have now. MatGet() has exactly the same interface too, namely things might not be available. That object would not have to be seen. You would just have a pc.require(SetSizes, m, n); pc.require(...) pc.setup() Is the Mat/PC/whatever interface or implementation calling this? No, wrappers as I show above. The user interface would not change. The config object would need to take ownership of the various arguments, including those that are not PetscObject (like preallocation arrays). No, the registered call would. The fact that someone has to explicitly call execute makes this solution look a lot like a factory, minus the type-level distinction. With configure, the environment is fixed and once a given set of dependencies are satisfied, an immutable object can be created. With PETSc objects, the user might insert arbitrary imperative code (including queries and setting up one object based on the state of another) during the definition of the environment. I fear that a set properties, then execute model would be frusratingly restrictive. It is what we have now. I do not understand any of your objections. Matt 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/20090723/f7c8c3ff/attachment.html
Setting options on matrices obtained from a DM
On Thu, Jul 23, 2009 at 9:45 AM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: MatExecute()? What about MatGetXXX() before MatExecute()? It will reregister that function, so you would need another SetUp() call, exactly the same interface we have now. But the user wants to call MatGetXXX() and use the result right away (instead of getting a request object or passing a continuation to be executed when the result is available). The whole point of the continuation is to perform a side-effect which is going to cause confusing behavior. Currently they get an error if the result isn't available. With the register attributes, then execute model, the result will almost never be available so everything they might do would go into a continuation. We could probably make this work (even with reasonable syntax) in a language like Haskell, but in an impure strict language I think it will snowball into a mess of side-effecting continuations being called at peculiar times. It would be impossible for me to disagree more strongly. A user cannot get information that is not setup in the current model. I really do not understand your objection, and the Haskell discussion is bizarre. All I am suggestion is that we use a better model for remembering what to do. Barry suggests that individual functions remember data and when to execute it. I am suggesting we use a uniform model for both remembering the data and the dependecies. That is it. Very simple. Matt 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/20090723/844d5fe4/attachment.html
Setting options on matrices obtained from a DM
On Thu, Jul 23, 2009 at 10:21 AM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: It would be impossible for me to disagree more strongly. A user cannot get information that is not setup in the current model. I really do not understand your objection, and the Haskell discussion is bizarre. All I am suggestion is that we use a better model for remembering what to do. If I call MatGetXXX(), I expect to either get a meaningful and usable result, or get an error. As I understand your suggestion, I wouldn't get that unless SetUp had been called. But I wanted to do something with that result which means that I will either get a request object (I keep control of when I do that thing with the result, this will be a PITA) or I give you a continuation for whatever I wanted to do with it There is no way we would be doing conintuations. Why even bring this up? This just complicates the discussion and distracts from the main issues. The answer is incredibly easy and straightforward. Just like MANY functions in PETSc, you will not get the correct answer until things have been initialized. This just sounds like arguing for the sake of argument. Matt (but then I don't know when it will be executed which is confusing because the continuation will have side-effects, and it's a PITA to do continuations in C/C++/etc). In Haskell, it's possible to maintain control of side-effects and have sane syntax for all these continuations, but we don't have (or want to be using) Haskell for this. To be concrete, someone is going to do: TSGetSNES SNESGetKSP KSPGetPC PCGetOperators MatGetVecs /* do something with the matrices and vectors */ If the objects are not sufficiently set up when this is called, the current model will give an error which is easy to understand. With your model, if we haven't called SetUp(), none of these objects will be available, so instead we'll pass a continuation for everything to do with them. In pseudo-Haskell and skipping the obvious sugar, we'd have something like TSGetSNES ts (\snes - SNESGetKSP snes (\ksp - KSPGetPC ksp (\pc - PCGetOperators pc (\(a,p) - MatGetVecs p (\(x,y) - -- do something with a,x,y ) The monad that this runs under would be able to control side-effects. That is, we have a type signature like XXXGetYYY :: x - (y - M a) - M a where the monad M controls the side-effects. Doing this in C would be insane which means that I must be misunderstanding what you want to do. 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/20090723/9a58b9d5/attachment.html
Prefix for DACreate
I will do it, but it will have to wait for weekend after next since I have to go the SIAM CSE. Matt On Sat, Feb 21, 2009 at 2:57 PM, Jed Brown jed at 59a2.org wrote: We solve equations in a high-aspect ratio domain and have both a 2- and 3-dimensional DA which need to be compatible. Due to the nature of the problem, the x-direction of the 3D DA must be local which means that options such as -da_processors_x don't work (they mean different things for each DA, thus forcing an incompatible state). It is currently not possible to set an options prefix on a DA because the usual PETSc creation pattern isn't used. A hack that would fix my problem is to just add a prefix argument to DACreate, but the more elegant solution is a more significant refactoring to DACreate, DASetSizes, DASetOptionsPrefix, DASetFromOptions. 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/20090221/f04ba9c6/attachment.html
USFFT Mat class
This means that you cannot use -mat_type fftw. Probably because no combination of options can currently initialize it correctly. It is fine to leave out USFFT until this is possible. Matt On Wed, Oct 8, 2008 at 2:20 PM, Dmitry Karpeev karpeev at mcs.anl.gov wrote: I'm writing a new Seq matrix class called USFFT that effects the FFT of unevenly-spaced functions. USFFT is roughly, an extension of the SeqFFTW class. While looking at the FFTW Mat class with Satish we noticed that MatCreate_SeqFFTW is not being registered in MatRegisterAll. In light of this, there are two question: 1) Is that a problem? 2) Should I register the constructor for the new class (MatCreate_SeqUSFFT)? Thanks. Dmitry. -- 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
request for comments/advices about mapping PetscCookie - Python Type
That approach sounds fine. I think that initializing the COOKIEs was not liked by some compilers. Ugh. Matt On Fri, Oct 10, 2008 at 1:31 PM, Lisandro Dalcin dalcinl at gmail.com wrote: In petsc4py, I've just implemented support for compose()/query() in my base Object class. However, I wanted to implement query() in such a way that 'dynamic_cast' (in the C++ sense, i.e, downcast) the composed PETSc object and return to Python code an instance of the appropriate Python type. Then, if you compose() a Mat, then query() will return a Mat. I manages all this inside a private python dictionary mapping PetscCookie - Python type. Of course, this required to make sure that ALL PetscXXXInitializePackage() have been called before adding stuff to my dict. All is working fine; moreover, this machinery is also being used in slepc4py and tao4py (yes, I have those...), then after importing slepc4py or tao4py, the dictionary is populated as appropriate. Then, the question are: Do this approach sound good enough? Is it too much hackery? Can I relly in the long future that this approach will always work? BTW, now I have a clear use case for initalizing all the XXX_COOKIE's to 0 in core PETSc. This will really help me to spot package initialization problems. In fact, I had to manage some of those problems in petsc-2.3.2, petsc-2.3.3 and tao-1.9 . PS: The renaming DA_COOKIE - DM_COOKIE does not play well with all this, but I do not care about it right now. -- 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 -- 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
FW: [PETSC #18391] PETSc crash with memory allocation in ILU preconditioning
[mailto:bsmith at mcs.anl.gov] Sent: Tuesday, October 07, 2008 6:15 PM To: Rhew, Jung-hoon Cc: petsc-maint at mcs.anl.gov; Linton, Tom; Cea, Stephen M; Stettler, Mark Subject: Re: [PETSC #18391] PETSc crash with memory allocation in ILU preconditioning During the symbolic phase of ILU(N) there is no way in advance to know how many new nonzeros are needed in the factored version over the original matrix (this is tree for LU too). We handle this by starting with a certain amount of memory and then if that is not enough for for the symbolic factor we double the memory allocated and copy the values over from the old copy of the symbolic factor (what has been computed so far) and then free the old copy. To avoid this memory doubling (which is not super memory efficient) you can use the option -mat_factor_fill or PCFactorSetFill() to set slightly more than the correct value then only a single malloc is needed and you can do larger problems. Of course, the question is what value should I use for fill? There is no formula, if there was we would use it automatically. So the only way I know is to run smaller problems and get a feel for what the ratio should be for your larger problem. Run with -info | grep pc_factor_fill and it will tell you what you should have used Hope this helps, Barry On Oct 7, 2008, at 5:46 PM, Rhew, Jung-hoon wrote: Hi, 1. I ran it with 64-bit machine with 32GB physical memory but it still crashed. At the crash, the peak memory was 17GB so there were plenty of memory left. This is why I don't think the simulation needed full 32GB + swap space more than 64GB. 2. The problem size is too big for direct solver as it can easily go beyond 32GB. Actually, we use MUMPS for smaller problems. 3. ILUN is the most robust preconditioner we found for our production simulation so we want to stick to it. I think I'll send a test case that reproduces the problem. -Original Message- From: knepley at gmail.com [mailto:knepley at gmail.com] On Behalf Of Matthew Knepley Sent: Tuesday, October 07, 2008 2:21 PM To: Rhew, Jung-hoon Cc: PETSC Maintenance Subject: Re: [PETSC #18391] PETSc crash with memory allocation in ILU preconditioning Its not hard for ILU(k) to run out of the 32-bit limit for large matrices. I would recommend 1) Using a 64-bit machine with more memory 2) Trying a sparse direct solver like MUMPS 3) Trying another preconditioner, which is of course problem dependent Thanks, Matt On Tue, Oct 7, 2008 at 4:03 PM, Rhew, Jung-hoon jung-hoon.rhew at intel.com wrote: Dear PETSc team, We use PETSc as a linear solver library in our tool and in some test cases using ILU(N) preconditioner, we have problems with memory. I'm not sending our matrix at this time since it is huge but if you think it is needed, I'll send it to you. Thanks for your help in advance. Log file is attached. OS: suse 64bit sles9 2.6.5-7.276.PTF.196309.1-smp #1 SMP Mon Jul 24 10:45:31 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux PETSc ver: petsc-2.3.2-p10 MPI implementation: Intel MPI based on MPICH2 and MVAPICH2 Compiler: GCC 4.2.2 Probable PETSc component: n/a Problem Description Solver setting: BCGSL (L=2) and ILU(N=2) -ksp_rtol=1e-14 -ksp_type=bcgsl -ksp_bcgsl_ell=2 -pc_factor_levels=2 -pc_factor_reuseordering -pc_factor_zeropivot=0.0 -pc_type=ilu -pc_factor_fill=2 -pc_factor_mat_ordering_type=rcm malloc crash: sparse matrix size ~ 500K by 500K with NNZ ~ 0.002% (full error message is attached.) In debugger, symbolic ILU requires memory beyond the max int. At line 1089 In aijfact.c, len becomes -2147483648 as (bi[n])*sizeof(PetscScalar) max int. len = (bi[n])*sizeof(PetscScalar); Then, it causes the following malloc error in subsequent function calls (the call stack is also in the attached error message). [0]PETSC ERROR: - Error Message [0]PETSC ERROR: Out of memory. This could be due to allocating [0]PETSC ERROR: too large an object or bleeding by not properly [0]PETSC ERROR: destroying unneeded objects. [0]PETSC ERROR: Memory allocated -2147483648 Memory used by process -2147483648 [0]PETSC ERROR: Try running with -malloc_dump or -malloc_log for info. [0]PETSC ERROR: Memory requested 18446744071912865792! [0]PETSC ERROR: [0]PETSC ERROR: Petsc Release Version 2.3.2, Patch 10, Wed Mar 28 19:13:22 CDT 2007 HG revision: d7298c71db7f5e767f359ae35d33cab3bed44428 Possibly relevant symptom: iterative solver with ILU(N) consumes more memory than direct solver as N gets larger (5) although the matrix is not big enough to cause malloc crash like the above. -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments
Independently configuring down up smoothers in PCMG
On Mon, Oct 20, 2008 at 4:18 PM, Barry Smith bsmith at mcs.anl.gov wrote: Sorry I haven't responded to this fully. I hate the idea of a hack that is just for this case and a special flag you got to set or pass in. For the _1_, _2_ etc I did the following. If the string in the code has _%d_ (for example _1_) it first checks for an exact match in the list of set options. If it does not find an exact match it removes the _%d_ and tries again for an exact match. This seems to work pretty well and could be used in many places in the code, not just in the PCMG stuff. I am not sure I like this. It does not fit with my idea of namespaces, but I do like something very similar (maybe even identical, I can't tell yet). What if we let an object have multiple prefixes, and we have an order for checking. The way we could have -pc_mg_1_ksp_max_its 2 -pc_mg_1_up_ksp_max_its 3 The second would override the first for the up smoother. Is this identical to what you were proposing? Matt It would be nice to use some similar technique the case below. Possibilities 1) use _CAPS_ first exactly and then removing the _CAPS_ 2) make the part with special charactors _string_, first look with _string_ then try without _string_ (the are just my example charactors, could use | or whatever. What do people think about this? Barry Note that currently we always use small letters in the option names. We could continue to have the options database have small letters and use _tolower(CAPS)_ as the first test. I'm inclinded to do 1). With multiple _XXX_ _4_ in an option we'll have to be careful to properly check all possibilities in some consistent order. On Oct 8, 2008, at 10:14 PM, Dave May wrote: Howdy, Should there be a mechanism to independently configure the down and up smoothers for PCMG from the command line? From the looks of things, it seems that on a given level, one is only able to set the smoothing sweeps to be different via -pc_mg_smoothup 3 -pc_mg_smoothdown 2 Since both the down and up smoothers (KSP's) have the prefix set to be mg_levels_X, it would seem that I cannot differentiate between the up ksp at level X from the down ksp at level X via any command line arguments. It would be pain to ALWAYS have to configure both the up and down smoothers independently. But to enable the down and up smoothers to be configured independently (on those odd occasions you want to do it) , could we do something like; set a flag via -pc_mg_smoothers_different which would include in the smoothers prefix, the words up or down? Then on the command line we could do something like -mg_levels_1_up_ksp_type XXX -mg_levels_1_down_ksp_type YYY Cheers, Dave -- 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
Independently configuring down up smoothers in PCMG
On Mon, Oct 20, 2008 at 5:18 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, You idea is more general than mine, and (I think) encompasses what you could do with mine. We must keep in mind that prefixes can be append/prepended to other prefixes repeatedly. To manage this with your approach we might likely need to turn a prefix into a first class object and provide all the infrastructure to manage them. Yuck, if we can help it. Of course, with my approach and several _2_ and _CAP_ in a string the searches get more complicated also, there is no free lunch. But I like the simplicity of keeping the prefix a simple string. We could avoid a prefix object if we, for example, divided the possibilities with a |, for example my mg_levels_1_ prefix would be mg_levels_1_|mg_levels Note each part of an combined prefix would need to be separated by something like so one knows where the | applies. You write we let an object have multiple prefixes, this is actually what my suggestion does also, but with very limited possible multiples (which I kind of like, I hate to think -you_bad_option_pc_type and -a_totally_different_pc_type mean the same thing.) Okay, I always like the idea of limiting domains for simplicity. How about treating the prefix as a simple string, subject to prepending and appending, but change the meaning of match. Now the prefix is interpreted as a regular expression, and a match means an RE match. We can find a small library to do just this, and I think it is much more understandable than ad hoc rules from us. Matt Barry On Oct 20, 2008, at 4:56 PM, Matthew Knepley wrote: On Mon, Oct 20, 2008 at 4:18 PM, Barry Smith bsmith at mcs.anl.gov wrote: Sorry I haven't responded to this fully. I hate the idea of a hack that is just for this case and a special flag you got to set or pass in. For the _1_, _2_ etc I did the following. If the string in the code has _%d_ (for example _1_) it first checks for an exact match in the list of set options. If it does not find an exact match it removes the _%d_ and tries again for an exact match. This seems to work pretty well and could be used in many places in the code, not just in the PCMG stuff. I am not sure I like this. It does not fit with my idea of namespaces, but I do like something very similar (maybe even identical, I can't tell yet). What if we let an object have multiple prefixes, and we have an order for checking. The way we could have -pc_mg_1_ksp_max_its 2 -pc_mg_1_up_ksp_max_its 3 The second would override the first for the up smoother. Is this identical to what you were proposing? Matt It would be nice to use some similar technique the case below. Possibilities 1) use _CAPS_ first exactly and then removing the _CAPS_ 2) make the part with special charactors _string_, first look with _string_ then try without _string_ (the are just my example charactors, could use | or whatever. What do people think about this? Barry Note that currently we always use small letters in the option names. We could continue to have the options database have small letters and use _tolower(CAPS)_ as the first test. I'm inclinded to do 1). With multiple _XXX_ _4_ in an option we'll have to be careful to properly check all possibilities in some consistent order. On Oct 8, 2008, at 10:14 PM, Dave May wrote: Howdy, Should there be a mechanism to independently configure the down and up smoothers for PCMG from the command line? From the looks of things, it seems that on a given level, one is only able to set the smoothing sweeps to be different via -pc_mg_smoothup 3 -pc_mg_smoothdown 2 Since both the down and up smoothers (KSP's) have the prefix set to be mg_levels_X, it would seem that I cannot differentiate between the up ksp at level X from the down ksp at level X via any command line arguments. It would be pain to ALWAYS have to configure both the up and down smoothers independently. But to enable the down and up smoothers to be configured independently (on those odd occasions you want to do it) , could we do something like; set a flag via -pc_mg_smoothers_different which would include in the smoothers prefix, the words up or down? Then on the command line we could do something like -mg_levels_1_up_ksp_type XXX -mg_levels_1_down_ksp_type YYY Cheers, Dave -- 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 -- 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
error in handling download external packages
I have a problem with hiding the package includes. If I tell PETSc to install ParMetis, I think I should be able to use ParMetis however I want. I do not just want to use it through the PETSc interface. I have done this numerous times. I think most users think this way as well. What is the motivation for hiding the includes? Thanks, Matt On Wed, Oct 22, 2008 at 11:18 AM, Satish Balay balay at mcs.anl.gov wrote: On Wed, 22 Oct 2008, Barry Smith wrote: I wasn't saying we had to solve this problem, but I do think it is a problem. A users code could easily pick up the wrong include for something since we now have hundreds in our arch/include location. I guess part of the problem is namespace issue [This would be the primary reason for picking up the wrong include]. In that sense include/packagename/pkginc.h might be a valid thing. But the package has to support this internally [as in 'make install' provides include/pkgname/pkginclude'. And the recommended usage from user code would be: #inlcude package/pkginc.h [this model is not in sync with curent PETSc model of supporing both install in PETSC_DIR-src and 'make install with prefix']. It might be better to identify the namespace conflicts and ask the packages to fix the names.. The other kind of conflict is: user installs superlu separately - and then tries to use PETSc installed with --download-superlu. These 2 versions of superlu will conflict with each other.. The fix in this case is to not use the duplicate install of superlu anyway... 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
Check it out
http://en.wikipedia.org/wiki/Portable%2C_Extensible_Toolkit_for_Scientific_Computation 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
changes for next PETSc release
On Sun, Mar 16, 2008 at 7:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: There are two significant changes I'd like to see before the next PETSc release: 1) remove the overly complicated (from a user perspective) matrix subclassing for the various external matrix solver packages and replace with MatSolverSetType() - mat_solver_type type that simply flips the various factorization/solver functions with those requested and This seems not too hard. Just a layer on top to run the code a user must run now. 2) properly name-space PETSc by putting a Petsc in front of all PETSc objects, function names etc (this will require changing a few names also to keep them below the 32 character limit). This will be very painful change for some users who are not comfortable ever changing code, hence I hesitate to do it, but it is the right thing to do and should have been done originally. I guess I still do not see the need for this. NIMROD is a not a sufficient driver in my mind. If we really want namespaces, use a real language that has namespaces. There are plenty. If we are still using C, I say we stick with the old division. The imposition of this much pain on the overwhelming majority of users seems unjustified. Namespaces issues can be trivially fixed in say C++, which we should do. Matt Maybe we can do a release in around a couple of months, it would be 2.4 Barry -- 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
changes for next PETSc release
On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith bsmith at mcs.anl.gov wrote: 2) properly name-space PETSc by putting a Petsc in front of all PETSc objects, function names etc (this will require changing a few names also to keep them below the 32 character limit). This will be very painful change for some users who are not comfortable ever changing code, hence I hesitate to do it, but it is the right thing to do and should have been done originally. I guess I still do not see the need for this. NIMROD is a not a sufficient driver in my mind. You are an elitist who thinks that important ideas can only come from important/smart people. This I disagree strongly with, one should look everywhere, even at the local dump, for good ideas. NIMROD is not the driver, it is merely the spark. I will be more specific. I think there is no good idea connected with this requirement of NIMROD. In fact, I think it is a very very bad idea. They are using a language with namespaces (F90) but they ignore them. Then they wonder why uses a product from a language without namespaces (C) they have a problem. The wrong strategy is to do something complicated in the deficient language. The right thing to do is something easy in the language with support. Why can't we just do an F90 binding with namespaces? That would fix NIMROD and not disrupt the community who has not complained (and who is much much bigger). If we really want namespaces, use a real language that has namespaces. There are plenty. If we are still using C, I say we stick with the old division. The imposition of this much pain on the overwhelming majority of users seems unjustified. You seem to be saying we should stick with a bad decision I made many years ago, just because it is painful to change. When did you suddenly become conservative? No, I am saying that the fix is crap because it is complicated, entails enormous changes to the code, and is ugly. I think the correct fix is to use nice mechanisms in languages that support them, like C++. I am completely against forcing weak language mechanisms to do complicated things, which is why I hate all those template tricks. Also, we should look at history. We have made mistakes in the past when changing the interface (KSPSolve() with no arguments) which were painful. I want to make sure what we choose to do is as simple and non-painful as possible. 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
changes for next PETSc release
On Mon, Mar 17, 2008 at 1:06 PM, Barry Smith bsmith at mcs.anl.gov wrote: Fortran90 has namespaces?? Not in the way I was thinking. Damn F90. Anyway, it looks like you can selectively use interface modules, so we might be able to get away with redundant names by just not using them together. I jsut really hate the idea of putting PETSc in front of every word in the package. It is really the ugliest thing I can imagine and will make programming that much more of a slog. Matt On Mar 17, 2008, at 12:59 PM, Matthew Knepley wrote: On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith bsmith at mcs.anl.gov wrote: 2) properly name-space PETSc by putting a Petsc in front of all PETSc objects, function names etc (this will require changing a few names also to keep them below the 32 character limit). This will be very painful change for some users who are not comfortable ever changing code, hence I hesitate to do it, but it is the right thing to do and should have been done originally. I guess I still do not see the need for this. NIMROD is a not a sufficient driver in my mind. You are an elitist who thinks that important ideas can only come from important/smart people. This I disagree strongly with, one should look everywhere, even at the local dump, for good ideas. NIMROD is not the driver, it is merely the spark. I will be more specific. I think there is no good idea connected with this requirement of NIMROD. In fact, I think it is a very very bad idea. They are using a language with namespaces (F90) but they ignore them. Then they wonder why uses a product from a language without namespaces (C) they have a problem. The wrong strategy is to do something complicated in the deficient language. The right thing to do is something easy in the language with support. Why can't we just do an F90 binding with namespaces? That would fix NIMROD and not disrupt the community who has not complained (and who is much much bigger). If we really want namespaces, use a real language that has namespaces. There are plenty. If we are still using C, I say we stick with the old division. The imposition of this much pain on the overwhelming majority of users seems unjustified. You seem to be saying we should stick with a bad decision I made many years ago, just because it is painful to change. When did you suddenly become conservative? No, I am saying that the fix is crap because it is complicated, entails enormous changes to the code, and is ugly. I think the correct fix is to use nice mechanisms in languages that support them, like C++. I am completely against forcing weak language mechanisms to do complicated things, which is why I hate all those template tricks. Also, we should look at history. We have made mistakes in the past when changing the interface (KSPSolve() with no arguments) which were painful. I want to make sure what we choose to do is as simple and non-painful as possible. 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 -- 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
petscvariables: hardwired build dir instead of install dir
If someone explains to me in words what that sed crap is doing, I will
rewrite it in python.
Thanks,
Matt
On Mon, Mar 24, 2008 at 10:57 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
Barry, things are still broken. I think that at some point we have to
review the 'install:' target more carefully.
First, the 'sed' command i being called in a wrong way.
Second, ALL files under $PETSC_ARCH/conf are being copied, I'm not
sure if all them are needed (logs, RDict.db, configure.py, etc) when
you 'install' PETSc in a central, system location.
Finally, 'sed' trickery is done under all files under 'conf/' and that
can be dangerous.
I attach a hg diff fixing some of that issues. But I still believe
that this have to be more carefully reviewed. Unfortunately, I will
not be able to do that myself for, let say, three month from now.
By using the patch in the attached file, I was able to install PETSc
and next build petsc4py. However, this does not necesarily means that
things are all OK. I already do some trickery in the build system of
petsc4py in order to 'fix' the problems with the stuff in PETSc
makefiles since version 2.3.2 until latest petsc-dev.
Regards,
On 3/22/08, Barry Smith bsmith at mcs.anl.gov wrote:
Lisandro
The rule was a total mess; I think I have fixed it now, please try
again
and let me know how it goes.
Thanks for reporting the problem,
Barry
On Mar 22, 2008, at 1:18 PM, Lisandro Dalcin wrote:
OK, it seems my stderr were being sent I do not know were... I get the
following (BTW, I was not aware of the 'sed' trick, but I was not
seeing the error)
[root at trantor petsc-dev]# make install
Installing PETSc at /usr/local/petsc/dev/linux-gnu
sed: can't read s?${PETSC_DIR}?TMP_INSTALL_DIR?g: No such file or
directory
sed: can't read s?TMP_INSTALL_DIR?/usr/local/petsc/dev/linux-gnu?g: No
such file or directory
sed: can't read s?/${PETSC_ARCH}??g: No such file or directory
making shared libraries in /usr/local/petsc/dev/linux-gnu//lib
building libpetsc.so
building libpetscvec.so
building libpetscmat.so
building libpetscdm.so
building libpetscksp.so
building libpetscsnes.so
building libpetscts.so
building libpetsccontrib.so
sh/bash: PETSC_DIR=/usr/local/petsc/dev/linux-gnu; export PETSC_DIR
sh/bash: unset PETSC_ARCH
csh/tcsh: setenv PETSC_DIR /usr/local/petsc/dev/linux-gnu
csh/tcsh: unsetenv PETSC_ARCH
Then do make test to verify correct install
And then the 'petscvariables' still have the build dir in many places.
So the 'sed' command is not working for me. I do not know way, I've
never had the time to learn regexps :-(.
BTW, I'm on a Fedora 6 box.
On 3/22/08, Barry Smith bsmith at mcs.anl.gov wrote:
Ok, I think I understand your concern,
On Mar 22, 2008, at 9:00 AM, Lisandro Dalcin wrote:
On 3/22/08, Barry Smith bsmith at mcs.anl.gov wrote:
Do you mean that it lists, for example,
SUPERLU_DIST_LIB = -Wl,-rpath,/Users/bsmith/Src/petsc-dev/arch-icc-
superlu_dist/lib -L/Users/bsmith/Src/petsc-dev/arch-icc-
superlu_dist/
lib -lsuperlu_dist_2.2
instead of
SUPERLU_DIST_LIB = -Wl,-rpath,$PETSC_DIR/arch-icc-superlu_dist/
lib -L
$PETSC_DIR/arch-icc-superlu_dist/lib -lsuperlu_dist_2.2
exactly that, as an example, I've just built petsc-dev, passing as
prefix the following '--prefix=/usr/local/petsc/2.3.3/linux-
gnu' (yes,
I still want to have multiconfig installations of petsc in a central
location, so I add the PETSC_ARCH to the prefix)
But the 'petscvariables' file stills says, for example
ML_INCLUDE = -I. -I/usr/local/mpich2/1.0.6/include
-I/usr/local/mpich2/1.0.6/include
-I/repos/hg/petsc/petsc-dev/linux-gnu/include
This is because the place we want ML to install itself has be
passed in as the true path, it cannot be sent as a symbolic PETSC_DIR
since configure of the subpackage doesn't know PETSC_DIR
The last include dir is the directory were I've built PETSc. I would
love to see that include as -I${PETSC_DIR}/${PETSC_ARCH}/include.
And
now, if external packages got installed in $PETSC_DIR/$PETSC_ARCH,
we
perhaps could just put nothing, as that location is always taken
into
accout for PETSc itself.
The real problem: if I remove the build dir, the 'petscvariables'
point to locations that no longer exists, This is dangerous. I
already
had trouble in the past with the old 'bmake' based system. Is
there a
chance to 'fix' this, or I'm missing something?
make intall: see the rule in makefile is suppose to replace all
uses of the
petsc-dir
petscvariables: hardwired build dir instead of install dir
On Mon, Mar 24, 2008 at 9:50 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:57 AM, Lisandro Dalcin wrote: Barry, things are still broken. I think that at some point we have to review the 'install:' target more carefully. First, the 'sed' command i being called in a wrong way. This is not true; the sed is being called correctly. The problem is that -i is not a standard sed option and different systems gnu and freebsd treat it differently. freebsd requires a space between the -i and the suffix; gnu has no space; gnu also allows the use of -i to indicate no backup while freebsd expects -i Your patch works on POS gnu systems, but is broken on far superior Apple MacOS X systems! :-) Matt you need to add a config/configure.py test to detect the type of sed -i it is. I totally disagree. We should ditch all this crap, and just write nice, PORTABLE Python code. I will do it. I just need someone to explain what this sed is doing. 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
petscvariables: hardwired build dir instead of install dir
On Mon, Mar 24, 2008 at 10:14 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, The sed is so trivial it is silly to even think about replacing it with python! I did not realize until after reading Lisandro's email What does that have to do with anything? If its so trivial, then it won't take any time at all. This is at least the third time I have had to fool with this sed stuff (I already reported that sed bug two months ago). I do not want to do it again. Is there any justification, except inertia, for keeping that in sed? Matt that the sed -i option behaved differently on different systems. Barry On Mar 24, 2008, at 10:07 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 9:50 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:57 AM, Lisandro Dalcin wrote: Barry, things are still broken. I think that at some point we have to review the 'install:' target more carefully. First, the 'sed' command i being called in a wrong way. This is not true; the sed is being called correctly. The problem is that -i is not a standard sed option and different systems gnu and freebsd treat it differently. freebsd requires a space between the -i and the suffix; gnu has no space; gnu also allows the use of -i to indicate no backup while freebsd expects -i Your patch works on POS gnu systems, but is broken on far superior Apple MacOS X systems! :-) Matt you need to add a config/configure.py test to detect the type of sed -i it is. I totally disagree. We should ditch all this crap, and just write nice, PORTABLE Python code. I will do it. I just need someone to explain what this sed is doing. 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 -- 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
petscvariables: hardwired build dir instead of install dir
On Mon, Mar 24, 2008 at 10:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:25 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 10:14 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, The sed is so trivial it is silly to even think about replacing it with python! I did not realize until after reading Lisandro's email What does that have to do with anything? If its so trivial, then it won't take any time at all. This is at least the third time I have had to fool with this sed stuff (I already reported that sed bug two months ago). I do not want to do it again. Is there any justification, except inertia, for keeping that in sed? Not having hundreds of dinky little python scripts lying around that do the same thing as Unix utilities is a good reason. If you write the entire install: rule in python that would be great, then you could start on some of the other rules in conf/rules I am only objecting to replacing Unix one-liners with python one liners. Fine, but you just asked for a lot more Python then 1 line to check which form of the -i flag is on the machine. Matt Barry Matt that the sed -i option behaved differently on different systems. Barry On Mar 24, 2008, at 10:07 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 9:50 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:57 AM, Lisandro Dalcin wrote: Barry, things are still broken. I think that at some point we have to review the 'install:' target more carefully. First, the 'sed' command i being called in a wrong way. This is not true; the sed is being called correctly. The problem is that -i is not a standard sed option and different systems gnu and freebsd treat it differently. freebsd requires a space between the -i and the suffix; gnu has no space; gnu also allows the use of -i to indicate no backup while freebsd expects -i Your patch works on POS gnu systems, but is broken on far superior Apple MacOS X systems! :-) Matt you need to add a config/configure.py test to detect the type of sed -i it is. I totally disagree. We should ditch all this crap, and just write nice, PORTABLE Python code. I will do it. I just need someone to explain what this sed is doing. 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 -- 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 -- 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
petscvariables: hardwired build dir instead of install dir
On Mon, Mar 24, 2008 at 10:53 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:42 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 10:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:25 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 10:14 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, The sed is so trivial it is silly to even think about replacing it with python! I did not realize until after reading Lisandro's email What does that have to do with anything? If its so trivial, then it won't take any time at all. This is at least the third time I have had to fool with this sed stuff (I already reported that sed bug two months ago). I do not want to do it again. Is there any justification, except inertia, for keeping that in sed? Not having hundreds of dinky little python scripts lying around that do the same thing as Unix utilities is a good reason. If you write the entire install: rule in python that would be great, then you could start on some of the other rules in conf/rules I am only objecting to replacing Unix one-liners with python one liners. Fine, but you just asked for a lot more Python then 1 line to check which form of the -i flag is on the machine. Yes, but that is the autoconf model! You wanted the autoconf model, not me! You first tried it with autoconf, not possible, so you wrote a better than autoconf in python. I never asked anyone to make a conf system, I was perfectly happy requiring people to write the correct flags directly into petscconf :-). What bothers me about one-line python scripts to fix Unix weirdness is now you have two models (some things you fix by running config/configure.py and figuring things out and some things you fix by replacing Unix with python). One thing you should know about me is I HATE HATE HATE HATE using two models for doing something at the same time (this is why I hate Mathematica and PERL, they each support about 20 different programming models that can be used together). So now we have reached the root if the issue; in my mind if you introduce a new model approach to solving some problem you toss the old, you don't use them both together! I am all for consistency. However I have a different interpretation of what constitutes the model. I thought the model was 1) Test a set of tools, e.g. compilers, make, ... 2) Customize the use of each based upon our tests 3) Use the set of tools required for each build task I think I am proposing a decision for 3), namely replacing one tool with another. We already do this, for instance when we link with a linker or a compiler. I think we should eliminate all uses of sed with python. Notice that this is not wasted work, as it will survive when eventually everything is replaced by Python. Matt Barry Matt Barry Matt that the sed -i option behaved differently on different systems. Barry On Mar 24, 2008, at 10:07 PM, Matthew Knepley wrote: On Mon, Mar 24, 2008 at 9:50 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Mar 24, 2008, at 10:57 AM, Lisandro Dalcin wrote: Barry, things are still broken. I think that at some point we have to review the 'install:' target more carefully. First, the 'sed' command i being called in a wrong way. This is not true; the sed is being called correctly. The problem is that -i is not a standard sed option and different systems gnu and freebsd treat it differently. freebsd requires a space between the -i and the suffix; gnu has no space; gnu also allows the use of -i to indicate no backup while freebsd expects -i Your patch works on POS gnu systems, but is broken on far superior Apple MacOS X systems! :-) Matt you need to add a config/configure.py test to detect the type of sed -i it is. I totally disagree. We should ditch all this crap, and just write nice, PORTABLE Python code. I will do it. I just need someone to explain what this sed is doing. 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 -- 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 -- 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 -- What most experimenters take for granted before they begin their experiments is infinitely more interesting
This build is so broken
I have spent the last hour trying to get my PETSc to work. This sucks. 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
This build is so broken
I pushed fixes for all this crap. Matt On Mon, Mar 31, 2008 at 9:46 AM, Matthew Knepley knepley at gmail.com wrote: I have spent the last hour trying to get my PETSc to work. This sucks. 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 -- 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
This build is so broken
On Mon, Mar 31, 2008 at 10:12 AM, Lisandro Dalcin dalcinl at gmail.com wrote: Which part? The 'configure' one, or the 'make' one? Anyone who builds needs to pull BuildSystem and reconfigure, and then a bunch of the make was broken. It is fixed now. Matt On 3/31/08, Matthew Knepley knepley at gmail.com wrote: I have spent the last hour trying to get my PETSc to work. This sucks. 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 -- 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 -- 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
config/configure.py - configure?
On Thu, Jul 17, 2008 at 4:14 PM, Barry Smith bsmith at mcs.anl.gov wrote: On Jul 17, 2008, at 3:58 PM, Boyana Norris wrote: Speaking of configure and user experiences, I just noticed that PETSc defines top_builddir (in petscconf), which conflicts with automake-generated makefiles, making it impossible in some cases to include PETSc's petsconf file into Makefile.am (as far as I know that's the only thing that causes problems). I hate automake in general, but sometimes you are stuck with it and it's very nice to be able to include PETSc make snippets even in automake files and avoid a lot of pain. Anyway, since this is in a file that gets copied to the install location, I think in general it would be best to avoid defining build tree-related variables (especially those that conflict with auto-generated ones from other tools). Thoughts? I think this was originally in there when Matt was mucking around with libtool (the gnu one, not the Mac one). I don't think it is used and should be removed. Once Matt confirms this, we will rip it out. Yep, its a relic. Rip it out. Matt Barry Boyana Satish Balay wrote: On Thu, 17 Jul 2008, Satish Balay wrote: If we could support the same way that this is done with autoconf packages that would improve a users experience with PETSc. I guess we don't prevent the usage from shell scripts. We just promote the alternative usage of adding configure options in a python script. And we generate $PETSC_ARCH/config/configure.py - which can be rerun by the user. Alternative would be to generate this file in a shell-script notation.. Satish -- Boyana Norris, Computer Scientist| Email: norris at mcs.anl.gov Argonne National Laboratory | Phone: +1 (630) 252 7908 http://www.mcs.anl.gov/~norris/ | Fax: +1 (630) 252 5986 -- 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
Repository
I cannot ping petsc.cs.iit.edu. I have a tutorial scheduled for 8:30am and was planning for everyone to pull and build. 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
problem with PetscSynchronizedFPrintf (fwd)
I made this change because synchronized printing was cutting off my stuff. Now the queue is dynamically allocated so it can accomodate any size string. I tried ex7 and it runs fine for me, even under valgrind. Shi, can you reproduce this with a Sieve example? Matt On Mon, Jul 21, 2008 at 2:37 PM, Satish Balay balay at mcs.anl.gov wrote: Looks like this could be related to changeset 9e3fbe04a926 -- mprint.h -- - charstring[QUEUESTRINGSIZE]; + char *string; So now strings needs to use malloc()/free()? Matt - you can reproduce this issue with dm/ao/examples/tests/ex7.c Satish On Mon, 21 Jul 2008, Satish Balay wrote: -- Forwarded message -- Date: Sun, 20 Jul 2008 22:39:13 -0700 (PDT) From: Shi Jin jinzishuai at yahoo.com Subject: problem with PetscSynchronizedFPrintf To: petsc-dev at mcs.anl.gov Hi, I recently updated my petsc-dev and found my previously working code is having trouble running in parallel. I've narrowed it down to the calls to PetscSynchronizedFPrintf. Even if I don't have those, I will have errors at the end of my MPI runs like: [1]PETSC ERROR: PetscMemzero() line 189 in src/sys/utils/memc.c [1]PETSC ERROR: PetscViewerASCIISynchronizedPrintf() line 859 in src/sys/viewer/impls/ascii/filev.c [1]PETSC ERROR: PetscMemoryShowUsage() line 367 in src/sys/memory/mtr.c [1]PETSC ERROR: PetscFinalize() line 675 in src/sys/objects/pinit.c [1]PETSC ERROR: completeSection() line 163 in main.cxx [0]0:Return code = 0, signaled with Interrupt [0]1:Return code = 85 Since the same code was running fine before the update. I am wondering if it is something recently introduced. Thanks a lot. -- Shi Jin, PhD -- 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
problem with PetscSynchronizedFPrintf (fwd)
I will check all the occurences of SynchronizedPrintf() in the source. Matt On Mon, Jul 21, 2008 at 3:03 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, You have to be careful here. You use PetscMalloc() here, are you positive this routine will never be called BEFORE PetscMalloc() is setup for (sometime in PetscInitialize), or after PetscMalloc() is taken down (somewhere in PetscFinalize())? Is there someway you can make sure that it is safe? In a few places on setup I have to use a raw malloc instead of PetscMalloc(), I don't want you to have to do that here. I'm not saying to change back the code, just to be careful and check it. Barry On Jul 21, 2008, at 2:47 PM, Matthew Knepley wrote: I made this change because synchronized printing was cutting off my stuff. Now the queue is dynamically allocated so it can accomodate any size string. I tried ex7 and it runs fine for me, even under valgrind. Shi, can you reproduce this with a Sieve example? Matt On Mon, Jul 21, 2008 at 2:37 PM, Satish Balay balay at mcs.anl.gov wrote: Looks like this could be related to changeset 9e3fbe04a926 -- mprint.h -- - charstring[QUEUESTRINGSIZE]; + char *string; So now strings needs to use malloc()/free()? Matt - you can reproduce this issue with dm/ao/examples/tests/ex7.c Satish On Mon, 21 Jul 2008, Satish Balay wrote: -- Forwarded message -- Date: Sun, 20 Jul 2008 22:39:13 -0700 (PDT) From: Shi Jin jinzishuai at yahoo.com Subject: problem with PetscSynchronizedFPrintf To: petsc-dev at mcs.anl.gov Hi, I recently updated my petsc-dev and found my previously working code is having trouble running in parallel. I've narrowed it down to the calls to PetscSynchronizedFPrintf. Even if I don't have those, I will have errors at the end of my MPI runs like: [1]PETSC ERROR: PetscMemzero() line 189 in src/sys/utils/memc.c [1]PETSC ERROR: PetscViewerASCIISynchronizedPrintf() line 859 in src/sys/viewer/impls/ascii/filev.c [1]PETSC ERROR: PetscMemoryShowUsage() line 367 in src/sys/memory/mtr.c [1]PETSC ERROR: PetscFinalize() line 675 in src/sys/objects/pinit.c [1]PETSC ERROR: completeSection() line 163 in main.cxx [0]0:Return code = 0, signaled with Interrupt [0]1:Return code = 85 Since the same code was running fine before the update. I am wondering if it is something recently introduced. Thanks a lot. -- Shi Jin, PhD -- 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 -- 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
problem with PetscSynchronizedFPrintf (fwd)
Fixed.
Matt
On Mon, Jul 21, 2008 at 3:32 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Matt,
While you are at it could you please fix the buggy code in mprint.c?
make PETSC_DIR=/Users/bsmith/Src/petsc-dev-for-fixes
PETSC_ARCH=arch-icc-ifort
/Users/bsmith/Src/petsc-dev-for-fixes/arch-icc-ifort/bin/mpicc -o mprint.o
-c -wd1572 -Qoption,cpp,--extended_float_type -g
-I/Users/bsmith/Src/petsc-dev-for-fixes
-I/Users/bsmith/Src/petsc-dev-for-fixes/arch-icc-ifort/include
-I/Users/bsmith/Src/petsc-dev-for-fixes/include -I/usr/X11/include
-I/Users/bsmith/Src/petsc-dev-for-fixes/arch-icc-ifort/include
-D__SDIR__='src/sys/fileio/' mprint.c
mprint.c(350): warning #592: variable fullLength is used before its value
is set
while(fullLength = next-size) {
^
On Jul 21, 2008, at 3:30 PM, Matthew Knepley wrote:
Pushed a fix. I missed the Viewer when I corrected the raw call. That
should
not be separate code.
Matt
On Mon, Jul 21, 2008 at 2:54 PM, Satish Balay balay at mcs.anl.gov wrote:
Matt - Perhaps ex7 is a different Problem. But it does crash for me.
And I noticed the following code:
ierr = PetscNew(struct _PrintfQueue,next);CHKERRQ(ierr);
if (queue) {queue-next = next; queue = next;}
else {queuebase = queue = next;}
queuelength++;
string = next-string;
ierr = PetscMemzero(string,QUEUESTRINGSIZE);CHKERRQ(ierr);
i.e 'next' is allocated - here is no malloc for 'next-string'. But
its being zeroed in PetscMemzero() - hence the crash with ex7 for me.
Satish
-
asterix:/home/balay/spetsc/src/dm/ao/examples/testsmpiexec -n 2 ./ex7
Number of elements in ordering 10
PETSc-App App-PETSc
00 00
15 12
21 24
36 36
42 48
57 51
63 63
78 75
84 87
99 99
[1]PETSC ERROR: - Error Message
[1]PETSC ERROR: Null argument, when expecting valid pointer!
[1]PETSC ERROR: Trying to zero at a null pointer!
[1]PETSC ERROR:
[1]PETSC ERROR: Petsc Development Version 2.3.3, Patch 13, unknown HG
revision: unknown
[1]PETSC ERROR: See docs/changes/index.html for recent updates.
[1]PETSC ERROR: See docs/faq.html for hints about trouble shooting.
[1]PETSC ERROR: See docs/index.html for manual pages.
[1]PETSC ERROR:
[1]PETSC ERROR: ./ex7 on a asterix64 named asterix by balay Mon Jul 21
14:51:02 2008
[1]PETSC ERROR: Libraries linked from /home/balay/spetsc/lib
[1]PETSC ERROR: Configure run at Mon Jul 21 10:38:52 2008
[1]PETSC ERROR: Configure options
--with-mpi-dir=/home/balay/soft/linux64/mpich2-1.0.7 --with-shared=1
PETSC_ARCH=asterix64
[1]PETSC ERROR: [0] Number of indices in
(stride) set 5
[0] 0 0
[0] 1 2
[0] 2 4
[0] 3 6
[0] 4 8
[1]PETSC ERROR: PetscMemzero() line 189 in src/sys/utils/memc.c
[1]PETSC ERROR: PetscViewerASCIISynchronizedPrintf() line 859 in
src/sys/viewer/impls/ascii/filev.c
[1]PETSC ERROR: ISView_Stride() line 231 in
src/vec/is/impls/stride/stride.c
[1]PETSC ERROR: ISView() line 398 in src/vec/is/interface/index.c
[1]PETSC ERROR: main() line 31 in src/dm/ao/examples/tests/ex7.c
application called MPI_Abort(MPI_COMM_WORLD, 85) - process 1[cli_1]:
aborting job:
application called MPI_Abort(MPI_COMM_WORLD, 85) - process 1
[0]0:Return code = 0, signaled with Interrupt
[0]1:Return code = 85
asterix:/home/balay/spetsc/src/dm/ao/examples/tests
On Mon, 21 Jul 2008, Matthew Knepley wrote:
I made this change because synchronized printing was cutting off my
stuff. Now the queue is dynamically allocated so it can accomodate
any size string.
I tried ex7 and it runs fine for me, even under valgrind.
Shi, can you reproduce this with a Sieve example?
Matt
On Mon, Jul 21, 2008 at 2:37 PM, Satish Balay balay at mcs.anl.gov wrote:
Looks like this could be related to changeset 9e3fbe04a926
-- mprint.h --
- charstring[QUEUESTRINGSIZE];
+ char *string;
So now strings needs to use malloc()/free()?
Matt - you can reproduce this issue with dm/ao/examples/tests/ex7.c
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
--
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
problem with PetscSynchronizedFPrintf (fwd)
On Mon, Jul 21, 2008 at 3:03 PM, Barry Smith bsmith at mcs.anl.gov wrote: Matt, You have to be careful here. You use PetscMalloc() here, are you positive this routine will never be called BEFORE PetscMalloc() is setup for (sometime in PetscInitialize), or after PetscMalloc() is taken down (somewhere in PetscFinalize())? Is there someway you can make sure that it is safe? In a few places on setup I have to use a raw malloc instead of PetscMalloc(), I don't want you to have to do that here. I'm not saying to change back the code, just to be careful and check it. I looked at all the code. There are no calls in PetscInitialize() and I cannot find anything else that might be called before PetscMalloc is set. Matt Barry On Jul 21, 2008, at 2:47 PM, Matthew Knepley wrote: I made this change because synchronized printing was cutting off my stuff. Now the queue is dynamically allocated so it can accomodate any size string. I tried ex7 and it runs fine for me, even under valgrind. Shi, can you reproduce this with a Sieve example? Matt On Mon, Jul 21, 2008 at 2:37 PM, Satish Balay balay at mcs.anl.gov wrote: Looks like this could be related to changeset 9e3fbe04a926 -- mprint.h -- - charstring[QUEUESTRINGSIZE]; + char *string; So now strings needs to use malloc()/free()? Matt - you can reproduce this issue with dm/ao/examples/tests/ex7.c Satish On Mon, 21 Jul 2008, Satish Balay wrote: -- Forwarded message -- Date: Sun, 20 Jul 2008 22:39:13 -0700 (PDT) From: Shi Jin jinzishuai at yahoo.com Subject: problem with PetscSynchronizedFPrintf To: petsc-dev at mcs.anl.gov Hi, I recently updated my petsc-dev and found my previously working code is having trouble running in parallel. I've narrowed it down to the calls to PetscSynchronizedFPrintf. Even if I don't have those, I will have errors at the end of my MPI runs like: [1]PETSC ERROR: PetscMemzero() line 189 in src/sys/utils/memc.c [1]PETSC ERROR: PetscViewerASCIISynchronizedPrintf() line 859 in src/sys/viewer/impls/ascii/filev.c [1]PETSC ERROR: PetscMemoryShowUsage() line 367 in src/sys/memory/mtr.c [1]PETSC ERROR: PetscFinalize() line 675 in src/sys/objects/pinit.c [1]PETSC ERROR: completeSection() line 163 in main.cxx [0]0:Return code = 0, signaled with Interrupt [0]1:Return code = 85 Since the same code was running fine before the update. I am wondering if it is something recently introduced. Thanks a lot. -- Shi Jin, PhD -- 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 -- 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
Check it out
http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension 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
docs for MINRES, only for positive definite?
Docs are wrong. Matt 2008/2/28 Lisandro Dalcin dalcinl at gmail.com: I've noticed that the docs for MINRES say that the operator and the preconditioner must be POSITIVE DEFINITE. But I understand MINRES is tailored for the symmetric/hermitian-indefinite case. Are the docs wrong? Or the actual code is a (very peculiar) MINRES variant? -- 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 -- 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
docs for MINRES, only for positive definite?
On Thu, Feb 28, 2008 at 10:56 AM, Barry Smith bsmith at mcs.anl.gov wrote: But does it require a positive definite preconditioner? You mean so I can play the trick with M^1/2 A M^1/2 to maintain symmetry? I think you may be right. Matt Barry On Feb 28, 2008, at 9:32 AM, Matthew Knepley wrote: Docs are wrong. Matt 2008/2/28 Lisandro Dalcin dalcinl at gmail.com: I've noticed that the docs for MINRES say that the operator and the preconditioner must be POSITIVE DEFINITE. But I understand MINRES is tailored for the symmetric/hermitian-indefinite case. Are the docs wrong? Or the actual code is a (very peculiar) MINRES variant? -- 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 -- 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 -- 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
docs for MINRES, only for positive definite?
On Thu, Feb 28, 2008 at 11:25 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
Good point, the current code seems to require that...
Its not the code, its the algorithm. It requires symmetry.
Matt
ierr = KSP_PCApply(ksp,R,Z);CHKERRQ(ierr); /* z - B*r */
ierr = VecDot(R,Z,dp);CHKERRQ(ierr);
/*...*/
if (dp 0.0) {
ksp-reason = KSP_DIVERGED_INDEFINITE_PC;
PetscFunctionReturn(0);
}
Indeed, the following (simple minded, diagonal matrix) test fails with
-pc_type jacobi, but success with -pc_type none
import sys, petsc4py
petsc4py.init(sys.argv)
from petsc4py import PETSc
import numpy as N
A = PETSc.Mat().createAIJ([10,10])
for i in range(0,5):
A[i,i] = -(i + 1)
for i in range(5,10):
A[i,i] = +(i + 1)
A.assemble()
A.view()
x, b= A.getVecs()
b.set(1)
ksp = PETSc.KSP().create()
ksp.type = 'minres'
ksp.setOperators(A)
ksp.setFromOptions()
ksp.solve(b,x)
On 2/28/08, Barry Smith bsmith at mcs.anl.gov wrote:
But does it require a positive definite preconditioner?
Barry
On Feb 28, 2008, at 9:32 AM, Matthew Knepley wrote:
Docs are wrong.
Matt
2008/2/28 Lisandro Dalcin dalcinl at gmail.com:
I've noticed that the docs for MINRES say that the operator and the
preconditioner must be POSITIVE DEFINITE. But I understand MINRES is
tailored for the symmetric/hermitian-indefinite case.
Are the docs wrong? Or the actual code is a (very peculiar) MINRES
variant?
--
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
--
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
--
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
--
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
docs for MINRES, only for positive definite?
On Thu, Feb 28, 2008 at 11:35 AM, Barry Smith bsmith at mcs.anl.gov wrote:
symmetry has nothing to do with it. Yes the matrix and
preconditioner must be
symmetric. The point is that the preconditioner has to also be
positive definite.
Because B is used in the algorithm to define a norm.
I disagree. Here is a weaker condition:
1) A is symmetric indefinite and so is B
2) BA is also symmetric
Since A and B are full rank, so is BA. Thus BA is symmetric indefinite
and MINRES will work.
My comment was that if B is SPD, then BA is equivalent to B^1/2 A
B^1/2 and thus symmetric.
Matt
Barry
On Feb 28, 2008, at 11:28 AM, Matthew Knepley wrote:
On Thu, Feb 28, 2008 at 11:25 AM, Lisandro Dalcin
dalcinl at gmail.com wrote:
Good point, the current code seems to require that...
Its not the code, its the algorithm. It requires symmetry.
Matt
ierr = KSP_PCApply(ksp,R,Z);CHKERRQ(ierr); /* z - B*r */
ierr = VecDot(R,Z,dp);CHKERRQ(ierr);
/*...*/
if (dp 0.0) {
ksp-reason = KSP_DIVERGED_INDEFINITE_PC;
PetscFunctionReturn(0);
}
Indeed, the following (simple minded, diagonal matrix) test fails
with
-pc_type jacobi, but success with -pc_type none
import sys, petsc4py
petsc4py.init(sys.argv)
from petsc4py import PETSc
import numpy as N
A = PETSc.Mat().createAIJ([10,10])
for i in range(0,5):
A[i,i] = -(i + 1)
for i in range(5,10):
A[i,i] = +(i + 1)
A.assemble()
A.view()
x, b= A.getVecs()
b.set(1)
ksp = PETSc.KSP().create()
ksp.type = 'minres'
ksp.setOperators(A)
ksp.setFromOptions()
ksp.solve(b,x)
On 2/28/08, Barry Smith bsmith at mcs.anl.gov wrote:
But does it require a positive definite preconditioner?
Barry
On Feb 28, 2008, at 9:32 AM, Matthew Knepley wrote:
Docs are wrong.
Matt
2008/2/28 Lisandro Dalcin dalcinl at gmail.com:
I've noticed that the docs for MINRES say that the operator and
the
preconditioner must be POSITIVE DEFINITE. But I understand
MINRES is
tailored for the symmetric/hermitian-indefinite case.
Are the docs wrong? Or the actual code is a (very peculiar) MINRES
variant?
--
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
--
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
--
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
--
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
--
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
Inner KSP never created on SNES
I am not against requiring SetFromOptions() to create default objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
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
--
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/20081202/b284bade/attachment.html
Inner KSP never created on SNES
On Tue, Dec 2, 2008 at 8:41 AM, Barry Smith bsmith at mcs.anl.gov wrote:
Matt,
You are wrong!
I will fix this today.
Okay, thats fine. For hg, you can do annotate on the file to see what lines
come from what version, and also log to see which sets changed it. You can
also search in hg view.
Matt
Barry
On Dec 2, 2008, at 8:29 AM, Matthew Knepley wrote:
I am not against requiring SetFromOptions() to create default objects. We
already require it to set a default type.
Matt
On Tue, Dec 2, 2008 at 8:08 AM, Lisandro Dalcin dalcinl at gmail.com
wrote:
I've just noticed that now SNES does not create the inner KSP at the
time SNESCreate() is called. Then I could easily manage to break
things (basically, if SNESSetFromOptions() is never called)
Does it make sense to add:
if (!snes-ksp) { SNESGetKSP(snes, snes-ksp);}
near the begining of SNESSetUp() ??
--
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
--
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
--
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/20081202/3ba0456a/attachment.html
an small and perhaps unimportant gotcha
This is strange. I just tried KSP ex2 and after MatSetType() the type_name
is
set. What does *.setType() call?
Matt
On Tue, Dec 2, 2008 at 9:12 AM, Lisandro Dalcin dalcinl at gmail.com wrote:
Other (really nice!) change I've noticed is that now we can call
{Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
However, see this.
In [1]: from petsc4py import PETSc
In [2]: x = PETSc.Vec().create()
In [3]: x.setType('seq')
In [4]: print x.getType()
None
In [5]: A = PETSc.Mat().create()
In [6]: A.setType('seqaij')
In [7]: print A.getType()
None
Internally, the type_name field is never set, it still is NULL (then
petsc4y returns None).
The problem is that forcing the type_name to be set will be really
dangerous (rmember PetscValidType macro).
Any comments?
--
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
--
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/20081202/7173c780/attachment.html
some problems with 'make install'
On Tue, Dec 2, 2008 at 1:31 PM, Satish Balay balay at mcs.anl.gov wrote:
On Mon, 1 Dec 2008, Lisandro Dalcin wrote:
I'm testing configure passing '--prefix=', and after building, I do
$ su -c 'make install'
But then, some files ('configure.log', 'RDict.db') are left with
'root:root' owner and group. If you want to build/rebuild again, this
fails bad.
And you know, using 'sudo' is not always a chance, as depending on
'sudo' configuration, it does not preserve the environment.
I don't see configure.log - but I see build.log and default.log. These
should not cause conflict - but RDict.db does.
Matt would have to check this issue. Ideally most of these files
should not be created during 'make install'
As a hack - I can add os.remove('RDict.db') in config/installer.py
I am for this.
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/20081202/d0e1aeec/attachment.html
fixes for VecPlaceArray/VecResetArray
On Wed, Dec 3, 2008 at 5:04 PM, Lisandro Dalcin dalcinl at gmail.com wrote: I've pushed some fixes for VecPlaceArray/VecResetArray, trying to the pair a bit more smarter. However, the I'm not sure what's the use case in VecPlaceArray for accepting NULL for the array. Just in case, I did not changed this, but if NULL is actually pased, then the call is now non-op. Is this fine? I'm missing something?? I think you would like to reset the array back to NULL sometimes, to clear out memory of an old array it no longer owns. Is this right? Matt -- 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 -- 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/20081203/b7ddf925/attachment.html
Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
I for one think it should be possible to remove 'make' from the
toolchain, leaving us with only win32fe, which we distribute. Thus
I think we could abandon cygwin once and for all. I would even be
willing to write a \emph{make clone} to accomplish this, even though
I am a committed enemy of make (which once TP'ed my house).
Matt
-- Forwarded message --
From: Barry Smith bsm...@mcs.anl.gov
Date: Thu, Dec 4, 2008 at 12:00 PM
Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
To: Stefan Benkler benkler at itis.ethz.ch
Cc: petsc-maint at mcs.anl.gov
Stefan,
Here is my understanding of the situation.
Conjecture: You CAN use an open source compiler (GNU) to compile
proprietary code and then sell
the binaries without making the proprietary code GNU licensed so long as you
just use the
GNU compilers out of the box and don't change their source code and don't
include the compliers
libraries in your binaries.
IF this is true then you are safe, the Cygwin environment is only used by
PETSc to have
a system to compile PETSc. None of it is included in the binaries generated.
On the other hand, if my initial conjecture is wrong, then there could be a
problem.
Barry
We've tried over the years to use Windows posix environments to develop a
build system
for PETSc so we don't need cygwin to build PETSc. Unfortunately their stuff
is so un-unix
like that it just wasn't practical and using developers studio to build
PETSc directly is
possible but requires some how getting all the PETSc source properly into
developers studio
and as far as I know the only way to do this is manually through the gui
which is very painful;
plus if we change something in the Unix build side later we'd need to change
it manually
on the developers studio side.
If the situation has changed and Windows does provide a reasonable way to
build large
unix codes I'd love to hear about it and use it. We hate cygwin but feel
with have no other
reasonable option.
On Dec 4, 2008, at 3:33 AM, Stefan Benkler wrote:
Dear PETSc developers
Since a while, I successfully use your fantastic library on Windows. Thank
you very much!
Lately, I had a discussion about the involved copyrights/licenses with a
colleague. The main point was if PETSc requires the POSIX layer of cygwin on
Windows (and therefore would need to fulfill cygwin's GPL license).
My standpoint was that cygwin is just used to configure and build the
library, but only native Windows libraries (using MS or Intel's Windows
compiler, MKL) are finally linked to the PETSc libs. However, I have
difficulties to proof this claim, which is the reason for this email.
Please comment/clarify the licensing on a Windows system.
Thanks a lot for your informations.
Best regards
Stefan Benkler
--
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/20081204/55dc7a43/attachment.html
Fwd: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, Dec 4, 2008 at 12:41 PM, Satish Balay balay at mcs.anl.gov wrote:
On Thu, 4 Dec 2008, Matthew Knepley wrote:
I for one think it should be possible to remove 'make' from the
toolchain, leaving us with only win32fe, which we distribute. Thus
I think we could abandon cygwin once and for all. I would even be
willing to write a \emph{make clone} to accomplish this, even though
I am a committed enemy of make (which once TP'ed my house).
For one there is some cygwin code in win32fe to handle cygwin paths
[its difficult for us avoid doing this - and solely rely on MS path
scheme in our builds].
Did not know that. It will have to be rewritten.
And I don't think its an issue of 'make clone'. We use tons of shell
and other unixy stuff in the build process - within each recursive
make invocation steps.
We have slowly eliminated the use of UNIX tools from the build. I believe
the last impediment is shell. All this shell code would be converted to
Python, since our 'make clone' would speak Python natively instead of shell.
The March of Progress.
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/20081204/d7fb3db5/attachment.html
[PETSC #18705] PETSc and Cygwin License (POSIX layer)
On Thu, Dec 4, 2008 at 12:42 PM, Barry Smith bsmith at mcs.anl.gov wrote:
Make is NOT the problem! (It is just one of several)
Config/configure.py uses the SHELL constantly for basically everything.
Try running config/configure.py
under Windows without using cygwin.
I disagree with this characterization. The lowest level definitely spawns
shell jobs, however at the configure
level, they are a small set of specific tasks, and it would not be hard to
retarget them to a different architecture.
For instance, almost everything comes down to a compile, link, or execution.
I will now say toolbox, or maybe
toolbag (buildstuff?).
Matt
I hate the term toolchain
Barry
On Dec 4, 2008, at 12:04 PM, Matthew Knepley wrote:
I for one think it should be possible to remove 'make' from the
toolchain, leaving us with only win32fe, which we distribute. Thus
I think we could abandon cygwin once and for all. I would even be
willing to write a \emph{make clone} to accomplish this, even though
I am a committed enemy of make (which once TP'ed my house).
Matt
-- Forwarded message --
From: Barry Smith bsmith at mcs.anl.gov
Date: Thu, Dec 4, 2008 at 12:00 PM
Subject: Re: [PETSC #18705] PETSc and Cygwin License (POSIX layer)
To: Stefan Benkler benkler at itis.ethz.ch
Cc: petsc-maint at mcs.anl.gov
Stefan,
Here is my understanding of the situation.
Conjecture: You CAN use an open source compiler (GNU) to compile
proprietary code and then sell
the binaries without making the proprietary code GNU licensed so long as
you just use the
GNU compilers out of the box and don't change their source code and don't
include the compliers
libraries in your binaries.
IF this is true then you are safe, the Cygwin environment is only used by
PETSc to have
a system to compile PETSc. None of it is included in the binaries
generated.
On the other hand, if my initial conjecture is wrong, then there could be
a problem.
Barry
We've tried over the years to use Windows posix environments to develop
a build system
for PETSc so we don't need cygwin to build PETSc. Unfortunately their
stuff is so un-unix
like that it just wasn't practical and using developers studio to build
PETSc directly is
possible but requires some how getting all the PETSc source properly into
developers studio
and as far as I know the only way to do this is manually through the gui
which is very painful;
plus if we change something in the Unix build side later we'd need to
change it manually
on the developers studio side.
If the situation has changed and Windows does provide a reasonable way to
build large
unix codes I'd love to hear about it and use it. We hate cygwin but feel
with have no other
reasonable option.
On Dec 4, 2008, at 3:33 AM, Stefan Benkler wrote:
Dear PETSc developers
Since a while, I successfully use your fantastic library on Windows. Thank
you very much!
Lately, I had a discussion about the involved copyrights/licenses with a
colleague. The main point was if PETSc requires the POSIX layer of cygwin on
Windows (and therefore would need to fulfill cygwin's GPL license).
My standpoint was that cygwin is just used to configure and build the
library, but only native Windows libraries (using MS or Intel's Windows
compiler, MKL) are finally linked to the PETSc libs. However, I have
difficulties to proof this claim, which is the reason for this email.
Please comment/clarify the licensing on a Windows system.
Thanks a lot for your informations.
Best regards
Stefan Benkler
--
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
--
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/20081204/2f6defad/attachment.html
