[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
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. Incidentally, currently there appears to be no way to supply additional linker flags, as used to be the case with LDFLAGS. Dmitry. -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/ba455026/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:42 AM, Matthew Knepley knepley at gmail.com wrote: 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. Sorry, I meant configure-time option. Does sharedLinkerFlags alter the behavior of CLINKER? 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/b3fa10ca/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] PetscDLSym called on an empty handle
On Thu, Aug 5, 2010 at 11:53 AM, Matthew Knepley knepley at gmail.com wrote: On Thu, Aug 5, 2010 at 11:47 AM, Dmitry Karpeev karpeev at mcs.anl.govwrote: 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. Actually, I'm guessing that there should be a configure-time option to figure out the platform-dependent way of exporting symbols as dynamic, and then a compile-time option to actually export the executable's symbols. (Not everybody may want to pollute the dynamic symbol table and, potentially, increase the required symbol search time). Dmitry. 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/d57be3d3/attachment.html
[petsc-dev] easyinstall for petsc4py
On Aug 5, 2010, at 9:59 AM, Matthew Knepley wrote: 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? As Matt says in too many words absolutely We'd like to remove all the pain of using petsc4py so it will be trivially used with packages like SAGE and Scipy etc. It is too painful now for Python users since it requires installing PETSc manually. The reason I want to look for mpi4py is to determine what MPI it was built with so PETSc would be built with the same MPI (and hence can be used with mpi4py). Barry 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/3827abc1/attachment.html
[petsc-dev] easyinstall for petsc4py
On 5 August 2010 15:16, Barry Smith bsmith at mcs.anl.gov wrote: 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? ?? As Matt says in too many words absolutely ?? We'd like to remove all the pain of using petsc4py so it will be trivially used with packages like SAGE and Scipy etc. It is too painful now for Python users since it requires installing PETSc manually. ?? The reason I want to look for mpi4py is to determine what MPI it was built with so PETSc would be built with the same MPI (and hence can be used with mpi4py). ?? Barry OK, now I can see what all you want. However, I think mpi4py would not help you on this. mpi4py does not have a real configure step... It just look for 'mpicc' compiler wrapper in $PATH and uses it if found. If not found (eg. on Windows), things do not work out of the box, users have to edit a mpi.cfg file provinding include an library dirs and libraries to link. And that information is not recorded on the mpi4py install, so basically mpi4py cannot tell us any info about the MPI it was built with. Add to all this that Python's distutils is kinda fragile and you have to constantly hack and monkeypatch things. Perhaps what we really need is a super-script (with GUI?) that manages the download and install of PETSc, SLEPc, mpi4py, petsc4py and slepc4py? PS: You may think I'm lazy/idiot/whatever, but mpi4py and petsc4py buildsystems are very limited, this is because I constrained myself to implement it with standard Python distutils and live with that. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] easyinstall for petsc4py
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. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] 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] PetscDLSym called on an empty handle
On 5 August 2010 13:40, 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). Look at your dlfch.h header file.. Does it have the line below?: # define RTLD_DEFAULT ((void *) 0) -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] PetscDLSym called on an empty handle
On Thu, Aug 5, 2010 at 4:00 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 13:40, 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). Look at your dlfch.h header file.. Does it have the line below?: # define RTLD_DEFAULT ((void *) 0) Yes. Ah, I see: my problem was that the symbol wasn't being exported, not that the null handle wasn't referring to the executable. I guess I can change it to use RTLD_DEFAULT, but that would require changes to configure. Also, this may be less portable: OSX uses a different define for the default handle, so configure would have to test for that too. I wonder what OSX does for dlopen(0,flags)? Dmitry. -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/56630590/attachment.html
[petsc-dev] PetscDLSym called on an empty handle
On 5 August 2010 18:07, Dmitry Karpeev karpeev at mcs.anl.gov wrote: On Thu, Aug 5, 2010 at 4:00 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 13:40, 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). Look at your dlfch.h header file.. Does it have the line below?: # define RTLD_DEFAULT ? ((void *) 0) Yes.? Ah, I see: my problem was that the symbol wasn't being exported, not that the null handle wasn't referring to the executable. Yep I guess I can change it to use RTLD_DEFAULT, but that would require changes to configure. Using RTLD_DEFAULT is the right way to do it. Also, this may be less portable: OSX uses a different define for the default handle, so configure would have to test for that too.? I wonder what OSX does for dlopen(0,flags)? It likely fails with invalid handle passed to dlsym() (http://www.opensource.apple.com/source/dyld/dyld-132.13/src/dyldAPIs.cpp) -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] PetscDLSym called on an empty handle
On Thu, Aug 5, 2010 at 7:48 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 18:07, Dmitry Karpeev karpeev at mcs.anl.gov wrote: On Thu, Aug 5, 2010 at 4:00 PM, Lisandro Dalcin dalcinl at gmail.com wrote: On 5 August 2010 13:40, 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). Look at your dlfch.h header file.. Does it have the line below?: # define RTLD_DEFAULT ((void *) 0) Yes. Ah, I see: my problem was that the symbol wasn't being exported, not that the null handle wasn't referring to the executable. Yep I guess I can change it to use RTLD_DEFAULT, but that would require changes to configure. Using RTLD_DEFAULT is the right way to do it. Also, this may be less portable: OSX uses a different define for the default handle, so configure would have to test for that too. I wonder what OSX does for dlopen(0,flags)? It likely fails with invalid handle passed to dlsym() (http://www.opensource.apple.com/source/dyld/dyld-132.13/src/dyldAPIs.cpp) The implementation of dlsym from the link above seems to imply that RTLD_DEFAULT on OSX means search EVERYTHING, not just the main executable. No? Some of that Apple-specific code is impenetrable to me. If I'm right, then this is contrary to the way Linux interprets RTLD_DEFAULT. The Apple equivalent seems to be RTLD_MAIN_ONLY. Currently PetscDLSym(0,symbol,value) is implemented to search the main executable on Windows (at least that's how I read that code, without being too familiar with the Windows API). So I assume that's what we want to do everywhere else, including on OSX. This, in turn, means using RTLD_DEFAULT on Linux, RTLD_MAIN_ONLY on Apple. Dmitry. -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100805/e47bd150/attachment.html
[petsc-dev] easyinstall for petsc4py
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)... Disclaimer: I've not actually tested this in a long time. If it does not work, it should easy to fix. Right not I do not remember the logics to make things work with prefix and non-prefix PETSc installs, but I remember handling these two cases. ? ?I image the petsc4py install would look for mpi4py, if it finds it then figure out the MPI used to build it and pass that MPi information on to PETSc's configure. Perhaps this will surprise you: petsc4py does not depend in any way on mpi4py. Still, you can still pass an mpi4py.MPI.Comm instance, and petsc4py will accept it and do the right thing... If it does not find mpi4py then it would tell PETSc configure to not use MPI. If this doesn't make sense, I just made it up so I can understand it might not make sense, tell us how it should work. petsc4py actually parses PETSc makefiles ($PETSC_ARCH/conf/petscvariables) and uses that for build. So petsc4py will use mpicc or plain gcc depending on the value of makefile variables like PCC. ? ?We would also like to add some nightly tests for petsc-dev/petsc4py-dev and help keep petsc4py-dev in sync with petsc-dev. Having nightly tests running would be wonderful. About keeping it in sync with petsc-dev, I have one additional issue: keep it working against previous PETSc releases... Satish can you check into how you can add this? Provided that Cython is installed, It is just a matter of following the steps below: cd petsc4py-dev hg pull -u python conf/cythonize.py export PETSC_DIR=... export PETSC_ARCH=... python setup.py install --home=...|--prefix= python test/runtests.py PS: I'll not be available until next Monday. But all what Barry wants should be VERY easy to setup. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169
[petsc-dev] automatic preconditioners for Stokes type problems?
If someone tells us, I have a Stokes problem, we could search for 0 diagonals and create the partition for FS. Matt On Wed, Aug 4, 2010 at 11:30 AM, Barry Smith bsmith at mcs.anl.gov wrote: Is there anyway we could have a preconditioner automatically detect a stokes problem and figure out which rows/columns to Schur complement out with PCFIELDSPLIT? 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/20100805/34d3de68/attachment.html
[petsc-dev] automatic preconditioners for Stokes type problems?
On Thu, 5 Aug 2010 00:21:13 -0500, Matthew Knepley knepley at gmail.com wrote: If someone tells us, I have a Stokes problem, we could search for 0 diagonals and create the partition for FS. I suppose this would work for some common cases, but there are lot of discretizations and pressure-dependent constitutive relations/boundary conditions that have nonzeros in the pressure block. I think some slip conditions can also produce zero or negative values in the momentum block. I'm not convinced that it's so much to ask people to provide an index set, considering that FieldSplit is a somewhat advanced thing anyway (based on sheer number of choices available, and (typical) sensitivity to those choices). Jed
[petsc-dev] automatic preconditioners for Stokes type problems?
On Thu, Aug 5, 2010 at 2:10 AM, Jed Brown jed at 59a2.org wrote: On Thu, 5 Aug 2010 00:21:13 -0500, Matthew Knepley knepley at gmail.com wrote: If someone tells us, I have a Stokes problem, we could search for 0 diagonals and create the partition for FS. I suppose this would work for some common cases, but there are lot of discretizations and pressure-dependent constitutive relations/boundary conditions that have nonzeros in the pressure block. I think some slip conditions can also produce zero or negative values in the momentum block. Do not disagree. I'm not convinced that it's so much to ask people to provide an index set, considering that FieldSplit is a somewhat advanced thing anyway (based on sheer number of choices available, and (typical) sensitivity to those choices). I guess the point here is somewhat like the point of DAs. It is a very limited thing, but something many people do. So we provide a way to most easily do the very limited thing. Not sure if this is useful enough, but it might be. 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/20100805/c7b926d7/attachment.html
[petsc-dev] automatic preconditioners for Stokes type problems?
Jed brings up good points about false negatives, there are also false positives to worry about. This is a bad idea, at least as a default solver. That said, there is work on adaptive solvers like bootstrap AMG and using machine learning to formalize what it sounds like Barry is driving at. Perhaps make a '-ksp_type black_box' solver type where you put any heuristics methods like this. (this would require the KSP method to change the PC method which is ugly...) Mark On Aug 5, 2010, at 5:36 AM, Matthew Knepley wrote: On Thu, Aug 5, 2010 at 2:10 AM, Jed Brown jed at 59a2.org wrote: On Thu, 5 Aug 2010 00:21:13 -0500, Matthew Knepley knepley at gmail.com wrote: If someone tells us, I have a Stokes problem, we could search for 0 diagonals and create the partition for FS. I suppose this would work for some common cases, but there are lot of discretizations and pressure-dependent constitutive relations/boundary conditions that have nonzeros in the pressure block. I think some slip conditions can also produce zero or negative values in the momentum block. Do not disagree. I'm not convinced that it's so much to ask people to provide an index set, considering that FieldSplit is a somewhat advanced thing anyway (based on sheer number of choices available, and (typical) sensitivity to those choices). I guess the point here is somewhat like the point of DAs. It is a very limited thing, but something many people do. So we provide a way to most easily do the very limited thing. Not sure if this is useful enough, but it might be. 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/20100805/7e275749/attachment.html
[petsc-dev] automatic preconditioners for Stokes type problems?
On Thu, Aug 5, 2010 at 9:45 AM, Mark F. Adams mark.adams at columbia.eduwrote: Jed brings up good points about false negatives, there are also false positives to worry about. This is a bad idea, at least as a default solver. I was not thinking about that at all. There would be no false positives because the user would be required to say I have exactly this Stokes system, I am just too lazy to make my ISes, please do it for me Magic PETSc. Matt That said, there is work on adaptive solvers like bootstrap AMG and using machine learning to formalize what it sounds like Barry is driving at. Perhaps make a '-ksp_type black_box' solver type where you put any heuristics methods like this. (this would require the KSP method to change the PC method which is ugly...) Mark On Aug 5, 2010, at 5:36 AM, Matthew Knepley wrote: On Thu, Aug 5, 2010 at 2:10 AM, Jed Brown jed at 59a2.org wrote: On Thu, 5 Aug 2010 00:21:13 -0500, Matthew Knepley knepley at gmail.com wrote: If someone tells us, I have a Stokes problem, we could search for 0 diagonals and create the partition for FS. I suppose this would work for some common cases, but there are lot of discretizations and pressure-dependent constitutive relations/boundary conditions that have nonzeros in the pressure block. I think some slip conditions can also produce zero or negative values in the momentum block. Do not disagree. I'm not convinced that it's so much to ask people to provide an index set, considering that FieldSplit is a somewhat advanced thing anyway (based on sheer number of choices available, and (typical) sensitivity to those choices). I guess the point here is somewhat like the point of DAs. It is a very limited thing, but something many people do. So we provide a way to most easily do the very limited thing. Not sure if this is useful enough, but it might be. 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/20100805/56a14420/attachment.html
[petsc-dev] easyinstall for petsc4py
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? -- 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
