On Thu, May 7, 2009 at 10:34 PM, Garth N. Wells <[email protected]> wrote: > > > Martin Sandve Alnæs wrote: >> >> On Thu, May 7, 2009 at 9:43 PM, Garth N. Wells <[email protected]> wrote: >>> >>> Anders Logg wrote: >>>> >>>> I've added some of the requested features to the parameter system, >>>> some pushed and some sitting here in a local repository. But the >>>> current design makes it a pain to add new features. A single change >>>> will make it necessary to add a function in at least 5 different >>>> classes. >>>> >>>> So I'm thinking of reimplementing and simplifying the parameter >>>> system. I think I know how to make it simpler. >>>> >>>> But before I do that, does anyone have opinions on the >>>> design/implementation? Is there any third-party library that we >>>> could/should use (maybe something in boost)? >>>> >>> This could be interesting: >>> >>> http://www.boost.org/doc/libs/1_39_0/doc/html/program_options.html >>> >>> >>> While we're on the topic of boost, this is neat >>> >>> http://www.boost.org/doc/libs/1_39_0/libs/parameter/doc/html/index.html >>> >>> It addresses the problem we had with attaching functions to forms - >>> arguments can associated with a name. At first glance it allows >>> >>> BilinearForm a(V, V, "f", f, "h", h); >>> >>> or >>> >>> BilinearForm a(V, V, "h", h, "f", f); >>> >>> so the user doesn't need to worry about the order of the arguments. >> >> We don't have that problem with code generated by dolfin_utils.wrappers: >> >> BilinearForm a(V, V): >> a.f = f; >> a.h = h; >> > > It was a problem and the above approach is how we resolved it. It doesn't > however work well for mixed elements. This still needs to be resolved. Are
I see, for example: u, p = Functions(TH) would make both u and p Indexed instances so their names won't be found. The workaround for now is to use up = Function(TH) u, p = split(up) which will properly name the mixed function "up" (not u and p). I suspect better subfunction support in both DOLFIN and UFL is needed for this and other important mixed element features. > there names which could be used for a Function in Python (like 'default') > which are not legal in C++? Good point. But probably not a big problem. We could add checks for C++ language keywords in dolfin_utils to give proper error messages. >> or: >> >> CoefficientSet coeffs; >> coeffs.u = u; >> coeffs.dt = dt; >> coeffs.beta = beta; >> BilinearForm a(V, V, coeffs); >> LinearForm L(V, coeffs); >> > > . . . which looks like it hasn't been fully implemented. It would fix the > problem that in order to do > > Form* my_form = new MyForm(V, V); > my_form.a = a; > > we had to keep the old-style constructor in the generated code. CoefficientSet works fine for me, but I don't think FFC uses dolfin_utils yet? Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
