ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

This really sounds good. I look forward to trying it out.

The array part seems to correspond to the Function concept we have in
DOLFIN. A Function in DOLFIN is defined by three things (private
member of the Function class):

    Vector* x; // wrapper for PETSc Vec
    FiniteElement* element;
    Mesh* mesh;

The vector holds the degrees of freedom, and the finite element
(generated from a FIAT finite element by FFC) defines how these are
distributed on the mesh.

A Function can be evaluated (but the implementation for evaluation at
arbitrary points is missing), passed as a argument to a variational
form and be written to a File for visualization.

/Anders

On Thu, Sep 01, 2005 at 09:51:37AM -0500, Matthew Knepley wrote:
> Anders Logg <logg@xxxxxxxxx> writes:
> 
> > Yes, the intention is that we should look closely at Matt's new mesh
> > component and if possible completely throw out all our mesh stuff and
> > wrap the new mesh component in DOLFIN.
> >
> > When you're ready Matt, pick a name (Sieve?) and put it on fenics.org.
>   
>   There will be two names: Sieve for a thing which encodes topology, and
> SievedArray for a thing which stores data in a hierarchical format consistent
> with a certain topology. The idea here being that a SievedArray can both
> 
>   1) Present data in a contiguous parallel format like a PETSc Vec
> 
> and
> 
>   2) Restrict that data to coverings of the original topology (like a
>      single element), and then reassemble
> 
> > My only worries is that (i) the new mesh component will be not be
> > limited enough in its scope and force us to throw out more than just
> > the mesh component and (ii) it will be impossible to install... ;-)
> 
>   I will try and address these:
> 
>   1) I am fairly confident that we are alright here. This is ONLY intended
>      to make the program understand topology and data organized around it.
>      It should slot in just below normal linear algebra for storage, and
>      should provide the necessary information to organize a) parallel
>      assembly and b) finite element assembly.
> 
>   2) Since it is implemented entirely in C++ with STL as a first pass, our
>      idea was for you just to use the C++, which is a bunch of self-contained
>      files. The build should be easy. I have a bunch of interop stuff on top
>      to make it do Python, but you don't need this.
> 
>      Matt
> 
> > /Anders

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/