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

Recent changeset confuses the heck of intel compilers
by Blaise Bourdin 24 Feb '11

24 Feb '11

Hi, Changeset f301815fc494cb333d15c0cefabf71a0988a0321 (rev 18363) seems to confuse the intel compilers (I tested 11.1 on linux x86_64 and mac OS X). After updating past this point, I get tons of warnings like drawv.c(397): warning #187: use of "=" where "==" may have been intended ierr = PetscFree((*sviewer)->data);CHKERRQ(ierr); ^ drawv.c(398): warning #187: use of "=" where "==" may have been intended ierr = PetscHeaderDestroy(*sviewer);CHKERRQ(ierr); ^ drawv.c(398): warning #187: use of "=" where "==" may have been intended ierr = PetscHeaderDestroy(*sviewer);CHKERRQ(ierr); ^ Is this right? Blaise -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

1 0

Re: [petsc-dev] builder.py
by Satish Balay 24 Feb '11

24 Feb '11

On Thu, 24 Feb 2011, Matthew Knepley wrote: > On Wed, Feb 23, 2011 at 5:21 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > On Wed, 23 Feb 2011, Matthew Knepley wrote: > > > > > On Wed, Feb 23, 2011 at 5:17 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > > > It appers to compile only a bit of fortran modules - and not the c > > sources > > > > for me... > > > > > > > > > > Yes, I am fixing that. It is an initialization problem. Since my database > > is > > > already initialized, > > > I did not have it. Should work soon. > > > > > > > > > > And it leaves arround *.d files in my PETSC_DIR > > > > > > > > > > Yes, that way I can rebuild dependencies at any time. > > > > Then they should be in PETSC_DIR/PETSC_ARCH/builder or some other > > location - like cmake does.. > > > Okay, it should work from a clean install now, and it puts the .d in the > right place. I still see the old behavior - only .mod compiles - and .d files in PETSC_DIR Perhaps you haven't pushed yet? Satish

1 0

Re: [petsc-dev] builder.py
by Matthew Knepley 24 Feb '11

24 Feb '11

On Wed, Feb 23, 2011 at 5:21 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Wed, 23 Feb 2011, Matthew Knepley wrote: > > > On Wed, Feb 23, 2011 at 5:17 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > > It appers to compile only a bit of fortran modules - and not the c > sources > > > for me... > > > > > > > Yes, I am fixing that. It is an initialization problem. Since my database > is > > already initialized, > > I did not have it. Should work soon. > > > > > > > And it leaves arround *.d files in my PETSC_DIR > > > > > > > Yes, that way I can rebuild dependencies at any time. > > Then they should be in PETSC_DIR/PETSC_ARCH/builder or some other > location - like cmake does.. Okay, it should work from a clean install now, and it puts the .d in the right place. 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

1 0

Re: [petsc-dev] builder.py
by Satish Balay 23 Feb '11

23 Feb '11

On Wed, 23 Feb 2011, Matthew Knepley wrote: > On Wed, Feb 23, 2011 at 5:17 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > It appers to compile only a bit of fortran modules - and not the c sources > > for me... > > > > Yes, I am fixing that. It is an initialization problem. Since my database is > already initialized, > I did not have it. Should work soon. > > > > And it leaves arround *.d files in my PETSC_DIR > > > > Yes, that way I can rebuild dependencies at any time. Then they should be in PETSC_DIR/PETSC_ARCH/builder or some other location - like cmake does.. Satish

1 0

Re: [petsc-dev] builder.py
by Matthew Knepley 23 Feb '11

23 Feb '11

