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. 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
