August 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Barry Smith 14 Aug '12

14 Aug '12

On Aug 14, 2012, at 5:58 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Aug 14, 2012 at 4:19 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Ok, but then that context cannot be used for any other purpose because of the possible conflict. Which means SNEScoloring thing must be changed. > > Why not use SNESSetApplicationContext() to get the ts into SNES? > > I don't mind this, but I think it would be cleaner to change SNES coloring. > > Here you are passing into the jacobian location something more general than the jacobian context. > > Why is it more general? It's exactly the context needed to compute the Jacobian. > > Do you also pass the ts to the SNESSetFunction() context? > > Yes. > > > I philosophically like having separate contexts for each callback because it avoids imposing a certain class structure on the user. That is, if we just had XXSetApplicationContext() and all the callbacks used that, it basically forces the user to implement each callback from the same class. I think that is usually the right design, but not always, and I'd hate to place that constraint on the user. Fine we can nuke SNESSetApplicationContext() > > Now assuming that the flexibility above is good, we should not have SNES treat TS specially. Here you say SNES should not treat TS specially > When someone wraps a different loop around SNES (optimization, UQ, etc), they should be able to compose using standard interfaces. This is why I think that SNES coloring is the misbehaving component. Here I do not understand. Why is TS allowed to use the SNESSetJacobian() context slot but SNES coloring is not allowed to? What if someone wrote their own custom Compute Jacobian and wanted to use the context slot? To me that means TS is special it is the only one allowed to use that slot?? Here you are saying only TS is allowed to use the context slot. WTF? Barry

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Jed Brown 14 Aug '12

14 Aug '12

On Tue, Aug 14, 2012 at 4:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > How about just having a SNESSetTS()? Please no.

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Jed Brown 14 Aug '12

14 Aug '12

On Tue, Aug 14, 2012 at 4:19 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Ok, but then that context cannot be used for any other purpose because of > the possible conflict. Which means SNEScoloring thing must be changed. > > Why not use SNESSetApplicationContext() to get the ts into SNES? > I don't mind this, but I think it would be cleaner to change SNES coloring. > Here you are passing into the jacobian location something more general > than the jacobian context. > Why is it more general? It's exactly the context needed to compute the Jacobian. > Do you also pass the ts to the SNESSetFunction() context? > Yes. I philosophically like having separate contexts for each callback because it avoids imposing a certain class structure on the user. That is, if we just had XXSetApplicationContext() and all the callbacks used that, it basically forces the user to implement each callback from the same class. I think that is usually the right design, but not always, and I'd hate to place that constraint on the user. Now assuming that the flexibility above is good, we should not have SNES treat TS specially. When someone wraps a different loop around SNES (optimization, UQ, etc), they should be able to compose using standard interfaces. This is why I think that SNES coloring is the misbehaving component.

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Barry Smith 14 Aug '12

14 Aug '12

On Aug 14, 2012, at 5:26 PM, Peter Brune <prbrune(a)gmail.com> wrote: > > On Tue, Aug 14, 2012 at 5:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <prbrune(a)gmail.com> wrote: > Correct; the sheer amount of code using this convention makes it exceedingly painful to fix. It would be much easier to alter our internals. I'm *this* close to fugueing on TS especially and removing all PetscObjects from ctx arguments internal to PETSc. We can pass the TS around by PetscObjectCompose using the coarsen/restrict hooks. > > We could also punt with > > void *PETSC_NULL_FORCE = &knownlocation; > > I like the dogfooding of having TS pass itself as the context to SNES, but could be convinced to change my mind. > > I had to swear at it for a while and think of a way of getting it to work when I was doing the TS DMDA bindings, as you can't just set the TS as the context when you call DMDATSSetRHSJacobianLocal(DM, ... ) because you have no idea what the TS (or the appropriate SNES) is at that point. I ended up having to set it in TSSetUp. > > I'm still a bit torn on it, though. I'm not sure that any other solution will end up looking better. > > The MatFDColoring used in SNESComputeJacobianDefaultColor could be assumed to be attached to something. This could either be the coloring off the DM, A coloring attached to the matrix itself, or something else. It's not a big issue for us to remove the coloring argument, as long as the user has some ability to set a coloring in an appropriate spot. Yes it would "work" to remove the coloring context from that location to fix this one problem. But the bigger question is WHAT IS THAT LOCATION USED FOR? If the only thing that we can put into the last argument to SNESSetJacobian() or SNESSetFunction() is the TS then that is crazy and it should be removed from the user interface? How about just having a SNESSetTS()? to take the ts (you could store it as a void*). We need a diagram of all the crazy shit we do now to juggle all these contexts and then we need to understand that diagram and improve it. It is too complicated and confusing now. Could you make a stab at making such a diagram (not how it should be, but how it is now)? Thanks Barry > > - Peter >

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Peter Brune 14 Aug '12

