dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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 <gnw20@xxxxxxxxx> wrote:
> >
> >
> > Martin Sandve Alnæs wrote:
> >>
> >> On Thu, May 7, 2009 at 9:43 PM, Garth N. Wells <gnw20@xxxxxxxxx> 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

Attachment: signature.asc
Description: Digital signature