On 30 May 2011 19:24, Johan Hake <johan.h...@gmail.com> wrote: > On Monday May 30 2011 04:33:29 Martin Sandve Alnæs wrote: >> On 30 May 2011 12:51, Marie E. Rognes <m...@simula.no> 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
