| Thread Previous • Date Previous • Date Next • Thread Next |
>> > I think we should go with suggestion #2 and/or #3 (slicing). Since >> > functions are associated with a finite element (in FFC for example), >> > the association needs to be stored. >> >> Part of the problem with the current design is that not all Functions >> should be associated with a particular FiniteElement. A user-defined >> Function that just implements operator() (const Point& p) could be >> reused in different forms and be associated with different >> FiniteElements in each form (like in Andy's case). > > I think that Functions defined by an expression and not associated with an > element are sufficiently different to make them separate sub-class. > Sub-classes > of functions seems to me a natural approach and affords flexibilty for > future > (as yet unknown) functionality. I think the sub-class model is good since it would make a Function object separate from the Form object. In the assembly it makes sense to involve the Form object (to get element), but we might wanna use a Function in other situations, like postprocessing for example, where it does not make sense to include Form in the function call. We had this design previously in DOLFIN, and it worked ok. >> Part of the reason I would like to break out the functionality in >> subclasses is to be able to make some simplications. The logic of the >> current implementation of Function is nontrivial. >> >> If we make DiscreteFunction a separate subclass, it would be easier >> to follow the logic and get it right. >> >> > Functions are used in the inner assembly loop, so they need to be as >> > close to optimal as possible. I don't think we can afford to make them >> > too abstract. >> >> I don't think that's much of an issue, as long as the stuff we do >> inside the calls to Function::foo() dominates the function call. >> >> The current implementation also needs to check which type of Function >> is used so we would be able to replace some if-statements with >> subclassing. I agree that efficiency in the assembly is critical. But I'm not sure how the two approaches differ in this respect? >> > If we want to make DOLFIN very user-friendly later, I think it's >> > better to add a layer in Python on top of PyDOLFIN (since C++ isn't >> > very user-friendly in the first place). Then we don't need to be >> > optimal at all times, since the possibility exists of using the >> > underlying C++ interface directly. >> >> That's also an option. Yes, this is a good point. /Johan
| Thread Previous • Date Previous • Date Next • Thread Next |
