dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Dec 21, 2008 at 11:47:21PM +0100, Johan Hake wrote:
> On Sunday 21 December 2008 23:26:53 Anders Logg wrote:
> > On Sun, Dec 21, 2008 at 11:08:57PM +0100, Johan Hake wrote:
> > > On Saturday 20 December 2008 23:55:39 Anders Logg wrote:
> > > > On Sat, Dec 20, 2008 at 11:03:32PM +0100, Johan Hake wrote:
> > > > > On Saturday 20 December 2008 22:59:48 DOLFIN wrote:
> > > > > > One or more new changesets pushed to the primary dolfin repository.
> > > > > > A short summary of the last three changesets is included below.
> > > > > >
> > > > > > changeset:   5428:5ee944b2216752dd3078f0906c9500837a65097a
> > > > > > tag:         tip
> > > > > > user:        "Johan Hake <hake@xxxxxxxxx>"
> > > > > > date:        Sat Dec 20 22:59:46 2008 +0100
> > > > > > files:       demo/pde/dg/advection-diffusion/cpp/main.cpp
> > > > > > demo/pde/dg/advection-diffusion/python/demo.py
> > > > > > dolfin/function/SpecialFunctions.cpp
> > > > > > dolfin/function/SpecialFunctions.h
> > > > > > site-packages/dolfin/specialfunctions.py description:
> > > > > > Work on getting dg advection-diffusion demo to work in python
> > > > > >  - Changed name of OutFlowFacet function to Is...
> > > > > >  - IsOutFlowFacet is instantiated using a FunctionSpace and a field
> > > > > > funtion - the evaluation of IsOutFlowFacet is done by evaluating
> > > > > > the field in the midpoint of the facet
> > > > > >  - Does not work properly yet.
> > > > >
> > > > > I done some work on the IsOutFlowFacet in the direction previously
> > > > > discussed. The function is now mapped to python. Please have a look
> > > > > on the
> > > > > implementation. It could probably had been made easier.
> > > > >
> > > > > The demo runs but the result differ from the cpp. Please have a look.
> > > > >
> > > > > It also raises a lot of warings during assemble :
> > > > >
> > > > >   *** Warning: Point belongs to more than one cell, picking first.
> > > > >
> > > > > Johan
> > > >
> > > > It shouldn't be necessary to call eval(). That involves a search
> > > > through the mesh to find the correct cell and we already know the cell
> > > > from data.cell().
> > >
> > > Ok.
> > >
> > > > This means we should be able to call evaluate_basis directly. To
> > > > avoid needing to duplicate the code at the end of FunctionSpace::eval
> > > > starting with _dofmap->tabulate_dofs(), we should move that code to a
> > > > separate call that can be reused in both.
> > > >
> > > > My suggestion would be an additional eval function that gets the
> > > > current ufc_cell as an argument.
> > >
> > > Would this also scale to a function that is not discrete?
> >
> > Yes, it should (if we get the logic correct). It's a three step
> > process:
> >
> > 1. Find the cell that contains the point x
> >
> > This is handled by IntersectionDetector (GTS) but is not needed if we
> > already know the cell.
> >
> > 2. Call DofMap::tabulate_dofs to evaluate all the dofs (expansion
> > coefficients) on the current cell.
> >
> > This should either result in the coefficients being picked directly
> > from the global vector (for a discrete function) or by calls to the
> > eval() functions (either one of the two we have now).
> >
> > 3. Call FiniteElement::evaluate_basis to evaluate the basis functions
> > at the point x and evaluate the linear combinatio (dofs and basis
> > function values).
> 
> Ok, I am _really_ not into the deep magic of the function 
> evaluations/interpolations/abstraction/redirection (or what ever), so I leave 
> this to you guys to sort out!

That's what I was afraid of. :-)

I'll see what I can do.

-- 
Anders

Attachment: signature.asc
Description: Digital signature