Subject: [FIAT-dev] numbering, etc

From: "Robert Kirby" <[email-masked]>
Date: Tue, 22 Jan 2008 11:48:23 -0600

Hi, with all of the difficulties regarding (0,1) vs (-1,1) and handling
different kinds of reference orderings,we seem to have scattered reference
element info in about 3 different modules.  It might be a good time
to refactor some of this.  I propose having a "ReferenceElement" class that
will encapsulate the
geometry and topology of the particular reference elements, parametrizing
the rest of FIAT on top of
this.  This will make FIAT much cleaner and more extensible for people who
want other orderings.

Rob

---

From: Anders Logg <[email-masked]>
Date: Tue, 22 Jan 2008 18:58:39 +0100

On Tue, Jan 22, 2008 at 11:48:23AM -0600, Robert Kirby wrote:
> different kinds of reference orderings,
> we seem to have scattered reference element info in about 3 different modules.
>  It might be a good time
> geometry and topology of the particular reference elements, parametrizing the
> rest of FIAT on top of
> this.  This will make FIAT much cleaner and more extensible for people who want
> other orderings.
> 
> Rob

Is this instead of or in addition to the transformed spaces?

If instead of, this is what we started out with (trying to parametrize
FIAT over the reference element).

At some point, we may also want to think of having some common module
or interface for finite elements. Now, each of FIAT, SyFi, FFC, UFC
and UFL have a FiniteElement class of their own, some of which are
wrappers for the others.

-- 
Anders

---

From: "Robert Kirby" <[email-masked]>
Date: Tue, 22 Jan 2008 12:04:15 -0600

This should replace the transformed spaces.  FIAT's client would say that
they want a 5th order Lagrange over such and such a reference element.  I
would provide the "old" reference element and the UFC reference element as
particular cases.
We were facing problems in both geometry and topology in the FFC/FIAT
hookup.  The numbering.py module attempted to solve the topology problem and
the transformedspace.py module the geometry problem.

I think we should be able to have a single point of entry for all the
geometry & topology information about reference elements in FIAT.

On Jan 22, 2008 11:58 AM, Anders Logg <[email-masked]> wrote:

> _______________________________________________
> FIAT-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/fiat-dev
>

---

From: "Marie E. Rognes" <[email-masked]>
Date: Tue, 22 Jan 2008 19:17:25 +0100

Robert Kirby wrote:
> This should replace the transformed spaces.  FIAT's client would say 
> that they want a 5th order Lagrange over such and such a reference 
> element.  I would provide the "old" reference element and the UFC 
> reference element as particular cases.
>

How does this differ from the setup before the transformed spaces?

--
Marie
 
> hookup.  The numbering.py module attempted to solve the topology 
> problem and the transformedspace.py module the geometry problem.
>
> On Jan 22, 2008 11:58 AM, Anders Logg <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Robert Kirby" <[email-masked]>
Date: Tue, 22 Jan 2008 12:23:29 -0600

1.) It will get rid of all of the if numbering == "UFC" type code that has
been inserted into FIAT.   These ifs are difficult to maintain and have
crept into several parts of the code.2.) Within FFC, you will instantiate a
FIAT "ReferenceElement" such as
FIAT.reference_element.UFCTriangle() and pass that to the constructor for
the particular finite element.  Inside, it will automatically handle the
transformations and ordering.

---

From: Anders Logg <[email-masked]>
Date: Tue, 22 Jan 2008 20:26:03 +0100

On Tue, Jan 22, 2008 at 12:23:29PM -0600, Robert Kirby wrote:
> 1.) It will get rid of all of the if numbering == "UFC" type code that has been
> inserted into FIAT.   These ifs are difficult to maintain and have crept into
> several parts of the code.
> 2.) Within FFC, you will instantiate a FIAT "ReferenceElement" such as 
> FIAT.reference_element.UFCTriangle() and pass that to the constructor for the
> particular finite element.  Inside, it will automatically handle the

Sounds excellent!

Maybe it's time for a release soon since all the new spaces seem to
work now (BDM, BDFM, RT, Nedelec) so perhaps this could wait until
after the release?

We still haven't implemented the code generation for evaluate_dof
which depends on getting dof information from FIAT (which will enable
us to set essential BCs for these elements) but depending on how that
goes, it could be included before or after the release. (?)

-- 
Anders

> On Jan 22, 2008 12:17 PM, Marie E. Rognes < [email-masked]> wrote:
> 
>     Robert Kirby wrote:
>     > <mailto:[email-masked] >> wrote:
>     >

---

From: "Robert Kirby" <[email-masked]>
Date: Tue, 22 Jan 2008 14:03:46 -0600

I'm not doing this in the main repository yet.  While I'm doing some major
surgery, we can talk some more about how functionals can be improved as
well.
Rob

On Jan 22, 2008 1:26 PM, Anders Logg <[email-masked]> wrote:

> >     >     > Hi, with all of the difficulties regarding (0,1) vs (-1,1)
> and
> >     >     handling
> >     >     > to refactor some of this.  I propose having a
> "ReferenceElement"
> >     >     class that
> >     >     > will encapsulate the
> >     >     > this.  This will make FIAT much cleaner and more extensible
> for
> >     >     people who want
> >     >     > other orderings.
> >     >     >
> >     >     > Rob
> >     >