dolfin team mailing list archive

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

On 30 May 2011 19:24, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> On Monday May 30 2011 04:33:29 Martin Sandve Alnæs wrote:
>> On 30 May 2011 12:51, Marie E. Rognes <meg@xxxxxxxxx> wrote:
>> > On 05/30/2011 11:26 AM, Martin Sandve Alnæs wrote:
>> >> Since this feature implementation relies on modifying immutable objects,
>> >> I'm not the least surprised you're getting problems. The bug is not that
>> >> dolfin subdomains are not passed with forms, but that they are allowed
>> >> to be attached in the first place on an existing and assumed immutable
>> >> form object.
>> >
>> > Yes...
>> >
>> >> The short term solution to this bug is to revert pydolfin back to
>> >> providing subdomains as arguments to assemble and variationalproblem
>> >> where they belong, instead of attaching them to forms. I think this
>> >> should be done for fenics 1.0 if this bug is a problem.
>> >>
>> >> Improvements to the language for expressing subdomains of various kinds
>> >> is in the design stage, but that won't happen before the summer.
>> >
>> > Specifications of subdomain does not belong as arguments to assemble and
>> > variational problem. If you have a form
>> >
>> >        L = g*v*dG
>> >
>> > where G is a part of a boundary (In semi-math, semi-UFL notation), G
>> > should be related to the form. Not to the matrix resulting from the
>> > assembly of the form.
>> >
>> > (cc to DOLFIN since the below involves DOLFIN mainly)
>> >
>> > The interface to VariationalProblem
>> >
>> >        VariationalProblem(., ., bcs, exterior_facet_domains,
>> > interior_facet_domains, cell_facet_domains)
>> >
>> > was rather suboptimal because it assumed implicitly that the bilinear and
>> > the linear form were defined over the same subdomains. That in,
>> > combination with dx = dx(0) etc, is highly bugprone.
>> >
>> > I care of course because if you want to use the same patent for an
>> > variational problem with automatic adaptivity, and take care of the
>> > above, the required  input will look something like this
>> >
>> >        VariationalProblem(., ., bcs,
>> >                        primal_bilinear_exterior_facet_domains,
>> >                        primal_bilinear_interior_facet_domains,
>> >                        primal_bilinear_cell_domains,
>> >                        primal_linear_exterior_facet_domains,
>> >                        primal_linear_interior_facet_domains,
>> >                        primal_linear_cell_domains,
>> >                        goal_exterior_facet_domains,
>> >                        goal_interior_facet_domains,
>> >                        goal_cell_domains)
>> >
>> > which I can't live with.
>> >
>> > The Coefficient/Function magic must involve some of the same issues as
>> > this. I imagine that a similar way of fixing it should be possible.
>>
>> I'm not saying it can't be implemented, only that it can't
>> be implemented well within the FEniCS 1.0 timeframe, and
>> that fixing the current solution will lead down a bad path.
>> I'm hoping for a much better solution later this year, but
>> that will require some design work first.
>>
>> An alternative short term approach could be to attach the data to the
>> measures.
>>
>> dxp = dx(cell_domains=primal_cell_domains)
>> dsp = ds(exterior_facet_domains=primal_exterior_facet_domains)
>> L = g*dxp(1) + f*dsp(0)
>>
>> and making sure that this data follows measure objects around.
>> They can then be collected in ufl preprocess just like functions
>> and function spaces. Then the connection between the
>> meshfunction and the dx(i) index looks more explicit as well.
>
> I like that syntax. I guess we only allow one type of cell integral within one
> form?
>
> My conserns regards changing the subdomains after creating the form, as this
> can be a convinient way of reusing a compiled form. But I guess letting domain
> arguments in assemble override domains in the form should fix that.

Yes, that would be exactly how it works with coefficients today.

Martin