On Monday May 30 2011 13:48:34 Martin Sandve Alnæs wrote: > On 30 May 2011 22:40, Johan Hake <johan.h...@gmail.com> wrote: > > On Monday May 30 2011 13:33:29 Marie E. Rognes wrote: > >> On 05/30/2011 07:36 PM, Anders Logg wrote: > >> > On Mon, May 30, 2011 at 10:24:48AM -0700, Johan Hake 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? > >> > >> I don't see how this last guess would follow from the above. Why? > > > > My guess was that: > > > > dxp = dx(cell_domains=primal_cell_domains) > > L = g*dxp(1) + f*dxp(2) > > > > should work as previously. > > > > But: > > > > dxp = dx(cell_domains=primal_cell_domains) > > dxs = dx(cell_domains=second_cell_domains) > > L = g*dxp(1) + f*dxs(2) > > > > should not. > > > > Johan > > I did not really think about that at all, but that shouldn't be a > necessary limitation.
For UFL and ufc this wont matter much I guess, but how on earth should this get propagated to DOLFIN? Johan > > 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
