ffc team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> On Mon, Dec 04, 2006 at 03:51:04PM +0100, Johan Hoffman wrote:
>> 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
>
> Yes, maybe.
>
> Add anything you need in src/kernel/functions/SpecialFunctions.h.
>
> (If it's not too special...:-)
>
> /Anders

Ok.

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