dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jan 28, 2011 at 04:06:48PM +0100, Kristian Ølgaard wrote:
> On 28 January 2011 12:53, Anders Logg <logg@xxxxxxxxx> 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     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
> >