On Fri, Dec 19, 2008 at 10:55 AM, Johan Hake <[email protected]> wrote: > On Friday 19 December 2008 10:08:40 Kristian Oelgaard wrote: >> Quoting Johan Hake <[email protected]>: >> > 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 <[email protected]> >> > > > > > 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. > > If noone(tm) does not object to this difference in c++ vs python version of > the demo, I can update the python one, and take a try on the OutflowFacet > function in SpecialFunction to a not-so-special function. This will then be > instantiated using a FunctionSpace and the field function. > > Johan
Just a minor language nitpicking: The name "OutflowFacet" indicates that this is some sort of facet, i.e. a geometric entity, but it's a function, so... Maybe you mean "FacetOutflow"? Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
