dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/6/8 Anders Logg <logg@xxxxxxxxx>:
> On Fri, Jun 06, 2008 at 02:30:12PM +0200, Martin Sandve Alnæs wrote:
>> 2008/6/6 Anders Logg <logg@xxxxxxxxx>:
>> > On Fri, Jun 06, 2008 at 01:40:15PM +0200, Martin Sandve Alnæs wrote:
>> >> 2008/6/6 Johan Hake <hake@xxxxxxxxx>:
>> >> > On Friday 06 June 2008 13:19:54 Martin Sandve Alnæs wrote:
>> >> >> Say I have a form
>> >> >>
>> >> >> a = u*v*dx + f*v*ds
>> >> >
>> >> > Isn't it possible to do
>> >> >
>> >> > a = u*v*dx + f0*v*ds0 + f1*v*ds1
>> >> >
>> >> > Johan
>> >>
>> >> Sure, but my forms are more complicated than that,
>> >> and it would add to the compilation time for the forms.
>> >
>> > Well, there are two options:
>> >
>> > 1. Use two subdomains and two Functions, one on each domain.
>> >
>> > 2. Use one subdomain and one Function for the whole domain.
>> >
>> > If you think (1) costs too much, then you need to define your Function
>> > in such a way that it is takes care of the different domains. I guess
>> > it should be possible to create one Function f which owns two
>> > Functions f0 and f1, overload interpolate() for f and there send the
>> > data on to either f0 or f1.
>> >
>> > We could add an interface for this, something like
>> >
>> >  f = Function([f0, f1, f2, ...], sub_domains)
>> >
>> > but it seems overly complicated and specific.
>>
>> Yes, it quickly becomes very complicated.
>>
>> Another solution could be to add an argument
>> "bool zero_tensor=true" next to reset_tensor in
>> assemble functions, define a separate form
>> with just the boundary integral, and call assemble
>> repeatedly for each coefficient set with zero_tensor=false.
>> This would be much efficient if iteration directly
>> over a subdomain was possible, which will require
>> the "inverse" of a MeshFunction.
>
> I don't understand why this would be faster than just defining the form
>
>  a = f0*v*ds0 + f1*v*ds1
>
> (if we assume that we also here have access to the inverse of the
> MeshFunction).
>
> --
> Anders

That's because it won't :)

(Except perhaps for the additional restriction of more coefficient
functions to each local cell, since the form gets a larger coefficient
list).

My point was to _avoid_ having to define different forms for different
sets of boundary conditions. I want to define my forms one place and
reuse them in several applications, and these test cases may have
different combinations of boundary conditions.

If subdomains are specified with MeshFunctions which gives the most
freedom (and is completely necessary for nontrivial geometries!), I'll
have no way to select between functions in my own Function subclass,
and I have no way to pass different functions for different
subdomains.

--
Martin