dolfin team mailing list archive

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

2008/6/10 Anders Logg <logg@xxxxxxxxx>:
> On Mon, Jun 09, 2008 at 10:31:01AM +0200, Martin Sandve Alnæs wrote:
>> 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).
>> >
>>
>> 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.
>
> It would be entirely possible to add the current sub domain as a
> member to Function (like we do with the cell) so that a Function could
> return different things depending on the sub domain (not only x).
>
> The input to the eval() function is only the current coordinate x, but
> eval() may actually depend on other things. This is how we've
> implemented the functions in SpecialFunction.h, like MeshSize.
>
> --
> Anders

Why not take the cell as input to eval like with do with ufc::function?
I don't like sneaking arguments to a function in the backdoor like this.

Anyway, with cell information available, it's entirely possible to implement
my own Function subclass which knows about my MeshFunctions with
whatever kind of logic I want to use for evaluating my function.

So I may construct one MeshFunction which I give to DOLFIN which
tells the assembler which integral to use where, and one MeshFunction
which I pass to my own Function, which MyFunction::eval can look up
to select from "sub-sub-domains" or whatever.

So then there's really no problem!
(Unless there are other uses for assembling
only the boundary contribution of a given form).

--
Martin