On 28 April 2011 23:17, Anders Logg <[email protected]> wrote: > On Thu, Apr 28, 2011 at 12:55:02PM +0200, Martin Sandve Alnæs wrote: >> On 28 April 2011 11:45, Garth N. Wells <[email protected]> wrote: >> > >> > >> > On 27/04/11 20:50, Johan Hake wrote: >> >> On Wednesday April 27 2011 12:45:46 Martin Sandve Alnæs wrote: >> >>> On 27 April 2011 21:34, Anders Logg <[email protected]> wrote: >> >>>> On Wed, Apr 27, 2011 at 09:30:08PM +0200, Martin Sandve Alnæs wrote: >> >>>>> 2011/4/27 Johan Hake <[email protected]> >> >>>>> >> >>>>> On Wednesday April 27 2011 12:03:56 Martin Sandve Aln s wrote: >> >>>>> > On 27 April 2011 19:07, Garth N. Wells <[email protected]> wrote: >> >>>>> > > I'm starting here a new thread on how to deal with the recent >> >>>> >> >>>> change in >> >>>> >> >>>>> > > UFL that has broken a good number of DOLFIN demos. The previous >> >>>> >> >>>> thread >> >>>> >> >>>>> > > meandered and got side-tracked. >> >>>>> > > >> >>>>> > > The framework in we need to operate is: >> >>>>> > > >> >>>>> > > A. UFL will not allow forms to be modified post-construction. >> >>>>> > > >> >>>>> > > B. It should be relatively easy to replace ufl.Coefficients in >> >>>>> > > a >> >>>> >> >>>> form >> >>>> >> >>>>> > > and return a new form. >> >>>>> > > >> >>>>> > > C. The issue with replacing ufl.Coefficients is that we lose >> >>>> >> >>>> DOLFIN >> >>>> >> >>>>> data >> >>>>> >> >>>>> > > (like the eval() functions) associated with the removed >> >>>> >> >>>> coefficients. >> >>>> >> >>>>> > > I'll kick off with the obvious solution: >> >>>>> > > >> >>>>> > > 1. Require that all DOLFIN Expressions are associated with a >> >>>>> > > ufl.FiniteElement. >> >>>>> > > >> >>>>> > > Other solutions? >> >>>>> > > >> >>>>> > > Garth >> >>>>> > >> >>>>> > 2. At the stage when ffc calls ufl.preprocess, or even in >> >>>>> >> >>>>> ufl.preprocess, >> >>>>> >> >>>>> > let the preprocessed form contain ufl Coefficients with new >> >>>> >> >>>> elements in >> >>>> >> >>>>> > place of the dolfin.Expressions. This is similar to the >> >>>> >> >>>> replacements done >> >>>> >> >>>>> > for renumbering of Coefficients, and could either be done >> >>>> >> >>>> simultaneously >> >>>> >> >>>>> or >> >>>>> >> >>>>> > as an additional step. The original Form and Expression objects >> >>>> >> >>>> will be >> >>>> >> >>>>> > untouched, and the preprocessed form will be fine. >> >>>>> >> >>>>> + >> >>>>> >> >>>>> However, setting cell and degree is done during analysis and relies >> >>>> >> >>>> on >> >>>> >> >>>>> form_data. The form is also preprocessed when the form_data is >> >>>> >> >>>> extracted. >> >>>> >> >>>>> This >> >>>>> means that for the preprocessed form to get correct signature, cell >> >>>> >> >>>> and >> >>>> >> >>>>> degrees being set, we need to break up the logic. >> >>>>> >> >>>>> 1) extract form_data >> >>>>> 2) set degree and cell >> >>>>> 3) genererate preprocessed form >> >>>>> >> >>>>> Lets figure out the exact algorithm if we need it. It could perhaps be >> >>>>> integrated better with preprocess. Or it might be better to extract >> >>>>> just >> >>>> >> >>>> the >> >>>> >> >>>>> information needed to determine degree and cell first, and pass the >> >>>> >> >>>> element >> >>>> >> >>>>> replacements to preprocess. >> >>>> >> >>>> That's what I suggested in an earlier mail. Preprocess already gets >> >>>> common_cell. We could also figure out common_degree before calling >> >>>> preprocess but that requires getting the data stored in >> >>>> form_data.sub_elements. >> >>> >> >>> Extracting all sub elements from a form before preprocessing should be >> >>> easy >> >>> and efficient. >> >>> >> >>> I assume it's still possible to construct an Expression with a specific >> >>> FunctionSpace? >> >> >> >> Yes. >> >> >> > >> > So it seems we've reached a solution that won't require any changes to >> > DOLFIN, and only minimal changes to FFC. The story is: >> > >> > 1. UFL will permit elements without a cell and without a degree. The >> > will leads an error for some operations, like grad and div. >> > >> > 2. Add a function to UFL to extract all sub-elements from a form. > > The functionality is already there since this is already extracted in > the preprocess function. > >> > 3. Add 'unspecified_elements=[]' (perhaps a dict?) to the argument list >> > of ufl.algorithms.preprocess. > > Not sure if this is needed. > >> > 4. For coefficients with incomplete elements, preprocess will replace >> > these with coefficients based on elements from the list >> > 'unspecified_elements'. The new form will be the 'preprocessed form'. >> > >> > Is that it? Anything else? >> > >> > Garth >> >> I think that should be all. > > I think all we need to do (in FFC) is to > > 1. extract the minimal amount of data we need to decide the undecided > degree and cell (essentially building the list of elements) > > 2. select the degree and cell (as we do today)
I've spent quite some time in ffc.analysis lately and I'm wondering if we're too strict when enforcing common_degree, common representation and common quadrature scheme on all sub domains and integral types in a form. I don't see a problem in varying all three in: L = f0*v*dx(0) + f1*v*dx(1) + f2*v*ds if fn were coefficients with no degree. > > 3. pass the degree and cell to compute_form_data (and thus to > preprocess) > > 4. let preprocess generate the preprocessed form with any "?" replaced > by common_cell and common_degree > > Any problems with the above approach? Remember to include 'quadrature_scheme' in all steps. Kristian > -- > Anders > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : [email protected] Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
