← Back to team overview

dolfin team mailing list archive

Re: [FFC-dev] geometry in FFC

 

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



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


Follow ups

References