14 Aug '12

On Tue, Aug 14, 2012 at 5:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <prbrune(a)gmail.com> wrote: > >> Correct; the sheer amount of code using this convention makes it >> exceedingly painful to fix. It would be much easier to alter our >> internals. I'm *this* close to fugueing on TS especially and removing all >> PetscObjects from ctx arguments internal to PETSc. We can pass the TS >> around by PetscObjectCompose using the coarsen/restrict hooks. > > > We could also punt with > > void *PETSC_NULL_FORCE = &knownlocation; > > I like the dogfooding of having TS pass itself as the context to SNES, but > could be convinced to change my mind. > I had to swear at it for a while and think of a way of getting it to work when I was doing the TS DMDA bindings, as you can't just set the TS as the context when you call DMDATSSetRHSJacobianLocal(DM, ... ) because you have no idea what the TS (or the appropriate SNES) is at that point. I ended up having to set it in TSSetUp. I'm still a bit torn on it, though. I'm not sure that any other solution will end up looking better. The MatFDColoring used in SNESComputeJacobianDefaultColor could be assumed to be attached to something. This could either be the coloring off the DM, A coloring attached to the matrix itself, or something else. It's not a big issue for us to remove the coloring argument, as long as the user has some ability to set a coloring in an appropriate spot. - Peter

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Barry Smith 14 Aug '12

14 Aug '12

On Aug 14, 2012, at 5:16 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <prbrune(a)gmail.com> wrote: > Correct; the sheer amount of code using this convention makes it exceedingly painful to fix. It would be much easier to alter our internals. I'm *this* close to fugueing on TS especially and removing all PetscObjects from ctx arguments internal to PETSc. We can pass the TS around by PetscObjectCompose using the coarsen/restrict hooks. > > We could also punt with > > void *PETSC_NULL_FORCE = &knownlocation; > > I like the dogfooding of having TS pass itself as the context to SNES, but could be convinced to change my mind. Ok, but then that context cannot be used for any other purpose because of the possible conflict. Which means SNEScoloring thing must be changed. Why not use SNESSetApplicationContext() to get the ts into SNES? Here you are passing into the jacobian location something more general than the jacobian context. Do you also pass the ts to the SNESSetFunction() context? Barry

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Jed Brown 14 Aug '12

14 Aug '12

On Tue, Aug 14, 2012 at 3:56 PM, Peter Brune <prbrune(a)gmail.com> wrote: > Correct; the sheer amount of code using this convention makes it > exceedingly painful to fix. It would be much easier to alter our > internals. I'm *this* close to fugueing on TS especially and removing all > PetscObjects from ctx arguments internal to PETSc. We can pass the TS > around by PetscObjectCompose using the coarsen/restrict hooks. We could also punt with void *PETSC_NULL_FORCE = &knownlocation; I like the dogfooding of having TS pass itself as the context to SNES, but could be convinced to change my mind.

1 0

Re: [petsc-dev] broken TS example related to Jacobian and coloring etc.
by Barry Smith 14 Aug '12

14 Aug '12

