← Back to team overview

dolfin team mailing list archive

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

 

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

-- 
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References