On Wed, Feb 23, 2011 at 5:17 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > It appers to compile only a bit of fortran modules - and not the c sources > for me... > Yes, I am fixing that. It is an initialization problem. Since my database is already initialized, I did not have it. Should work soon. > And it leaves arround *.d files in my PETSC_DIR > Yes, that way I can rebuild dependencies at any time. Matt > Satish > > ------- > > Building dependencies in /home/balay/tmp/petsc-dev/include > Building dependencies in /home/balay/tmp/petsc-dev/include/sieve > Building dependencies in /home/balay/tmp/petsc-dev/include/finclude > Building dependencies in > /home/balay/tmp/petsc-dev/include/finclude/ftn-auto > Building dependencies in > /home/balay/tmp/petsc-dev/include/finclude/ftn-custom > Building dependencies in /home/balay/tmp/petsc-dev/include/private > Building /home/balay/tmp/petsc-dev/src/sys/f90-mod/petscsysmod.F > Building /home/balay/tmp/petsc-dev/src/vec/f90-mod/petscvecmod.F > Building /home/balay/tmp/petsc-dev/src/mat/f90-mod/petscmatmod.F > Building /home/balay/tmp/petsc-dev/src/dm/f90-mod/petscdmmod.F > Building /home/balay/tmp/petsc-dev/src/ksp/f90-mod/petsckspmod.F > Building /home/balay/tmp/petsc-dev/src/snes/f90-mod/petscsnesmod.F > Building /home/balay/tmp/petsc-dev/src/ts/f90-mod/petsctsmod.F > asterix:/home/balay/tmp/petsc-dev>ls > asterix64/ config/ include/ petsckspmod.d petsctsmod.d > setup.py* xcode/ > bin/ configure* makefile petscmatmod.d petscvecmod.d > src/ > CMakeLists.txt configure.log@ make.log@ petscsnesmod.d projects/ > TAGS > conf/ CTAGS petscdmmod.d petscsysmod.d RDict.log > tutorials/ > asterix:/home/balay/tmp/petsc-dev>ls asterix64/lib/ > libpetsc.a libpetsc-obj/ > asterix:/home/balay/tmp/petsc-dev>ar t asterix64/lib/libpetsc.a > petscsysmod.o > petscvecmod.o > petscmatmod.o > petscdmmod.o > petsckspmod.o > petscsnesmod.o > petsctsmod.o > asterix:/home/balay/tmp/petsc-dev> > > > On Wed, 23 Feb 2011, Matthew Knepley wrote: > > > I have pushed a new version: > > > > 1) F90 modules now build correctly > > > > 2) It has been refactored so that all dependency analysis is done up > > front, and > > all building happens afterwards. > > > > 3) It could take other dependency trackers (insert your favorite) > > > > 4) It should be ready for a nightly build > > > > 5) It should now be possible to use subprocess to completely > parallelize > > the build. > > > > Alert me any problems that come up. It should work for Windows as well, > and > > be > > much faster. > > > > 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

1 0

Re: [petsc-dev] builder.py
by Satish Balay 23 Feb '11

23 Feb '11

It appers to compile only a bit of fortran modules - and not the c sources for me... And it leaves arround *.d files in my PETSC_DIR Satish ------- Building dependencies in /home/balay/tmp/petsc-dev/include Building dependencies in /home/balay/tmp/petsc-dev/include/sieve Building dependencies in /home/balay/tmp/petsc-dev/include/finclude Building dependencies in /home/balay/tmp/petsc-dev/include/finclude/ftn-auto Building dependencies in /home/balay/tmp/petsc-dev/include/finclude/ftn-custom Building dependencies in /home/balay/tmp/petsc-dev/include/private Building /home/balay/tmp/petsc-dev/src/sys/f90-mod/petscsysmod.F Building /home/balay/tmp/petsc-dev/src/vec/f90-mod/petscvecmod.F Building /home/balay/tmp/petsc-dev/src/mat/f90-mod/petscmatmod.F Building /home/balay/tmp/petsc-dev/src/dm/f90-mod/petscdmmod.F Building /home/balay/tmp/petsc-dev/src/ksp/f90-mod/petsckspmod.F Building /home/balay/tmp/petsc-dev/src/snes/f90-mod/petscsnesmod.F Building /home/balay/tmp/petsc-dev/src/ts/f90-mod/petsctsmod.F asterix:/home/balay/tmp/petsc-dev>ls asterix64/ config/ include/ petsckspmod.d petsctsmod.d setup.py* xcode/ bin/ configure* makefile petscmatmod.d petscvecmod.d src/ CMakeLists.txt configure.log@ make.log@ petscsnesmod.d projects/ TAGS conf/ CTAGS petscdmmod.d petscsysmod.d RDict.log tutorials/ asterix:/home/balay/tmp/petsc-dev>ls asterix64/lib/ libpetsc.a libpetsc-obj/ asterix:/home/balay/tmp/petsc-dev>ar t asterix64/lib/libpetsc.a petscsysmod.o petscvecmod.o petscmatmod.o petscdmmod.o petsckspmod.o petscsnesmod.o petsctsmod.o asterix:/home/balay/tmp/petsc-dev> On Wed, 23 Feb 2011, Matthew Knepley wrote: > I have pushed a new version: > > 1) F90 modules now build correctly > > 2) It has been refactored so that all dependency analysis is done up > front, and > all building happens afterwards. > > 3) It could take other dependency trackers (insert your favorite) > > 4) It should be ready for a nightly build > > 5) It should now be possible to use subprocess to completely parallelize > the build. > > Alert me any problems that come up. It should work for Windows as well, and > be > much faster. > > Matt > >

