← Back to team overview

ffc team mailing list archive

Re: [DOLFIN-dev] geometry in FFC

 

Ok, sounds good. So with this FaceNormal one could also specify
non-homogeneous Neumann bc (including the normal) in FFC with "ds"?

Are also FaceTangents under way?

/Johan

> These are functions that are best treated as Functions (coefficients).
> We already have MeshSize as a default function in DOLFIN and we will
> soon have (probably this week) a function FacetNormal that we will use
> for DG.
>
> The mapping we need to make is from FFC to DOLFIN so that one can
> write h = MeshSize() in FFC without having to declare the
> corresponding function in DOLFIN.
>
> /Anders
>
>
> On Mon, Dec 04, 2006 at 03:26:56PM +0100, Johan Hoffman wrote:
>> In connection with the dof-discussion; could we add geometry info to
>> FFC?
>> Like diameter, normals, tangents etc. From what I understand this info
>> is
>> already in FIAT, so it would amount to adding a mapping to FFC?
>>
>> /Johan
>>
>>
>>
>>
>> > Anders Logg wrote:
>> >> On Mon, Dec 04, 2006 at 02:14:51PM +0100, Garth N. Wells wrote:
>> >>> Could we add something to FFC to describe where the various degrees
>> of
>> >>> freedom live (on vertices, edges, internal)?
>> >>>
>> >>> Garth
>> >>
>> >> Yes we could, but I'd rather not. Why do we need it? I'd prefer if
>> >> DOLFIN did not know anything about dofs, other than how to reorder
>> >> them.
>> >>
>> >
>> > Not sure that it's this simple if you want to assemble some terms
>> > block-wise. Also, for parallel assembly we might need to know where
>> dofs
>> > lie. I'm still thinking about this so I can't be concrete in what's
>> > needed just yet.
>> >
>> >> I see two options:
>> >>
>> >>  1. Reorder the dofs computed by FFC, not knowing why and how they
>> >>     are numbered.
>> >>
>> >
>> > This is one option I'm considering. Just take the FFC numbering, and
>> run
>> > a renumbering algorithm over it to minimise bandwidth.
>> >
>> >>  2. Compute a different mapping in FFC.
>> >>
>> >
>> > This could be difficult as it depends on properties of the mesh,
>> > partition, etc. I think that this should remain simple.
>> >
>> >> I can be convinced otherwise of course, but I don't understand why
>> >> this is needed.
>> >>
>> >> /Anders
>> >> _______________________________________________
>> >> FFC-dev mailing list
>> >> FFC-dev@xxxxxxxxxx
>> >> http://www.fenics.org/mailman/listinfo/ffc-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > FFC-dev mailing list
>> > FFC-dev@xxxxxxxxxx
>> > http://www.fenics.org/mailman/listinfo/ffc-dev
>> >
>>
>>
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>





Follow ups