On Mon, Jun 13, 2011 at 09:24:43AM -0700, Johan Hake wrote: > On Monday June 13 2011 08:09:36 Anders Logg wrote: > > On Mon, Jun 13, 2011 at 05:04:53PM +0200, Kristian Ølgaard wrote: > > > On 13 June 2011 16:37, Anders Logg <l...@simula.no> wrote: > > > > On Mon, Jun 13, 2011 at 03:30:22PM +0100, Garth N. Wells wrote: > > > >> On 13/06/11 14:54, Anders Logg wrote: > > > >> > On Mon, Jun 13, 2011 at 02:42:57PM +0100, Garth N. Wells wrote: > > > >> >> On 13/06/11 14:10, Anders Logg wrote: > > > >> >>> On Mon, Jun 13, 2011 at 01:09:20PM +0100, Garth N. Wells wrote: > > > >> >>>> On 13/06/11 12:51, Marie E. Rognes wrote: > > > >> >>>>> On 06/13/2011 10:03 AM, Garth N. Wells wrote: > > > >> >>>>>> On 12/06/11 22:54, Anders Logg wrote: > > > >> >>>>>>> On Wed, Jun 08, 2011 at 11:47:10PM +0200, Anders Logg wrote: > > > >> >>>>>>>> I'm on a cell phone and can't engage in any discussions but I > > > >> >>>>>>>> just want to throw something in. Marie and I discussed at > > > >> >>>>>>>> some point another option which is to write everything as F > > > >> >>>>>>>> = 0 and let UFL compute J even for linear problems. J would > > > >> >>>>>>>> be a optional variable. Then we could have a common > > > >> >>>>>>>> interface and also a common solver. > > > >> >>>>>> > > > >> >>>>>> I think that this would be a nice option, but I don't think > > > >> >>>>>> that it can work without a more elaborate interface than just > > > >> >>>>>> > > > >> >>>>>> pde = VariationalProblem(F, bcs) > > > >> >>>>>> > > > >> >>>>>> because UFL cannot know which coefficient in a form is unknown, > > > >> >>>>>> and therefore which function to compute the linearisation with > > > >> >>>>>> respect to. Moreover, > > > >> >>>>>> > > > >> >>>>>> - UFL cannot compute the linearisation for all forms > > > >> >>>>>> - In some cases it's not desirable to let UFL do the > > > >> >>>>>> linearisastion > > > >> >>>>> > > > >> >>>>> Some specific responses: First, the moment solve is called (with > > > >> >>>>> a coefficient), which function to compute the linearization > > > >> >>>>> with respect to, is known. > > > >> >>>> > > > >> >>>> Which means that the simple call > > > >> >>>> > > > >> >>>> u = pde.solve() > > > >> >>>> > > > >> >>>> will not be possible. > > > >> >>> > > > >> >>> Why do you call it "pde" and not "problem"? > > > >> >> > > > >> >> The name has nothing to do with the discussion. > > > >> > > > > >> > This discussion is about just that: which names to use. > > > >> > > > >> Yes, the class name, but not what I dream up for an object: > > > >> > > > >> xxx = FooVariationalFoo(....) > > > >> > > > >> u = xxx.solve() > > > >> > > > >> >> I could call it xxx. > > > >> >> > > > >> >>> Once upon a time it was > > > >> >>> called that, so yet another option would be > > > >> >>> > > > >> >>> LinearPDE > > > >> >>> NonlinearPDE > > > >> >>> > > > >> >>> which is short enough. > > > >> >>> > > > >> >>> What speaks against this, and likely one of the reasons we > > > >> >>> switched to VariationProblem is that the above looks weird when > > > >> >>> used to define a projection which does not involve any > > > >> >>> derivatives. > > > >> >>> > > > >> >>> And here's yet another option: > > > >> >>> > > > >> >>> LinearProblem > > > >> >>> NonlinearProblem > > > >> >> > > > >> >> This looks ok, but it's a secondary issue for if we agree that we > > > >> >> should have separate classes for linear and nonlinear equations > > > >> >> (or have we agreed this?). > > > >> > > > > >> > Not yet. I think we should settle first one whether we want > > > >> > > > > >> > 1. a common class for (non)linear problems > > > >> > 2. two classes > > > >> > > > >> Agree. I strongly support 2. > > > >> > > > >> What I oppose vehemently is distinguishing between linear and > > > >> nonlinear by the order of the lhs/rhs arguments. As pointed out by > > > >> Martin, the line > > > >> > > > >> VariationalProblem(C, D) > > > >> > > > >> says nothing to the reader about the type of problem, and it has led > > > >> to confusion. > > > >> > > > >> The code > > > >> > > > >> LinearVariationalProblem(C, D) > > > >> > > > >> or > > > >> > > > >> NonlinearVariationalProblem(C, D) > > > >> > > > >> (class names subject to change) are clear, and the code can test for > > > >> the arity of C and D and throw an error if the order is mixed up. > > > > > > > > I agree with this. It's important that we can check input arguments. > > > > > > > > What are the votes in favor of either of these two options? > > > > > > > > 1. One class VariationalProblem for all (non)linear problems. > > > > > > > > 2. Two classes LinearProblem and NonlinearProblem. > > 2 gets my vote. > > > > I vote for 2 with the arguments of readability/debugging as Martin and > > > Garth have promoted, > > > and like Garth I also don't think that one class should try to do > > > everything. > > > > ok. Note the new choice of names LinearProblem/NonlinearProblem > > (without Variational). > > > > This would also let us keep the VariationalProblem class and issue a > > suitable error message that it has been replaced by those other > > classes. > > Sounds good!
Further comments? What does Marie say? -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