1 0

builder.py
by Matthew Knepley 23 Feb '11

23 Feb '11

I have pushed a new version: 1) F90 modules now build correctly 2) It has been refactored so that all dependency analysis is done up front, and all building happens afterwards. 3) It could take other dependency trackers (insert your favorite) 4) It should be ready for a nightly build 5) It should now be possible to use subprocess to completely parallelize the build. Alert me any problems that come up. It should work for Windows as well, and be much faster. 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

1 0

Re: [petsc-dev] DA refine/coarsen with stencil_width=0 for nproc>1
by Jed Brown 23 Feb '11

23 Feb '11

On Mon, Feb 21, 2011 at 21:39, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Perhaps I'm missing something obvious, but DA refine/coarsen with > stencil_width=0 for nproc>1 is failing, see the example below > Lisandro and I chatted about this earlier. The problem is that getting interpolation will fail because a coarse basis function always crosses the process boundary. You can have the locality if you use Q0 interpolation (maybe that should be set as default for stencil_width=0?), but that will fail even in serial unless you set periodic (which can be used to emulate cell-centered). There is a degenerate case that I think should work in parallel, but does not: Q0 interpolation and periodic refinement. The constraint equations I wrote do not have a solution in this case. I'm not sure if it requires handling as a special case or not. I put the consistency check in because I didn't like needing to wait for a confusing error in DMGetInterpolation when trying to coarsen in an incompatible way. But perhaps it is useful to refine or coarsen with no intention of having an interpolation operator, in which case the check can be removed.

1 0

Re: [petsc-dev] [petsc-users] Pre-conditioners in PETSc
by Jed Brown 22 Feb '11

22 Feb '11

On Tue, Feb 22, 2011 at 18:14, Ethan Coon <ecoon(a)lanl.gov> wrote: > > Also suppose the succeeding statement of KSPSetOperators is > KSPSetFromOptions(ksp_context) and I pass "-pc_type none" at the terminal, > would this mean that Pmat is not at all needed > > > > in PETSc's calculations?? > > Correct, pmat is not used in that case. In that case, you still have to > pass something in to KSPSetOperators, so Amat for both is the likely > choice. I thought it was silly that Pmat needed to be passed in even if it was not used. It turns out that there was a copy-paste error in PCGetOperators() that would overwrite pc->mat if pc->pmat was not set. I updated that function and now PCNONE works even if Pmat was never set. Of course it still makes sense to pass Amat in both slots even if you plan to use PCNONE. More importantly, however, the new error message is at least sensible "null argument" instead of the confusing "type not set" within a MatMult.

1 0

Re: [petsc-dev] Configure argument check
by Matthew Knepley 22 Feb '11

22 Feb '11

On Tue, Feb 22, 2011 at 11:41 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > I believe Jed has suggested before that we multiplex this check over > different architectures. This is also > starting to bite me and I looked at MPI.py. I think just by changing > args.petsc to args.<arch>.petsc we > can achieve this. Of course, it will not work for the unfortunate poop that > use make.inc, but we can clean > that up later. Any objections to this change? > Okay, it looks like the current system should work. I will find the problem I was having. Matt > 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

1 0