On Thu, May 07, 2009 at 10:53:16PM +0200, Martin Sandve Alnæs wrote: > 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
No, but it's on the TODO list. Another thing on the TODO list is load_ufl_file(). -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
