Anders Logg wrote: > On Thu, Sep 04, 2008 at 02:06:40PM -0400, Shawn Walker wrote: >> Hello, again. I looked at the interpolate routine, and that may be the >> way to go. Most of the arguments are already available in the >> UFCCell::init routine. however, it does require a 'finite_element' input, >> which would correspond to whatever the higher mesh Function is. Here I >> have posted the interpolate call. >> >> /// Interpolate function to finite element space on cell >> void interpolate(real* coefficients, >> const ufc::cell& ufc_cell, >> const ufc::finite_element& finite_element, >> Cell& cell, int facet = -1); >> >> Anyway, should we have another variable under MeshGeometry that is a >> 'finite_element' variable? or put this only in UFCCell::init? I just >> wanted to get an opinion on this. >> >> - Shawn > > A Function should always know its finite element so this demonstrates > that something is wrong with the current design of Function and > DiscreteFunction. > > The Function XML format needs to contain the element and a > DiscreteFunction must always know its finite element. > > We've been discussing cleaning up the Function class design for a > while (and the DofMap) so now may be the time. I don't have much time > to spend right now, but I'll open a new thread and hopefully we can > have a little discussion leading up to an improved design. >
Before getting stuck into Function and DofMap, I would like to see some conclusions on how we intend to approach parallelism because this will be a major design consideration for Function and DofMap. Garth > > > ------------------------------------------------------------------------ > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
