FIAT currently has

• a continuous Raviart-Thomas element,
• a discontinuous Raviart-Thomas element, and
• a generic DiscontinuousElement (UFL term: BrokenElement) that makes any given element discontinuous.

Is (was) the discontinuous Raviart-Thomas element any different than a "discontinuized" Raviart-Thomas element? If not, perhaps it is better to remove the discontinuous Raviart-Thomas element, especially in light of the recent changes to RT nodes, which would make DRT unnecessarily different.

Such a removal would, of course, necessitate a small change to the form compiler's FIAT interface, so that the "Discontinuous Raviart-Thomas" family name be translated to DiscontinuousElement(RaviartThomas(cell, degree, variant)).

Original report by Nico Schlömer (Bitbucket: nschloe, GitHub: nschloe).

Lines like https://bitbucket.org/fenics-project/fiat/src/550063505522529f9a6c3875007a3c0277d819f0/FIAT/newdubiner.py?at=master#cl-145

results[0,:] = 1.0 + apts[:,0]-apts[:,0]+apts[:,1]-apts[:,1]+apts[:,2]-apts[:,2]

look buggy

0 == apts[:,0]-apts[:,0] + apts[:,1]-apts[:,1] + apts[:,2]-apts[:,2]

There are more of the same kind, e.g., https://bitbucket.org/fenics-project/fiat/src/550063505522529f9a6c3875007a3c0277d819f0/FIAT/expansions.py?at=master#cl-143.

Original report by Garth N. Wells (Bitbucket: garth-wells, GitHub: garth-wells).

Using SymPy in FIAT is like using a sledgehammer to crack a peanut.

It's a heavy dependency that imports a lot of files, which can slow import.

Also, the SymPy Debian/Ubuntu packages pull in a lot of very large package dependencies, e.g. texlive. This blows out the size of virtual images and Linux containers.

Original report by Jack Hale (Bitbucket: jackhale, GitHub: jackhale).

@Meg @robert_kirby @cmaurini @lzlarryli @Spike05

This report is based around a private conversation I had with Rob Kirby. I thought it might be worth discussing it here as well, and whether changes should be made to FIAT.

I will just talk about the family NED^1 on triangles but it may well apply elsewhere in FIAT.

At the moment, the edge degrees of freedom for NED_^ are located at equally spaced points along the edge of the triangle. So for NED_2^1 we have points at (1/3, 2/3) that are passed to PointEdgeTangentEvaluation to make NedelecDual2D.

As Rob pointed out quite rightly, these are a unisolvent set of points, and it works fine.

However, it is also possible to define the edge DOFs of NED_2^1 as an evaluation at the quadrature points of a Gauss rule of order 2. In my opinion, this definition is more consistent with the integral definition of NED^1 family as given in the FEniCS book.

The practical reason for doing this is that we then have a nice Galerkin-orthogonality property which is very useful for defining the local projection of the degrees of freedom of a vector-valued CG function onto a NED^1 space. By a fluke we were successful doing this for [CG_2]^2 to NED^1_1 space, because the FIAT definition and the integral definition coincide. These projections are critical to the success of our fenics-shells project.

Rob also mentioned that conditioning number for higher-order NED^1 elements may improve as well.

Proposal:

1. Make a class in functional.py IntegralEdgeTangentMomentEvaluation
2. Adjust NedelecDual2D definition appropriately.

We can probably do the coding on this but would need a bit of guidance.

Original report by Jan Blechta (Bitbucket: blechta, GitHub: blechta).

test_quadrature in the regression test uses yield to generate subtests. It works satisfactorily but it is not a standard pytest way.

Upstream in Firedrake we hook in to the PETSc citations mechanism so that someone can run a simulation and add the PETSc option -citations to show.

It would be nice if FIAT registered citations for all its elements (and possibly the fiat-related paper describing their implementation if required) so that people can know what to cite.

We don't want a hard PETSc dependency in FIAT, so how about something like this (see also some discussion in FInAT/FInAT#71), which a downstream consumer can hook up to PETSc (or otherwise just use).

