fenics team mailing list archive

[Robert C.Kirby <kirby@xxxxxxxxxxxxxxx>]

I'll take a look.  Let me respond to FIAT below:

On Nov 17, 2004, at 3:34 PM, Anders Logg wrote:

> Hi!
>
> I just put up a new version of FFC (version 0.1.2). Among other
> things, I have added a command-line interface and some examples. Try
>
>     ffc navierstokes.form
>
> or why not
>
>     ffc -l latex navierstokes.form
>
> In case you just want to take a quick look, I include input and output
> of running FFC on this example. (More examples available in the
> directory src/demo.)
>
> I haven't done any real tests to see if the generated code is
> correct. I think it is correct for Poisson and it looks reasonable for
> Navier-Stokes. To compute the reference tensor for Navier-Stokes in
> 3D, a total of 46656 integrals are computed with FIAT. This takes
> about 10 seconds on my computer. Checking for factors which are
> identically zero (which happens since I create the elements by taking
> tensor products of scalar elements) speeds up the computation by
> roughly a factor 10 (takes a minute otherwise).

> Some suggestions for FIAT that I have come to think of as a FIAT user:
>
> - Perhaps we need to create a run-time C-library to speed it up? It's
> not critical right now, but if we want to have JIT compilation of
> forms I think we need it.
Yes -- I'm working on it as part of my collaboration with Kevin.


> - Tensor-valued elements are missing in FIAT. I have added a simple
> implementation that takes care of this, at least well enough for FFC.
> The class is called TensorSpace. Maybe this one could be moved to
> FIAT?

In the old version, not in the new one yet.

> - Can FIAT be responsible of knowing the local-to-global mapping? The
> name of the finite element is input to the compiler, and I think the
> output should contain all data necessary to do the assembly, including
> the local-to-global mapping. That means FFC needs to ask FIAT about
> the mapping and generate code that contains the mapping in one form or
> another. (DOLFIN would use this information to build the
> local-to-global mapping.)

Yes, it already is (sort of) -- look in dualbasis.py -- it gives which 
local nodes correspond to the vertices, edges, faces, etc.  You have to 
couple that with an ordering from the mesh.

The problem comes if you try to do Hermite elements -- you need to know 
that some of the nodes at vertices are derivatives and others are 
point-values.  It matters.

> - I have also created a simple wrapper class FiniteElement which makes
> it possible to pick the type of element by giving a string (the name
> of the element). I found it convenient to access FIAT this way.
> Maybe this (or something similar) could also go into FIAT?

Not sure why it's so important, but would be trivial to do.

> - I think there should be a setup.py script that takes care of
> installation. I'll be adding this to FFC and I think it's standard.
> I know I can just copy the files, but I shouldn't have to.

FIAT is a work in progress... This is easy to do.

> - You might also want to throw in some other standard files at the
> top-level directory of FIAT, like AUTHORS, README, INSTALL, COPYING,
> TODO, ChangeLog.
See above.

> - Versioning: With DOLFIN soon depending on FFC and FFC depending on
> FIAT, I would like to see version numbers X.Y.Z for FIAT, where
> probably X = 0 at this point.

Probably so.

> - My last point is perhaps the most important one and that is to put
> FIAT on fenics.org. A tar.gz tarball is ok if you don't want to put it
> in CVS (I know you don't).

So, I've heard back from ACM -- they will own copyright to the old 
version that I'm publishing, and we are free to license substantial 
rewrites however we want (LGPL, probably).

> /Anders
> <navierstokes.form><NavierStokes.h>