dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Tuesday 24 February 2009 21:07:43 A Navaei wrote:
> 2009/2/24 Johan Hake <hake@xxxxxxxxx>:
> > On Tuesday 24 February 2009 16:17:43 A Navaei wrote:
> >> 2009/2/24 Johan Hake <hake@xxxxxxxxx>:
> >> > On Tuesday 24 February 2009 01:08:11 A Navaei wrote:
> >> >> Finally after all those long discussions on the best way of
> >> >> architecturing variational image processing problems based on dolfin,
> >> >> a minimal demo showing how to solve a classical motion estimation PDE
> >> >> is available now -- thanks for all the support. Detailed explanation
> >> >> is given here:
> >> >>
> >> >> http://code.google.com/p/debiosee/wiki/DemosOptiocFlowHornSchunck
> >> >>
> >> >> Currently, the c++ implementation is done and the python wrapper is
> >> >> on the way.
> >> >
> >> > Cool!
> >> >
> >> >> I have tried to perform sub-classing as much as possible and leave
> >> >> the rest to be implemented outside of the main classes. While this
> >> >> works, there is a tiny problem which I'm not quite happy about. Here
> >> >> is what's happening:
> >> >>
> >> >> [ITK-backend]
> >> >>
> >> >>       v
> >> >> [GenericImage]-------\
> >> >>
> >> >>       v              |
> >> >> [ImageToMesh]        |
> >> >>
> >> >>       v              |
> >> >> [FunctionSpace]      |
> >> >>
> >> >>       v              |
> >> >> [ImageFunction]<-----/
> >> >>
> >> >> If you still cannot see what's happening, get a monospace font :)
> >> >> What I don't like is the right branch connecting GenericImage to
> >> >> ImageFunction. There should be a way of making sure that the two
> >> >> branches are initiated from the same image source, or this could be a
> >> >> source of error. Simply encapsulating this in a class takes away the
> >> >> freedom of defining a general problem away from the user.
> >> >
> >> > Just a thought:
> >> >
> >> > Would it help to let GenericImage also be a dolfin::Mesh? Then in
> >> > ITKImage you copy paste the algorithm for creating a
> >> > UnitCube/UnitSquare/Rectange/Box (the algorithms are actually not very
> >> > large).
> >>
> >> I understand that implemented algorithms are short, but maybe it's not
> >> a good practice to copy/paste the code (even if it's a short code). We
> >> should think of a more creative way of doing this.
> >
> > Sure ;)
> >
> > One alternative could be to inherit UnitSquare directly but then we need
> > to put the creation algorithm in, e.g., an init function (protected such
> > ;) ). This will then be called in the constructor, and we also need an
> > empty constructor to be called by the inherited mesh, which may or may
> > not make any sense at all.
>
> This looks like something feasible to me. What about having a virtual
> Mesh::Init() called in Mesh() so that the subclasses just have to
> override Init()? Then in the ImageMesh case, the parent Init() should
> be also called and the extra branch in the diagram will disappear.

I have to call for comments from the other c++ hackers for such change. 

> In case you missed the other question, is the information about number
> of cells in each dimension lost in UnitSquare or can it be retrieved?

Well ... I avoided it, I had not think it through I think ;)

If we should add them I guess we need to include other similare attributes 
from the other built in meshes too?

Johan