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

Re: [petsc-dev] What is this for?
by Matthew Knepley 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 6:30 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Nov 15, 2011 at 18:18, Sean Farley <sean(a)mcs.anl.gov> wrote: > >> I think this is a wholly bad idea. Putting build logic down in individual >>> makefiles is bad. >> >> >> Why should every object file be built with -I${VALGRIND_INCLUDE}? Why >> can't just the valgrind sources be compiled with the valgrind flags? >> > > I agree. Including all the dependent libraries is more fragile. We use MPI > in our public interface (this is a good thing), so it's okay to include > mpi.h. All the other headers should not be in the public interface. Note > that this is also important so that they can link with -lpetsc instead of > needing -lpetsc -lvarious -lother > -llibs-that-are-different-for-each-configuration. > Yes, but you are advocating a really shitty infrastructure for doing this. How do you expose these when the user turns out to want them (like ParMetis for instance)? How do you follow the chain back to find a bug if you have build logic scattered all over? 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] What is this for?
by Jed Brown 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 18:18, Sean Farley <sean(a)mcs.anl.gov> wrote: > I think this is a wholly bad idea. Putting build logic down in individual >> makefiles is bad. > > > Why should every object file be built with -I${VALGRIND_INCLUDE}? Why > can't just the valgrind sources be compiled with the valgrind flags? > I agree. Including all the dependent libraries is more fragile. We use MPI in our public interface (this is a good thing), so it's okay to include mpi.h. All the other headers should not be in the public interface. Note that this is also important so that they can link with -lpetsc instead of needing -lpetsc -lvarious -lother -llibs-that-are-different-for-each-configuration.

1 0

Re: [petsc-dev] snes/examples/tutorials/ex27.c
by Jed Brown 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 18:16, Matthew Knepley <knepley(a)gmail.com> wrote: > If you have a hammer, everything looks like a nail. I think you are > exaggerating the difficulty of doing this for simple cases. > The problem is that it's so frequently wrong. I can ask everyone to implement one interface that is always correct, or I can give them two interfaces, one of which is correct 40% of the time (or 95%, it doesn't matter), but then I have to explain under what conditions it is correct, the relative advantages of each interface, and deal with support requests when people don't read that documentation. If the always-correct interface is easy enough to always use, then we should always use it.

1 0

Re: [petsc-dev] What is this for?
by Sean Farley 15 Nov '11

15 Nov '11

> > I think this is a wholly bad idea. Putting build logic down in individual > makefiles is bad. Why should every object file be built with -I${VALGRIND_INCLUDE}? Why can't just the valgrind sources be compiled with the valgrind flags?

1 0

Re: [petsc-dev] What is this for?
by Matthew Knepley 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 6:14 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Nov 15, 2011 at 18:12, Matthew Knepley <knepley(a)gmail.com> wrote: > >> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0910059a9184 > > > One small step in a plan to be less promiscuous. > I think this is a wholly bad idea. Putting build logic down in individual makefiles is bad. 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] snes/examples/tutorials/ex27.c
by Matthew Knepley 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 6:06 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Nov 15, 2011 at 18:03, Matthew Knepley <knepley(a)gmail.com> wrote: > >> What are you on? It is F(x) = 0. This embedding will not work for all >> problems, but it will work for many, and be easy. If you >> have a more complicated system, by all means us TS, however I am pointing >> out that there are useful regimes where this >> kind of embedding would work. >> > > Is the underlying transient problem xdot+F(x)=0 or xdot=F(x)? > > What happens if you enforce boundary conditions without eliminating them > (like almost every PETSc example)? > > Just use the TS interface if time might be involved. Then you can do > everything. > If you have a hammer, everything looks like a nail. I think you are exaggerating the difficulty of doing this for simple cases. Matt > Making assumptions about what the user meant when they were using a > lower-level interface doesn't help. And just to get an "enclosing TS", they > had to write some setup code. At that point, it's no more difficult to > implement the TS callbacks than to implement the SNES callbacks. > -- 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] What is this for?
by Jed Brown 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 18:12, Matthew Knepley <knepley(a)gmail.com> wrote: > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0910059a9184 One small step in a plan to be less promiscuous.

1 0

What is this for?
by Matthew Knepley 15 Nov '11

15 Nov '11

http://petsc.cs.iit.edu/petsc/petsc-dev/rev/0910059a9184 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] snes/examples/tutorials/ex27.c
by Jed Brown 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 18:03, Matthew Knepley <knepley(a)gmail.com> wrote: > What are you on? It is F(x) = 0. This embedding will not work for all > problems, but it will work for many, and be easy. If you > have a more complicated system, by all means us TS, however I am pointing > out that there are useful regimes where this > kind of embedding would work. > Is the underlying transient problem xdot+F(x)=0 or xdot=F(x)? What happens if you enforce boundary conditions without eliminating them (like almost every PETSc example)? Just use the TS interface if time might be involved. Then you can do everything. Making assumptions about what the user meant when they were using a lower-level interface doesn't help. And just to get an "enclosing TS", they had to write some setup code. At that point, it's no more difficult to implement the TS callbacks than to implement the SNES callbacks.

1 0

Re: [petsc-dev] snes/examples/tutorials/ex27.c
by Matthew Knepley 15 Nov '11

15 Nov '11

On Tue, Nov 15, 2011 at 5:43 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Nov 15, 2011 at 17:37, Matthew Knepley <knepley(a)gmail.com> wrote: > >> b) FormFunction and FormJacobian in a SNES could be used by an >> enclosing TS to do pseudo-timestepping > > > This can't work. What equation would the FormFunction and FormJacobian > correspond to? > What are you on? It is F(x) = 0. This embedding will not work for all problems, but it will work for many, and be easy. If you have a more complicated system, by all means us TS, however I am pointing out that there are useful regimes where this kind of embedding would work. Matt > The TS *defines* the equation that needs to be solved. The user provides > information according to an interface. The TS interface is more general, > and really is required for transient things. The SNESFormFunction isn't > enough because you haven't identified positivity and constraints. Add that > transient term to all variables equally and you are going to see some > confusing stuff like huge conservation error and incorrect boundary > conditions, such that you could easily end up on the wrong branch or > mis-diagnose a limit cycle versus steady state. > -- 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