On Aug 14, 2012, at 5:06 PM, Peter Brune <prbrune(a)gmail.com> wrote: > On a related note, it seems that we have this wonky notion of different code paths for the same thing, in which we have SNESSetApplicationContext, DMSetApplicationContext, and then the ctx arguments to SNESSetFunction/Jacobian/GS/Picard. Perhaps we should clarify what is used for what, or remove some? Yup. Absolutely. There is the issue of mesh size specific stuff in one location and mesh independent stuff in another location. What is the status of that now? Barry > > - Peter > > On Tue, Aug 14, 2012 at 4:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Aug 14, 2012, at 4:49 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > On Tue, Aug 14, 2012 at 4:47 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Aug 14, 2012 at 3:44 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > You can, but the setter routines interpret NULL as "ignore", i.e. > > > > if (func) ctx->func = func; > > > > Does this make sense to anyone? Can we remove that if? > > > > Then we would have to revisit lots of locations and get the old value before resetting it. > > Explain? > > If the user is providing a new ComputeJacobian with SNESSetJacobian() then it seems reasonable that they are passing a new context to go with that new > ComputeJacobian function. Presumably the old context no longer has any meaning? > > My understanding is that when we pass in a function, ctx pair they are our (crude) C way of passing an object of a simple class. That is they always go together. So if the user passes a null it should replace the old value. If the old one has any meaning, what is it's meaning? Why don't we just null that value out? > > We can always try it and see what happens. > > Barry > > > > > > > > > > Passing NULL was a convenience. > > > > Ah, I see. This is crappy design. > > > > 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] broken TS example related to Jacobian and coloring etc.
by Peter Brune 14 Aug '12

14 Aug '12

On a related note, it seems that we have this wonky notion of different code paths for the same thing, in which we have SNESSetApplicationContext, DMSetApplicationContext, and then the ctx arguments to SNESSetFunction/Jacobian/GS/Picard. Perhaps we should clarify what is used for what, or remove some? - Peter On Tue, Aug 14, 2012 at 4:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Aug 14, 2012, at 4:49 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > On Tue, Aug 14, 2012 at 4:47 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Tue, Aug 14, 2012 at 3:44 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > > You can, but the setter routines interpret NULL as "ignore", i.e. > > > > if (func) ctx->func = func; > > > > Does this make sense to anyone? Can we remove that if? > > > > Then we would have to revisit lots of locations and get the old value > before resetting it. > > Explain? > > If the user is providing a new ComputeJacobian with SNESSetJacobian() > then it seems reasonable that they are passing a new context to go with > that new > ComputeJacobian function. Presumably the old context no longer has any > meaning? > > My understanding is that when we pass in a function, ctx pair they > are our (crude) C way of passing an object of a simple class. That is they > always go together. So if the user passes a null it should replace the old > value. If the old one has any meaning, what is it's meaning? Why don't we > just null that value out? > > We can always try it and see what happens. > > Barry > > > > > > > > > > Passing NULL was a convenience. > > > > Ah, I see. This is crappy design. > > > > 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] broken TS example related to Jacobian and coloring etc.
by Barry Smith 14 Aug '12

14 Aug '12

On Aug 14, 2012, at 4:49 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Tue, Aug 14, 2012 at 4:47 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Tue, Aug 14, 2012 at 3:44 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > You can, but the setter routines interpret NULL as "ignore", i.e. > > if (func) ctx->func = func; > > Does this make sense to anyone? Can we remove that if? > > Then we would have to revisit lots of locations and get the old value before resetting it. Explain? If the user is providing a new ComputeJacobian with SNESSetJacobian() then it seems reasonable that they are passing a new context to go with that new ComputeJacobian function. Presumably the old context no longer has any meaning? My understanding is that when we pass in a function, ctx pair they are our (crude) C way of passing an object of a simple class. That is they always go together. So if the user passes a null it should replace the old value. If the old one has any meaning, what is it's meaning? Why don't we just null that value out? We can always try it and see what happens. Barry > Passing NULL was a convenience. > > Ah, I see. This is crappy design. > > 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