On Fri, Jan 28, 2011 at 04:06:48PM +0100, Kristian Ølgaard wrote: > On 28 January 2011 12:53, Anders Logg <[email protected]> wrote: > > B1;2600;0cOn Fri, Jan 28, 2011 at 12:10:30PM +0100, Andre Massing wrote: > >> Den 28.01.11 12.06, skrev Anders Logg: > >> >On Fri, Jan 28, 2011 at 11:25:27AM +0100, Andre Massing wrote: > >> >>Den 28.01.11 00.30, skrev Anders Logg: > >> >>>On Thu, Jan 27, 2011 at 11:10:08PM +0100, Anders Logg wrote: > >> >>>>I would like to add factory functions in UFC, in particular > >> >>>> > >> >>>> finite_element* finite_element::create() const; > >> >>>> dof_map* dof_map::create() const; > >> >>>> > >> >>>>Are there any objections to this? It would be easy to add and easy to > >> >>>>implement in FFC. > >> >>>> > >> >>>>I need it to implement refinement of FunctionSpaces in DOLFIN where > >> >>>>fresh copies of ufc::finite_element and ufc::dof_map are needed given > >> >>>>a ufc::finite_element or ufc::dof_map. > >> >>>> > >> >>>>An alternative is to hack create_sub_foo so that it returns a copy of > >> >>>>the element/dofmap itself if the component argument 'i' is>= the > >> >>>>number of sub elements/dofmaps. > >> >>> > >> >>>I suggest we add this to UFC 1.6 and make a release next week together > >> >>>with DOLFIN 0.9.10, FFC 0.9.5 + other packages that need release. The > >> >>>sooner the better: there will be time to make bug fix releases and > >> >>>things will be tested before 1.0 in March. > >> >>> > >> >>>If there are any other things we want to add to UFC, now's a good > >> >>>time. > >> >> > >> >>What about the tabulate_tensor function taking arguments for runtime > >> >>quadrature rules, as we discussed a while ago? ATM I hacked UFC and > >> >>my generated form files having an additional function > >> >> > >> >>virtual void tabulate_tensor(double* A, > >> >> const double * const * w, > >> >> const ufc::cell& c, > >> >> dolfin::uint num_quad_points, > >> >> const double * const * coordinates, > >> >> const double * weights) const > >> >> > >> >>Such an interface would add a flexible layer for those who wants to > >> >>have some type of runtime quadrature. > >> >> > >> >>General opinons about that? > >> > > >> >The question is when this function will be implemented by form > >> >compilers. > >> > > >> >We could add it and let FFC generate an empty function with throws an > >> >exception. > >> > >> So I would like to delegate the following questions to the FFC > >> experts: How difficult would it be to generate code for that? > > > > I assume it would not be very difficult, but it would need to be > > implemented by Kristian (as part of the quadrature code generator) and > > he might have other things to do at the moment. > > How difficult it will be depend on what we want the code to do. > > 1) > If the quad coordinates (arguments) are defined on the reference element, we > can > implement https://blueprints.launchpad.net/ffc/+spec/evaluate-basis-reference > and have a small block of code > in the beginning of tabulate_tensor which fills the Psi_* tables with > basis function values (opposed to tabulating them > at FFC compile time which is done now). > Then remainder of the code will not need to change, so this should be > relatively simple. > > 2) > If the quad coordinates are defined on the physical element, we can > have a small piece of code which maps them to the reference element > and proceed with 1). This is of course a little more work, but maybe > this is the preferred interface (physical coordinates)?
I think (2) is the best option. If we find out there's a more efficient way to implement, we can optimize it later. -- Anders > 3) > If the quad coordinates are defined on the physical element, we call > the evaluate_basis* functions as is, but then we need to generate > different code to evaluate the element tensor since we get the 'real' > v.dx(0) values (no need to map using K_00 etc.). > This approach will require the most work. > > I'm not sure which one will result in the best runtime performance > since a mapping or coordinates will take place somewhere in the code > for all 3 approaches. However, since the current evaluate_basis > involves a mapping physical-->reference-->physical I suspect it to be > the slowest. > > Or maybe you had something different in mind? > > Kristian > > > > > _______________________________________________ > > 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/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
