dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> writes:

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

  Yes, the generalization comes from the broader definition of restriction
and assembly operations. In the language of the paper, a Function can define
only cocycles, where a SievedArray can handle cochains.

     Matt

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

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness