dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #00909
Re: Re: [FFC-dev] Mesh
-
To:
Discussion of DOLFIN development <dolfin-dev@xxxxxxxxxx>
-
From:
Matthew Knepley <knepley@xxxxxxxxxxx>
-
Date:
Thu, 01 Sep 2005 11:15:39 -0500
-
In-reply-to:
<20050901160420.GI23003@galerkin> (Anders Logg's message of "Thu, 1 Sep 2005 11:04:20 -0500")
-
Reply-to:
Discussion of DOLFIN development <dolfin-dev@xxxxxxxxxx>
-
User-agent:
Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux)
Anders Logg <logg@xxxxxxxxx> writes:
> On Thu, Sep 01, 2005 at 10:53:37AM -0500, Matthew Knepley wrote:
>> 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
>
> Sounds like I need to read that paper. Do you have a link?
Sorry, my fault for not sending it. This is the draft we sent for the Tech report.
I think we send the version to TOMS today.
Matt
Attachment:
sieve.pdf
Description: Sieve paper
--
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness
References