← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Work on getting dg?advection-diffusion demo to work in python

 

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!

Johan


Follow ups

References