Subject: [Fenics-ufc] Adding factory functions in UFC

From: Anders Logg <[email-masked]>
Date: Thu, 27 Jan 2011 23:10:08 +0100

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.

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Jan 2011 00:30:54 +0100

> 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.

--
Anders

---

From: Andre Massing <[email-masked]>
Date: Fri, 28 Jan 2011 11:25:27 +0100

Den 28.01.11 00.30, skrev Anders Logg:
>> the element/dofmap itself if the component argument 'i' is>= the

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?

Cheers,
Andre

>
> --
> Anders
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

-- 
André Massing       		email: [email-masked]
Ph.D. student			mobile: +47 469 57 401
Simula Research Laboratory
NO-1367 Fornebu, Norway

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Jan 2011 12:06:52 +0100

On Fri, Jan 28, 2011 at 11:25:27AM +0100, Andre Massing wrote:
> quadrature rules, as we discussed a while ago? ATM I hacked UFC and
> my generated form files having an additional function
>
> Such an interface would add a flexible layer for those who wants to
> have some type of runtime quadrature.
>

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.

--
Anders

---

From: Andre Massing <[email-masked]>
Date: Fri, 28 Jan 2011 12:10:30 +0100

> We could add it and let FFC generate an empty function with throws an

So I would like to delegate the following questions to the FFC experts: 
How difficult would it be to generate code for that?

--
Andre

---

From: Mehdi Nikbakht <[email-masked]>
Date: Fri, 28 Jan 2011 12:33:46 +0100

> General opinons about that?

Although this makes life easier for the case that we have to compute
quadrature rule in the run-time, but the current interface can also
handle this problem.  You can derive a class form ufc::foo_integrals and
pass object containing new gauss quadrature rule to its constructor as
we do for partition of unity method. 

Mehdi

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Jan 2011 12:53:13 +0100

B1;2600;0cOn Fri, Jan 28, 2011 at 12:10:30PM +0100, Andre Massing wrote:
> 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.

--
Anders

---

From: Kristian Ølgaard <[email-masked]>
Date: Fri, 28 Jan 2011 16:06:48 +0100

> 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)?

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

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Jan 2011 16:47:23 +0100

> 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