class Citations(dict):
    """Entry point to citations management.

    This object may be used to record Bibtex citation
    information and then register that a particular citation is
    relevant for a particular computation.

    Example usage::

        from FIAT.citations import registry
    
        registry["key"] = "bibtex-entry-for-my-funky-method"

        ...

        if using_funky_method:
            registry.register("key")

        ...

        registry.bibtex(filename)
    """
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._registered = set()

    def __setitem__(self, key, entry):
        """Add a paper to the database of possible citations.

        :arg key: The key to use.
        :arg entry: The bibtex entry.
        """
        if key in self and entry != self[key]:
            raise ValueError("Adding duplicate key with different entry.")
        super().__setitem__(key, entry)

    def register(self, key):
        """Register that a paper has been used in this computation.

        :arg key: The key of the relevant citation.

        :raises KeyError: if no such citation is found in the database.

        Papers to be cited can be added using :meth:`add`.

        .. note::

           The intended use is that :meth:`register` should be called
           only when the referenced functionality is actually being
           used.
        """
        cite = self.get(key, None)
        if cite is None:
            raise KeyError(f"Did not find a citation for '{key}', did you forget to add it?")
        self._registered.add(key)

    def bibtex(self):
        """Produce bibtex of currently registered citations.

        :returns: String."""
        return "\n".join(self[key] for key in sorted(self._registered))
            

registry = Citations()

Background

This is related to #15 and also https://bitbucket.org/fenics-project/fiat/issues/25/nedelec-dofs-give-suboptimal-interpolation

Although the nodes that FIAT implements for these elements give optimal order of convergence for projection, they are not sufficient to provide optimal interpolation order. For example, for RTq, the textbook nodes are:

1. \int_F v \cdot n p ds where p is polynomials of degree q-1;
2. \int_T v \cdot p dx where p is d-vector-valued polynomials of degree q-2.

With these nodes, the so defined interpolation operator I^q_T has the approximation property (e.g. Brezzi and Fortin, Chapter III.3 (1991)):

||u - I^q_T u||_H(div, T) <= C h^q_T |u|_H^{q+1}_T

||u - I^q_T u||L^2(T) <= C h^q_T |u|_H^q_T

tl;dr: the interpolation error should converge at order q in both the L2 and Hdiv norms.

