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

Re: [petsc-dev] Preconditioner for Schur complement (pcfieldsplit)
by Thomas Witkowski 29 Mar '11

29 Mar '11

Jed Brown wrote: > On Tue, Mar 29, 2011 at 12:55, Thomas Witkowski > <thomas.witkowski(a)tu-dresden.de > <mailto:[email protected]>> wrote: > > I have implemented a Schur complement solver based on the > fieldsplit preconditioner, i.e., my code is executed with the > option -pc_fieldsplit_type schur. How can I define a > preconditioner Sp for the inner Schur complement solution? I want > to define the preconditioner in an explicit way, thus build a > matrix that should approximate S in some way! > > > See PCFieldSplitSchurPrecondition and (perhaps) PCShell. Perhaps if > you give a more specific example, we can give more specific suggestions. PCFieldsplitSchurPrecondition seems to do what I want. But how to create the matrix for the preconditioner? I'm a little bit confused about it because the matrix/operator S acts on an index range that does not start from 0 and is not continuous, because each rank owns only some parts of the interior domain boundaries. Thomas

1 0

Re: [petsc-dev] Preconditioner for Schur complement (pcfieldsplit)
by Jed Brown 29 Mar '11

29 Mar '11

On Tue, Mar 29, 2011 at 12:55, Thomas Witkowski < thomas.witkowski(a)tu-dresden.de> wrote: > I have implemented a Schur complement solver based on the fieldsplit > preconditioner, i.e., my code is executed with the option > -pc_fieldsplit_type schur. How can I define a preconditioner Sp for the > inner Schur complement solution? I want to define the preconditioner in an > explicit way, thus build a matrix that should approximate S in some way! See PCFieldSplitSchurPrecondition and (perhaps) PCShell. Perhaps if you give a more specific example, we can give more specific suggestions.

1 0

Preconditioner for Schur complement (pcfieldsplit)
by Thomas Witkowski 29 Mar '11

29 Mar '11

I have implemented a Schur complement solver based on the fieldsplit preconditioner, i.e., my code is executed with the option -pc_fieldsplit_type schur. How can I define a preconditioner Sp for the inner Schur complement solution? I want to define the preconditioner in an explicit way, thus build a matrix that should approximate S in some way! Thomas

1 0

Re: [petsc-dev] Jed will like this
by Barry Smith 27 Mar '11

27 Mar '11

On Mar 27, 2011, at 3:46 PM, Jed Brown wrote: > On Sun, Mar 27, 2011 at 06:35, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ > > Evidently you missed our discussion on Reader when that went by last week. If it ain't in email or slashdot then I ain't read it :-) Barry > Nobody was impressed with the illusion that computation is about computation more than memory. Such consensus is rare. >

1 0

Re: [petsc-dev] Jed will like this
by Jed Brown 27 Mar '11

27 Mar '11

On Sun, Mar 27, 2011 at 06:35, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ > Evidently you missed our discussion on Reader when that went by last week. Nobody was impressed with the illusion that computation is about computation more than memory. Such consensus is rare.

1 0

Jed will like this
by Barry Smith 26 Mar '11

26 Mar '11

http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

1 0

Re: [petsc-dev] generatefortranstubs.py cannot run concurrently
by Jed Brown 26 Mar '11

26 Mar '11

On Sat, Mar 26, 2011 at 21:20, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I thought of that. But it takes seconds to build and it could be a later > run did come after some change to the files so see no harm in rebuilding. If > setting up the locking mechanism is as messy as doing them in parallel we > might as well do them in parallel. Seems to me that we should write dependencies for those sources and rebuild exactly when they are out of date. One option is to generate them out of the source tree and then move them in atomically. Then it won't matter if concurrent processes occasionally duplicate a small amount of the same work. Note that we pay significantly more to recompile those sources than to generate the fortran stubs.

1 0

Re: [petsc-dev] generatefortranstubs.py cannot run concurrently
by Barry Smith 26 Mar '11

26 Mar '11

I thought of that. But it takes seconds to build and it could be a later run did come after some change to the files so see no harm in rebuilding. If setting up the locking mechanism is as messy as doing them in parallel we might as well do them in parallel. Barry On Mar 26, 2011, at 9:36 AM, Satish Balay wrote: > fortranstubs,etags are common data for all builds. In case of multiple > builds one after another - it was ok to just rebuild each time. > > With parallel builds - it doesn't make sense to rebuild fortranstubs, > etags parallely. > > Perhaps we need some kind of locking mechanism? The first configure > cleates a lock - before starting a build and removes after completion. > > If a subsequent configure comes to the state fo building etags [or > fortranstubs] - it checks the lock - and if it exists - skips the > build? > > Satish > > On Sat, 26 Mar 2011, Jed Brown wrote: > >> Can temporary files be put in a private directory so that multiple >> reconfigures can be run simultaneously? I think the rest of configure works. >> >> >> ******************************************************************************* >> UNABLE to EXECUTE BINARIES for ./configure >> ------------------------------------------------------------------------------- >> [Errno 2] No such file or directory: >> '/home/jed/petsc/src/sys/viewer/interface/f90module.f90' >> ******************************************************************************* >> File "/home/jed/petsc/config/configure.py", line 272, in petsc_configure >> framework.configure(out = sys.stdout) >> File "/home/jed/petsc/config/BuildSystem/config/framework.py", line 922, >> in configure >> child.configure() >> File "/home/jed/petsc/config/PETSc/packages/sowing.py", line 123, in >> configure >> self.buildFortranStubs() >> File "/home/jed/petsc/config/PETSc/packages/sowing.py", line 83, in >> buildFortranStubs >> generatefortranstubs.main(self.petscdir.dir, self.bfort, >> self.petscdir.dir) >> File "/home/jed/petsc/bin/maint/generatefortranstubs.py", line 196, in >> main >> os.path.walk(dir, processDir, [petscdir, bfort]) >> File "/usr/lib/python2.7/posixpath.py", line 237, in walk >> walk(name, func, arg) >> File "/usr/lib/python2.7/posixpath.py", line 237, in walk >> walk(name, func, arg) >> File "/usr/lib/python2.7/posixpath.py", line 237, in walk >> walk(name, func, arg) >> File "/usr/lib/python2.7/posixpath.py", line 237, in walk >> walk(name, func, arg) >> File "/usr/lib/python2.7/posixpath.py", line 229, in walk >> func(arg, top, names) >> File "/home/jed/petsc/bin/maint/generatefortranstubs.py", line 161, in >> processDir >> FixDir(petscdir,outdir) >> File "/home/jed/petsc/bin/maint/generatefortranstubs.py", line 123, in >> FixDir >> >

1 0

alternative computation of overlap in additive Schwarz
by Barry Smith 26 Mar '11

26 Mar '11

Daniel Szyld suggests a refined way of computing overlap for additive Schwarz. Instead of taking all rows/columns connected to the block take those with "strong" coupling. I think this could be easily added to PETSc. The paper is at his website: http://math.temple.edu/szyld I've also added this to the projects file. Barry >

1 0

Re: [petsc-dev] Help
by Sean Farley 26 Mar '11

26 Mar '11

> > I do not see that. Does anyone else? > I see it in Terminal.app if my environment variable TERM is set to 'xterm-265color' however, if it's set to 'xterm-color' (the default) then everything looks fine. Matt, try switching your environment variable to debug. Sean

1 0