← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Fix remaining unchecked demos. Some?demos still broken:

 

Quoting Johan Hake <hake@xxxxxxxxx>:

> On Thursday 18 December 2008 22:34:14 Anders Logg wrote:
> > On Wed, Dec 17, 2008 at 11:42:47PM +0100, Johan Hake wrote:
> > > On Wednesday 17 December 2008 22:57:48 Anders Logg wrote:
> > > > On Wed, Dec 17, 2008 at 10:53:32PM +0100, 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:   5406:bc43cc830c11058dcabf239a5a7f878bb860fabb
> > > > > tag:         tip
> > > > > user:        Anders Logg <logg@xxxxxxxxx>
> > > > > date:        Wed Dec 17 22:53:27 2008 +0100
> > > > > files:       TODO demo/la/eigensolver/python/demo.py
> > > > > demo/pde/optimization/python/demo.py description:
> > > > > Fix remaining unchecked demos. Some demos still broken:
> > > > >
> > > > >   EE demo/pde/nonlinear-poisson/python/demo.py
> > > > >   EE demo/pde/poisson1D/python/demo.py                    viper
> > > > > problem with 1D EE demo/pde/waveguide/python/demo.py                
> 
> > > > >   results in C++ and Python differ EE
> > > > > demo/pde/dg/advection_diffusion/python/demo.py
> > > > >   EE demo/nls/nonlinearpoisson/python/demo.py
> > > > >   EE demo/mesh/partitioning/python/demo.py
> > > > >   EE demo/mesh/intersection/python/demo.py                strange
> > > > > transformation EE demo/ode/aliev-panfilov/python/demo.py
> > > > > EE demo/ode/lorenz/python/demo.py
> > > >
> > > > We may ignore the ODE demos here. Some work is needed to get the ODE
> > > > solvers to function from Python but they have only worked in part
> > > > before so it's not very important now.
> > > >
> > > > The following demos remain:
> > > >
> > > >    demo/pde/nonlinear-poisson/python/demo.py            ?
> > > >    demo/pde/poisson1D/python/demo.py                    viper problem
> > > > with 1D demo/pde/waveguide/python/demo.py                    results
> in
> > > > C++ and Python differ
> > > >    demo/pde/dg/advection_diffusion/python/demo.py       ?
> > >
> > > This demo is somewhat depricated as it stands now. I added it based on
> > > the previous c++ demo. Since then has the c++ demo changed, to be more
> > > simple, but including the builtin OutflowFacet special function. This is
> > > not included in the python interface.
> > >
> > > To get it up and running in python we need to add OutflowFacet to the
> > > python interface. This should be doable, and quite straightforward with
> > > the new function interface. Please correct me:
> > >
> > > class OutflowFacet(ffc.Function,cpp.OutflowFacet):
> > >     def __init__(self, vec_field):
> > >         appropriate check on vec_field
> > >         mesh = vec_field.function_space().mesh()
> > >
> > >         # Define the OutflowFacet form
> > >         n = FacetNormal(mesh)
> > >         a = ffc.dot(vec_field,n)*ffc.ds
> > >         self._dolfin_form = Form(a)
> > >
> > >         domain  = dim2domain[mesh.topology().dim()]
> > >         self._element = ffc.FiniteElement("Discontinuous Lagrange",
> > > domain, 0)
> > >
> > >         ffc.Function.__init__(self, self._element)
> > >         cpp.OutflowFacet(self, self._dolfin_form)
> > >
> > > It is a bastard wrt being a full fledged dolfin.Function, it does not
> > > define its own function space. I do not know if this would be a problem
> > > as the c++ counterpart neither initiate its base class with a
> > > functionspace.
> > >
> > > Once this function is in place the rest should be quite straight
> forward.
> > >
> > > Johan
> >
> > It looks strange to me, and so does the C++ version (that a Function
> > needs to be initialized with a form).

That's what makes it a 'SpecialFunction' :)

> > How about just evaluating the function at the midpoint of the facet
> > and computing the inner product with the facet normal?
> 
> Sounds resonable enough to me. I suppose an integral over the facet is 
> potentially more aqurate than just the midpoint evaluation. 

Yes, I guess this will be OK, and if it turns out that one needs the integral
for accuracy reasons it is still possible to implement the function in the
main.cpp file.
We could do this for the CPP demo and use the 'new' OutflowFacet in the Python demo.

Kristian
 
> 
> Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
> 




Follow ups

References