Instead of integral moments, FIAT uses point normal evaluations on the faces and point component evaluations on the cell (at equispaced lattice points). We therefore lose one order of approximation in interpolation in the Hdiv norm (because effectively we're underintegrating the moments).

On triangles, the face (edge) dofs can be component evaluations if they are chosen to fall at the Gauss points (and the polynomial set is the Gauss-Legendre polynomials) since then the quadrature rule collocates with the nodes of polynomial. No such construction exists for face dofs on tetrahedra.

Proposed fix

To fix this, one should replace the underintegrated point evaluation nodes by textbook integral moments. I've done this in firedrakeproject@c2e2eeb and obtain correct interpolation order for RTq.

Policy implications

Changing FIAT's dual basis modifies the primal basis, which means any checkpoints a user has now don't work. We therefore can't make this change without providing a migration path, and also deprecation warnings.

Proposal

UFL finite elements already have variant tags so that one can (for example) select between equispaced and Gauss-Lobatto points on interval elements. We should introduce variants (say integral [new] and pointwise [old]) defaulting to pointwise for the elements we fix. The form compiler's UFL->fiat element translation then needs to handle this. FIAT should spew deprecation warnings for the pointwise elements and suggest the fix for migrating data (project from old definition to new definition). At some point later (next major fenics release after the deprecation warning is introduced?) we switch the default. In the following release we remove the old nodes.

Original report by Dominique Orban (Bitbucket: optimizer, GitHub: optimizer).

It seems the PyPi package for FIAT is empty, pip install fiat fails with no package found. In the interim, this works though:

pip install -e git+https://bitbucket.org/fenics-project/fiat.git#egg=fiat

Original report by Jan Blechta (Bitbucket: blechta, GitHub: blechta).

See the discussion here https://bitbucket.org/fenics-project/fiat/commits/c84d5ce8ba5310f7d2ffa1f1376e2b91576fdcb0#comment-3456260

Original report by Miklós Homolya (Bitbucket: miklos1, GitHub: miklos1).

FIAT has generic rules for generating arbitrary order collapsed quadrature on triangles and tetrahedra ("canonical"). It also has a few hand-written rules for low-order quadrature on triangles and tetrahedra ("default"), which are presumably more efficient. The default rules indeed have fewer quadrature points than the canonical ones in all cases except one: degree 3 quadrature on the triangle.

The default scheme uses 6-point quadrature in this case, while the canonical scheme only uses 2 x 2 = 4 points.

Original report by Andrew McRae (Bitbucket: amcrae, GitHub: amcrae).

Hello all,

We at Firedrake recently incorporated the changes between 5500635 and ec68699 into our fork of FIAT (i.e. all of Nico/Aslak's recent changes)

After running our test-suite through cProfile, the time spent in FIAT's polynomial_set init or 'below' jumped from 1.28% to 18.21%, accompanied by a 15-20% increase in the total test time. Nearly all the time is spent in calls to numpy_lambdify and calls to form_derivative, both in expansions.py.

Any idea what's happened?

Original report by Jan Blechta (Bitbucket: blechta, GitHub: blechta).

Original report by Chris Richardson (Bitbucket: chris_richardson, ).

No check seems to be in place for sympy during the install.

When building specific functionals, we pass a name to the superclass constructor that is just a label.
A few of these superclass init calls have a functional name that doesn't match the class name. AFAICT this name is just an arbitrary label that one attaches, so it doesn't have to match.

To avoid this, we could make it an optional argument, and do:

class Functional:
    def __init__(self, ..., functional_type=None):
        ...
        self.functional_type = functional_type or type(self).__name__

Originally posted by @wence- in #56 (comment)

Original report by Garth N. Wells (Bitbucket: garth-wells, GitHub: garth-wells).

functional.py has used AD code from Scientific Python which is no longer imported by FIAT. Code must be non-functional.

Original report by Dominique Orban (Bitbucket: optimizer, GitHub: optimizer).

It seems the PyPi package for FIAT is empty, pip install fiat fails with no package found. In the interim, this works though:

pip install -e git+https://bitbucket.org/fenics-project/fiat.git#egg=fiat

Original report by Martin Sandve Alnæs (Bitbucket: martinal, GitHub: martinal).

An alternative family of quadrature points is the economical Gauss rules found here (reference at top of this file):

http://bazaar.launchpad.net/~syfi-core/fenics-syfi/main/view/611/site-packages/sfc/quadrature/quad_tables.py#L2941

For some choices of degrees it seems much more efficient.

Original report by Matthew Knepley (Bitbucket: knepley, GitHub: knepley).

Here is a small test that shows that 'master' disagrees with FIAT 0.9.9 and with common sense:

import numpy
from FIAT.polynomial_set import mis
from FIAT.reference_element import default_simplex
from FIAT.quadrature import make_quadrature

order = 1
quadrature = make_quadrature(default_simplex(1), order)

from FIAT.lagrange import Lagrange

degree = 1
element = Lagrange(default_simplex(1), degree)

vertices = [n.get_point_dict().keys()[0] for n in element.dual.get_nodes()]

quadpts = numpy.array(quadrature.get_points(), dtype=numpy.float64)
quadwts = numpy.array(quadrature.get_weights(), dtype=numpy.float64)
numQuadPts = len(quadpts)
evals = element.get_nodal_basis().tabulate(quadrature.get_points(), 1)
basis = numpy.array(evals[mis(1, 0)[0]], dtype=numpy.float64).transpose()
numBasis = element.get_nodal_basis().get_num_members()
basisDeriv = numpy.array([evals[alpha] for alpha in mis(1, 1)],
dtype=numpy.float64).transpose()

print "order: %d" % order
print "degree: %d" % degree
print "numQuadPts: %d" % numQuadPts
print "basis:"
print basis
print "basisDeriv:"
print basisDeriv

Original report by Garth N. Wells (Bitbucket: garth-wells, GitHub: garth-wells).

FIAT has virtually no tests. Expand testing to reach decent level of coverage.

Original report by Jan Blechta (Bitbucket: blechta, GitHub: blechta).

Information about supporting entities of dofs is thrown away in some subclasses of FiniteElement, e.g. DiscontinuousLagrange. The information is readily available - support entities of DiscontinuousLagrange are the same as Lagrange.entity_dofs() - but just thrown away.

The information is then needed to be recovered with hacks like FiniteElement.facet_support_dofs() and dolfin::DirichletBC::compute_bc_geometric.

Implement FiniteElement.support_entity_dofs().

Original report by Marie Elisabeth Rognes (Bitbucket: meg, GitHub: meg).

As Jan Blechta points out, the FIAT repository does not carry its test/reference.pickle. Thus the regression tests currently have zero value. The simplest fix is to just run the tests (quick) and commit the result.

Original report by Chris Richardson (Bitbucket: chris_richardson, ).

I just stumbled across this in expansions.py, lines 132-137:

pt_types = [ type(p) for p in pts[0] ]
ntype = type(0.0)
for pt in pt_types:
    if type(pt) != type(0.0):
        ntype = type(pt)

This will always return type<'type'>.
I have made a correction at https://bitbucket.org/chris_richardson/fiat/branch/chris/fix-typecheck

But maybe this code should be removed altogether?

Files in FIAT still use old long-format license in every file.

Original report by Miklós Homolya (Bitbucket: miklos1, GitHub: miklos1).

Currently, FIAT has Gauss-Jacobi quadrature rules for intervals (and being extended with Gauss-Lobatto and Gauss-Lobatto-Legendre by @David_Ham), collapsed quadrature rules for triangles and tetrahedra, and tensor product rules for tensor product cells. Since the collapsed quadrature rules are not the optimal choice, FFC contains hand-coded, optimal quadrature rules for triangles and tetrahedra up to degree 6. This is a proposal to move these rules to FIAT.

Effects:

• For FEniCS: No practical change, but all quadrature rules will be in a single component.
• For the FEniCS / Firedrake cooperation: TSFC "inherited" the quadrature rules from FFC. By moving these from FFC and TSFC to FIAT, we put more of our shared code under shared maintenance.
• For Firedrake: Having the quadrature rules scattered between components leads to poor composability. The tensor product rule is in FIAT, but the good triangle rules are in TSFC. Consequently, on prism cells (triangle x interval) we end up using the poor triangle rules.
• For FInAT: FInAT needs to have quadrature classes which express structure in quadrature rules, such as tensor product and collapsed quadrature. Having the quadrature rules scattered among TSFC, FIAT and FInAT is a nightmare for composability.

If you agree, I'm willing to do the surgery in both FFC and FIAT, so the code won't be duplicated in FEniCS.

Original report by Dominique Orban (Bitbucket: optimizer, GitHub: optimizer).

It seems the PyPi package for FIAT is empty, pip install fiat fails with no package found. In the interim, this works though:

pip install -e git+https://bitbucket.org/fenics-project/fiat.git#egg=fiat

Information about the number of co-located dofs on each entity is needed for FEniCS/ffcx#176.

Most likely, this information would need to be an unflattening map or the shape of the unflattened dof map.

Original report by David Ham (Bitbucket: David_Ham, ).

I'm tryting to add the new elements in the Firedrake version of FIAT to the regression tests. It is very unclear to me how this is supposed to work. I added a new element (Discontinuous Taylor) into the list of elements to be tested, and unsurprisingly this causes the test to fail because it has nothing to compare against. However I can't see an option which would enable me to bootstrap this process by generating the reference data.

Original report by Ben Crestel (Bitbucket: bcrestel, GitHub: bcrestel).

There is a general agreement that these interpolation points are better suited for high-order elements. It seems like this should be a direct modification of the Lagrange class (for someone who's familiar with FIAT.....).