2008/6/10 Anders Logg <[EMAIL PROTECTED]>: > On Mon, Jun 09, 2008 at 10:31:01AM +0200, Martin Sandve Alnæs wrote: >> 2008/6/8 Anders Logg <[EMAIL PROTECTED]>: >> > On Fri, Jun 06, 2008 at 02:30:12PM +0200, Martin Sandve Alnæs wrote: >> >> 2008/6/6 Anders Logg <[EMAIL PROTECTED]>: >> >> > On Fri, Jun 06, 2008 at 01:40:15PM +0200, Martin Sandve Alnæs wrote: >> >> >> 2008/6/6 Johan Hake <[EMAIL PROTECTED]>: >> >> >> > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
